time' code paths. The problem may lead to skipped fdm updates at very high
frame rates. The most visible effect of that was that the aircraft
slips backwards wrt the forward moving carrier.
Remove unused stuff.
Modified Files:
configure.ac projects/VC7.1/FlightGear.vcproj
projects/VC8/FlightGearLib.vcproj src/Cockpit/cockpit.cxx
src/FDM/Makefile.am src/FDM/flight.cxx src/FDM/flight.hxx
src/FDM/SP/Balloon.cxx src/FDM/SP/BalloonSim.cpp
src/FDM/SP/BalloonSim.h src/Main/Makefile.am
src/Main/fg_init.cxx src/Main/main.cxx src/Time/Makefile.am
Removed Files:
src/Time/fg_timer.cxx src/Time/fg_timer.hxx
coordinates that were set relative to the aircraft's position
are picked up before the view update rather than the next cycle.
This avoids ugly fluttering of "passengers" at higher speed.
stabilize some of the odd artifacts we were hearing, that were especially
noticable in clean sound samples like the stall horn or the marker beacon
codes. The change still preserves the doppler effect and maintains the
good work of a previous developer figuring out how to align the model and
listener velocity vectors correctly.
- Runways are now part of an airport, instead of a separate list
- Runways are no longer represented as a boring struct, but as a class
of their own.
-Improved runway access to unify various runway access methods.
CameraGroup supports cameras opened in different windows or in the
same window, with flexible view and perspective specification.
Clean up mouse click handling via osgViewer. Don't let any camera
"have focus;" this forces events to be reported in window coordinates
and simplifies life. Don't use the osgViewer::View::requestWarpPointer
method; instead use our own code which only deals with window
coordinates.
Make glut and sdl versions work with CameraGroup too.
* experimental clean-up / reduction on two of the FG headers:
(I'm going to await feedback on the developers list before doing more of
these, to avoiding going over files multiple times, but in principle it
seems pretty straightforward.)
* final fixes for SG_USING_STD removal
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.
- remove the OSX_BUNDLE crap *I* introduced years ago - we're always a a bun
dle on Mac now.
- fix up the default fg-root on Mac to be FlightGear.app/Contents/Resources/
data - i.e the location used by the macflightgear.org distro, and indeed the obv
ious 'correct' location. Not sure why I didn't use that in the first place, back
in the day.
- remove the CPSForegroundEnable hack. For one thing, we're a bundle and don
't need it, and for another, osgViewer on Mac does the same logic using a newer,
public API rather than a hack into the OS.
- remove the strange logic for doing fgOSInit 'early' (in bootstrap rather t
han main) when running from the command line on Mac; again this is obsolete, and
no one seems to know why it was ever necessary. I guess it was an interaction w
ith SDL when running without a bundle.
- (not Mac related) remove obsolete code bracketed by ENABLE_PLIB_JOYSTICK a
nd USE_GLIDE (neither of which are ever set, even from config.h that I can see)
in main.cxx
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.
From Till:
i started the project at the end of february with a simple idea: move all
3d-model loading to the DatabasePager-thread. my first attempts looked
promising, though they were a little too optimistic (or naive?). the patch
has evolved a lot since.
currently it does the following things:
1. revive SGModelLib, move functions for xml-model-loading there
2. replace all calls to sgLoad3dModel with calls to either
SGModelLib::loadModel() or SGModelLib::loadPagedModel()
almost all models will be loaded by the DatabasePager. the few exceptions are:
your own plane, shared models in scenery, random objects, AIBallistic models.
3. simplify mode-loading functions (avoid passing around fg_root)
4. avoid supurious MatrixTransform nodes in loaded models
5. fix some memory leaks
Reindent to Stroustrup style.
Make FGPrecipitationMgr an SGSubsystem and remove all references to it
in main.cxx and renderer.cxx.
Use SGGeod::makeZUpFrame instead of a private function in
tileentry.cxx. Rewrite that function, WorldCoordinate, to use
makeZUpFrame too.
This allows Nasal managed views thanks to the proximity of the
event manager (which executes Nasal loops). The io manager must
come after the view manager to avoid jitter in network replay.
Make an OSG file reader for .stg files.
New class flightgear::SceneryPager, which is a subclass
osg::DatabasePager to handle explicit delete requests.
Modify FGNewCache, FGTileEntry, and FGTileManager to use
SceneryPager. Mostly this involved removing the queues that talked to
FGTileLoader.
Calculate accurate tile timestamps from the time they are traversed in
the cull stage (which means that they are visible) instead of updating
them periodically.
Replace tile entry transform and range node with one LOD node
This removes some jitter in cases where Nasal is used to set up view
parameters from FDM data, such as position and orientation. (The event
subsystem handles Nasal's settimer() calls.)
/sim/screneryloaded-override was "true". At least one subsystem (od_gauge)
waits for /sim/sceneryloaded to bypass CPU intensive code until the scenery
is up. This broke e.g. the RTT-radar when using /sim/screneryloaded-override
--prop:sim/sceneryloaded-override=true has the effect that fgfs
doesn't show the splash screen until the scenery is loaded, but shows
the OTW view (scenery/aircraft) at the earliest possible moment. This is
useful for developers who often need to run fgfs only to check some minor
detail, while not caring about stuttering caused by scenery loading.
configure.ac src/Main/Makefile.am src/Main/fg_os.cxx
src/Main/fg_os.hxx src/Main/fg_os_sdl.cxx src/Main/main.cxx
src/Main/renderer.cxx src/Main/renderer.hxx
src/Network/jpg-httpd.cxx
Added Files:
src/Main/FGManipulator.cxx src/Main/FGManipulator.hxx
src/Main/fg_os_osgviewer.cxx:
Tim Moore: Make use of osgViewer.
"FATAL: PUI: No Live Interface! Forgot to call puInit ?"
We shouldn't use the splash progress message before guiInit().
Leave the "idle_state" step for now, to keep the similarity
with fg/plib as big as possible. This can be dropped later.
(this was the reason why the first two text lines on the splash screen
looked more blurry than the others). BTW: I played with other values
than -0.5, but this turned out to be the best already. It makes textures
sharper than 0, but not too sharp (and thus flickering).
I attach 2 new files and a diff file for the associated changes to add a
“fluxgate compass” to the instrument inventory. Whist this outputs
essentially the same data as /orientation/heading-magnetic-deg, it has to
be powered, and can be made to fail. I also followed Roy’s suggestion to
generate the error properties for this instrument here rather than in
xmlauto.xml.
When this instrument is included in cvs, I intend to use it in the Hunter,
A4F Seahawk and KC135. After a bit more research, it might be appropriate
for the Spitfire and Hurricane as well. AJ would also like to use it for his
Lightning model.
src/AIModel/AIAircraft.cxx src/ATC/AILocalTraffic.cxx
src/FDM/flight.cxx src/FDM/flight.hxx src/FDM/groundcache.cxx
src/FDM/groundcache.hxx src/Main/fg_init.cxx src/Main/main.cxx
src/Scenery/hitlist.cxx src/Scenery/hitlist.hxx
src/Scenery/scenery.cxx src/Scenery/scenery.hxx
Make use of the attached SGMaterial reference userdata on scenegraph
leafs. Make the SGMaterial pointer available to the ground query
routines.
The new multiplayer patch with an extension to transmit some properties with
the base package. The properties are transmitted in a way that will not
immediately brake the packet format if we need new ones.
Even if the maxmimum number needs to be limited somehow, that format might
work well until we have an improoved packet format which is even more compact
and that does not require to retransmit redundant information with each
packet.
That part is relatively fresh and based on that what Oliver provides on his
multiplayer server web page.
The properties are transferred to the client and I have modified the seahawks
rudder animation property to use a relative property path to verify that it
works appart from the fact that you can see it changing in the property
browser.
The movement is still a bit jerky, but that can be fixed/tuned later without
again braking the packet format.
This patch limits the maximum simtime we do simulation computations for.
That is highly sensible if you run flightgear in valgrind or some realy slow
debug build. In such a case it is possible that flightgear gets totally
unresponsible, because simulation time might increase slower than real time.
That patch introduces a maximum simulation time per rendered frame to limit
that effect.
If the property /sim/max-simtime-per-frame is set to something strictly
positive, the simulation time is limited to that value.
The default is unchanged - no limit.
Anyway, from the point of view of gui responsiveness and responsiveness to
realtime controls like joystick inputs it might be a good idea to limit that
by default to say 1 second. If you have less than 1fps, flightgear is
unplayable anyway and I believe we do not longer need to care for realtime
correctness for that case ...
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
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.
FG_ENABLE_MULTIPASS_CLOUDS must be defined to enable
the algorithm. I made this because the stencil buffer
must be initialized at the beginning of the program and
OpenGL can fallback to software rendering if it can't
find a visual with stencil buffer. I didn't touch the
configure script, so CXXFLAGS=-DFG_ENABLE_MULTIPASS_CLOUDS
must be set before running ./configure.
If FG_ENABLE_MULTIPASS_CLOUDS is defined, the main render
loop begins by reading the /sim/rendering/multi-pass-clouds
property. It is a boolean property so there are only two
quality levels. false means no multi pass and no use of
the stencil buffer, true means an additionnal pass for
both upper and lower cloud layers.
The algorithms are as follow :
/sim/rendering/multi-pass-clouds=false
1. draw sky dome
2. draw terrain only
3. draw clouds above the viewer
4. draw models except the aircraft
5. draw clouds below the viewer
6. draw the aircraft.
The cloud rendering doesn't update the depth buffer.
This means that models overwrite clouds above the viewer.
This is only noticeable for tall buildings and when
flying very low. Also, drawing low clouds after models
means that they are not blended with models' translucent
surfaces. Large transparent area require alpha test
enabled and AI aircraft canopy are making holes. The
pilot's aircraft being rendered at the end, there is no
problem with canopy or prop disc.
/sim/rendering/multi-pass-clouds=true
1. draw the sky dome
2. draw the terrain only
3. draw all clouds
4. draw models except the aircraft
5. redraw the clouds where the models where drawn ( stencil
test on )
6. draw the aircraft
The assumptions made by this algoritm are that the terrain
is not transparent ( should be true in all cases and
that there are no clouds between the aircraft and the viewer.
Assuming these facts, there should be no blending bugs.
The screenshot rendering is not updated yet.
trying the --show-aircraft option, I noticed that I had
no output. This is because there are still output to
cout or cerr, that are not triggering my console patch
for windows. The patch attached use SG_LOG instead.
A request to hit a key is also added because otherwise,
the console window will disappear as soon as the program
stop.
This problem is minor though given the fact that fgfs.exe
is shipped with fgrun that do show the available aircraft
in a much nicer manner.
