PLETE_FUNCTIONAL from SimGear and FlightGear.
As a result, SG_HAVE_STD_INCLUDES is now *always* set, so I will get the boring
fixes for that done, but separately. I'm still auditing the other things in comp
ilers.h - there's a lot that can die now BORLAND is gone.
After the changes that moved the GUI and HUD to a slave camera, the
texture-based fonts wouldn't display. The main fixes here are making
sure that the TXF textures are all loaded into the font cache early,
and explicitly setting the active texture unit in the GUI / HUD
drawImplementation.
Switch to defining PU_USE_NONE and providing our own callback
functions to pui for "get window" and "get window size." A new
WindowSystemAdapter class assigns ID numbers to windows for the
purpose of identifying them to plib; the window size can be extracted
from the osg::GraphicsContext class in all the different
implementations (osgViewer, glut, sdl).
Implement a GraphicsContextOperation that runs code in a particular
graphics context, perhaps in another thread, and provides an
isFinished() method to test if the operation has finished. This allows
us to initialize plib PUI properly if there are multiple graphics
contexts without using fgMakeCurrent(). fgMakeCurrent() can't work in
multi-threaded OSG configurations.
Eliminate fgMakeCurrent() and all its uses, either by using
GraphicsContextOperation or by seeing that it is not necessary.
Attach the GUI camera as a slave camera.
Don't manipulate the OSG state in the drawImplementation() functions
for SGHUDAndPanelDrawable and SGPuDrawable; it's not needed.
- re-enable od_gauge ("owner drawn" render-to-texture instruments)
- implement radar in c++ (unlimited number of clouds/ai/mp/... objects,
better performance)
- Well I finally licked it, the clipping works great now, in 16 and 32
bpp mode, on 2d and 3d panels.
- I tried glScissors, didnt work because clipping was done in screen
co-ordinates.
- Stencil buffer methods worked great for 2d panel, but messed up 3d
panels,(depth buffer problems I think), and only worked in 32 bpp mode.
- I then tried clip planes , and so far it appears to work with no
problem, and no framerate drop like I had with the stencil buffer
method...
I'm attaching the panel.cxx file for testing...
color group /sim/hud/palette/color[*]/ to the active group /sim/hud/color/
if they really exist. (Parameters like <antialiased> can be set in the
active group and be left alone, or set by each <palette> color group.)
there was the situation where four directories contained jst two files,
of which three directories were aircraft related, and one directory contained
test code from Curt that might be better of in SimGear anyhow.
This is just a patch to move a bunch of files to new locations. In case of
local changes to any of them you can do the following:
move replay.[ch]xx from src/Replay to src/Aircraft
move control.[ch]xx from src/Control to src/Aircraft
move ssgEntityArray.[ch]xx from src/Objects to simgear/screen
In addition it has been decided only to use .[ch]xx files in all directories
unless it's contained within an FDM specific directory, in which case the
author is free to do whatever (s)he wants.
In this repspect the following files have been renamed in src/Multiplayer:
tiny_xdr.[ch]pp has become tiny_xdr.[ch]xx
multiplaymgr.[ch]pp has become multiplaymgr.[ch]xx
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
Using new gcc 4.0 I have some serios warnings about uninitialized
variables, that are used. I created a patch, but I have no idea if it
is possible to do it my way. Can you check this out please?
Erik: I've modified the patch slightly based on the contents of an older
version of hitlist.cxx. I think this is correct now.
- replay.cxx :
corrected a bug, now reinitialize the recording data when replay is
deactivated
- fgclouds.cxx :
cloud layers and weather condition are saved when choosing a weather scenario,
added a new scenario 'none' so we can switch back to standard flightgear
weather
- navradio.cxx :
force a search() on init to initialize some variables, preventing a nearly
infinite loop when delta-time == 0 on the first update()
- electrical.cxx :
uninitialized variable in apply_load() for FG_EXTERNAL supplier
- panel.cxx, panelnode.cxx :
added a property "depth-test" for 2.5D panels so that they update the depth
buffer and are no more visible from the outside of the aircraft when the
aircraft uses textures without an alpha channel
- panel.cxx :
moved the computation of the instruments diffuse color outside the
texturelayer code since this is constant during a frame, this is a big speedup
for 2D panels
I have prepared a patch that:
- Introduces a FGTileMgr::scenery_available method which asks the tilemanager
if scenery for a given range around a lat/lon pair is already loaded and make
use of that method at some -9999 meter checks.
- Introduces a FGScenery::get_elevation_m method which queries the altitude at
a given position. In constrast to the groundcache functions this is the best
choice if you ask for one *single* altitude value. Make use of that thing in
AI/ATC classes and for the current views ground level. At the current views
part the groundcache is reused if possible.
- The computation of the 'current groundlevel' is no longer done on the
tilemanagers update since the required functions are now better seperated.
Alltogether it eliminates somehow redundant terrain level computations which
are now superseeded by that more finegrained functions and the existence of
the groundcache. Additionally it introduces an api to commonly required
functions which was very complex to do prevously.
a single apt.dat.gz file which is in the native X-Plane format.
To do this I wrote a front end loader than builds the airport and runway
list. Some of the changes I needed to make had a cascading effect, so there
are minor naming changes scattered throughout the code.
I've finished the emigration of the radiostack, and I've also removed it
completely. It turned out that the comm radio is completely implemented in
the ATC subsystem. I've changed the affected ATC files to point
to /instrumentation/com, but I guess that the maintainer of the ATC code
should decide wether to make it configureable, and how.
I also had to change some files in Network and Main. The changes in network
should be obvious, but the changes in Main were a bit suspect. The files
included radiostack.hxx, but they weren't directly depending on
radiostack-hxx. They were depending on other files that were included by
radiostack.hxx. I got it to compile, but I'm not sure if I included the
correct directly depending file.
For the data directory I changed every occurrence of /radios/
with /instrumentation/ with this simple one-liner that I found on the net:
find -name '*.xml' -type f | xargs perl -pi -e
's/\/radios\//\/instrumentation\//g'
Instead of me sending all the files that got changed by this I suggest that
you execute the one-liner yourself. Of course I can not guarantee that this
will work perfectly, but I considered hand editing to be not an option (I'm
lazy). I don't want to test every aircraft to see if everything still works,
I think it's better to wait and see if anyone complaints about broken nav
radios/instruments.
I understand that the new hud/runway feature is still very experimental,
and that the search criteria for the active runway don't necessarily make
much sense. (We are searching for a runway on /sim/presets/airport-id
that matches the current wind direction best, and not the tuned in ILS
runway or something!)
Anyway: the new hud code completely denies the possibility of
globals->get_runways()->search() not finding a runway and returning false.
There's always a runway found at KSFO, but not so at e.g. LOXL, in which
case we are handing garbage over to sg_geodesy.cxx and find ourselves
caught in an endless loop in geo_direct_wgs_84().
directory and over to the Instrumentation directory and make them modular
in the sense of being able to pick and choose what you include with any
particular aircraft.
Aaron says:
I just got the virtual runway hud projection working on all views and
2D & 3D HUDs. It is working awesome(see below). I have attached every
file that was modified (hud.hxx, hud.cxx, and the default.xml for the hud)
and every file that was added (hud_rwy.cxx and runwayinstr.xml).
Just a quick overview of how the instrument works.
The virtual runway is projected by getting the "cockpit view" of the
runway in 3D and projecting the points on to the 2D HUD. Therefore, the
virtual runway will be displayed the same in every view. For example,
you can land an aircraft from the "Tower View" by flying the HUD. Also
if you're in "Cockpit View" and it is centered then the virtual runway
lines will perfectly outline the actual runway. I am getting the active
runway via the wind like done in the ATC classes, which may need changed.
Also, I made the assumption the view 0, in view manager, is always the
cockpit view, which may need changed as well.
The runway configuration file will allow you to specify a center offset
(x,y) and a bounding box (width,height). You can also configure the line
stipple pattern for the outside and the center line. For instance, if
you wanted a 0xFAFA pattern, then specify 64250 as the value. If you
want a solid line, you can specify -1 or 65535 (0xFFFF) and zero will
turn the line off. It also draws a runway indication arrow when the
runway is not in the HUD or it can be drawn all the time if arrow_always
is true. The arrow will point in the direction of the runway (2D) by
rotating around the center at a radius of arrow_radius. If you wish to
turn the arrow off, you must set the arrow_scale <=0. The arrow really
should be 3D arrow that points to the runway (or points in the direction
of the aircraft-to-runway vector).
compilation without ENABLE_SP_FMDS defined gave me a lot of link errors. It appeared that symbol used by ADA was still in use in the HUD.
There is also a typo from Curt in instrument_mgr.cxx where he #include "kr_87.cxx" instead of "kr_87.hxx"
All necessary elements for an ADF gauge had been migrated from
Cockpit/kr_87.cxx to Instrumentation/adf.cxx. Migrating the sound
related elements was apparently planned, but not done yet. This
intermediate state broke the ident morse sound: it couldn't get
turned off and it always indicated "SF", regardless of the tuned-in
frequency. The following patches continue the migration:
adf-radio.diff => Base/Aircraft/Instruments/adf-radio.xml:
---------------------------------------------------------------
* sets maximum volume to 1 (rather than 2); Not only is 1
loud enough (and 2 unpleasantly noisy), it also prevents
the knob from being turned to non-existant positions. :-)
* fixes wrong use of /instrumentation/adf/ident
* the voice/ident selector(?) remains unchanged, but as it's
not switched to "IDENT", there'll be no ident sound by default
this is consistent with other sounds and DME.
radiostack.diff => src/Cockpit/radiostack.[ch]xx:
---------------------------------------------------------------
* comment out use of FGKR_87 class. kr_87.[ch]xx is now no
longer used. kr-87adf.xml would no longer work, either, but
isn't used anywhere, anyway. Future adf radios have to use
the adf instrument, using xml/Nasal for specific hardware
implementation details.
adf.diff => src/Instrumentation/adf.[ch]xx:
---------------------------------------------------------------
* adds ident morse sound capability using two new input
properties:
- /instrumentation/adf/volume-norm (double)
- /instrumentation/adf/ident-audible (bool)
will delay it's reply by 50ms. The ground station can change it's reply delay
to trick the airborn dme unit into reporting a distance that is offset from
the true distance by some constant value. In FG we model this by subtracting
a fixed distance from the actual distance.
It is thus possible in our implimentation for the displayed distance to become
negative. This patch clamp DME distance to a minimum value of 0.00 so it can
never go negative.
A good elevation is critical for proper glide slope modeling. This patch
assigns the average field elevation to any ILS component that doesn't have
a valid elevation.
Also, for an ILS approach, use the GS transmitter elevation for glide slope
calculations rather than the localizer elevation, in some cases this can
make a big difference.
- FG now directly supports Robin's native nav database file format.
- His latest data now separates out dme, gs, loc, and marker beacon
transmitters rather than lumping them all into a single "ILS" record.
- These new data structure changes prompted me to do some code restructuring
so that internally these different types of navaids are all kept as
separate lists and searched and handled separately.
- This structural change had a cascading affect on any code that
references or uses the nav databases. I've gone and "touched" a lot of
nav related code in a lot of places.
- As an added bonus, the new data (and code) adds DME bias so these will
all now read as they do in real life.
- Added Navaids/navdb.cxx and Navaids/navdb.hxx which provide a front
end loaders for the nav data.
- Added Navaids/navrecord.hxx which is a new "generic" nav data record.
- Removed Navaids/ils.hxx, Navaids/ilslist.cxx, Navaids/ilslist.hxx,
Navaids/mkrbeacons.cxx, and Navaids/mkrbeacons.hxx which are all now
depricated.
Add FGPredictor class to xmlauto. Add support for horizontal navigation based
on flight track as opposed to heading. Add crosstrack-error support to nav.
Simplify error adjust calculation for horizontal nav (better interception).
Fixed potential divide by zero that was producing nan issues in the xmlauto
code.
immediate end to glut, only that I'm going through and cleaning up (and
taking inventory of the actual glut dependencies in case I want to investigate
SDL.)
