I stumbled across two memory errors with two wrong const references to
std::string.
As I fixed that, I also moved aircraft_dir which is only used from UIUC into
UIUC. With that uiuc_aircraftdir.h is empty and can be removed.
There was a patch from Manuel Masing a few months ago which cleaned up
SGLocation's way depending on input values. That means that with that patch
SGLocation does no longer have calls with unneeded input arguments.
I took his patch and integrated that into flightgear and made maximum use of
that changes.
Erik Hofman:
Remove some duplicate code that was moved to simgear/compiler.h
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.
I have traced that reset on carrier problem down to several problems. One of
them is the fact that on reset the carrier is updated while the aircraft is
not. That made the aircraft drop down an elevator sometimes. Depending on the
passed realtime while loading some parts of the scenery.
/sim/startup/splash-progress)
- a string in /sim/startup/splash-title is displayed on top of the screen
and by default empty
- the splash image is scaled down if 512x512 is too big
- code cleanup
I have done a patch to eliminate the jitter of 3D-objects near the viewpoint
(for example 3D cockpit objects).
The problem is the roundoff accuracy of the float values used in the
scenegraph together with the transforms of the eyepoint relative to the
scenery center.
The solution will be to move the scenery center near the view point.
This way floats relative accuracy is enough to show a stable picture.
To get that right I have introduced a transform node for the scenegraph which
is responsible for that shift and uses double values as long as possible.
The scenery subsystem now has a list of all those transforms required to place
objects in the world and will tell all those transforms that the scenery
center has changed when the set_scenery_center() of the scenery subsystem is
called.
The problem was not solvable by SGModelPlacement and SGLocation, since not all
objects, especially the scenery, are placed using these classes.
The first approach was to have the scenery center exactly at the eyepoint.
This works well for the cockpit.
But then the ground jitters a bit below the aircraft. With our default views
you can't see that, but that F-18 has a camera view below the left engine
intake with the nose gear and the ground in its field of view, here I could
see that.
Having the scenery center constant will still have this roundoff problems, but
like it is now too, the roundoff error here is exactly the same in each
frame, so you will not notice any jitter.
The real solution is now to keep the scenery center constant as long as it is
in a ball of 30m radius around the view point. If the scenery center is
outside this ball, just put it at the view point.
As a sideeffect of now beeing able to switch the scenery center in the whole
scenegraph with one function call, I was able to remove a one half of a
problem when switching views, where the scenery center was far off for one or
two frames past switching from one view to the next. Also included is a fix
to the other half of this problem, where the view position was not yet copied
into a view when it is switched (at least under glut). This was responsible
for the 'Error: ...' messages of the cloud subsystem when views were
switched.
a safe undersleep() to conserve cpu. Essentially we undersleep our target by
just a bit (to avoid the chance of oversleeping.) Then we finish off the
remaining time slice with a busy-wait loop.
Norman Vine wrote :
> Frederic Bouvier writes:
>
>> Quoting Andy Ross:
>>> * Hopefully in a CPU-friendly way. I know that older versions of
>>> the NVidia drivers did this by spinning in a polling loop
>>> inside the driver. I'm not sure if this has been fixed or not.
>>>
>>> From my experience, the latest non-beta Windows NVidia driver seems to eat CPU
>>
>> even with sync to vblank enabled. The CPU usage is always 100%.
>
> Buried in the PPE sources is a 'hackish' but portable way to limit CPU usage if the desired framerate is met
>
> /*
> Frame Rate Limiter.
>
> This prevents any one 3D window from updating faster than
> about 60Hz. This saves a ton of CPU time on fast machines.
>
> ! I THINK I MUNGED THE VALUE FOR ulMilliSecondSleep() NHV !
> */
>
> static ulClock *ck = NULL ;
>
> if ( frame_rate_limiter )
> {
> if ( ck == NULL )
> {
> ck = new ulClock ;
> ck -> update () ;
> }
>
> int t_ms = (int) ( ck->getDeltaTime() * 1000.0 ) ; /* Convert to ms */
>
> if ( t_ms < 16 )
> ulMilliSecondSleep ( 16 - t_ms ) ;
> }
>
>
I implemented the method pointed out by Norman. It works great on windows and saves me a lot of CPU cycles. This way, I can get the same framerate in moderately populated areas and have CPU idle 50% of the time instead of wildly looping in the NVidia driver while waiting to sync on vblank.
It has been tested on Linux by Melchior. He saw the same gain in CPU cycles.
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.
Don't overwrite user settings from config files.
fgfs had in any case set bump-mapping to false, no matter if this
node did already exist (because it was defined in a config file).
This is a patch to make display list usage optional. They are on by default.
Use --prop:/sim/rendering/use-display-list=false to use immediate mode.
There is also a change in exception handling in main.cxx and bootstrap.cxx
Split up main.cxx into a program manegement part (which remains in
main.cxx) and a render part (the new renderer.?xx files). Also turn
the renderer into a small class of it's own. At this time not really
exctining because most of the stuff is still global, but it allows us
to slowly migrate some of the global definitions into the new class.
The FGRenderer class is now managed by globals, so to get the renderer
just call gloabals->get_renderer()
At some pijt it might be a good idea to also turn the remaining code in
main into a class of it's own. With a bit of luck we end up with a more
robust, and better maintainable code.
1. The listener is always positioned at the origin.
2. All sounds eminate from the aircraft's model position.
3. Sound positions are relative to the listener location.
my code was accidentally drawing the cockpit twice
in view 0. This patch should fix the problem of
lights not seen through canopies or prop discs.
It was also drawing the lights ( ground and rw )
after the clouds, so they were not obscured by
them.
I restored the output to cout / cerr
for the options and the warning for the version mismatch.
There is a dummy SG_LOG to allow the windows version to
popup the console.
The snapshot rendering use multipass now.
