1. Only one copy of each object (and its texture) is stored in memory,
no matter how many materials use it.
2. Random objects are added to a triangle only when the objects are in
range, and they are deleted as soon as the objects are out of
range. That way, only a relatively small number of ssg nodes are
used at any one time.
This patch seems to eliminate freezes when tiles are freed. There are
occasional stutters at extremely high speeds (i.e. over 3,000kt), but
it seems smooth enough for normal aviation speeds.
- no extra nodes are created at all if the material has no random
objects defined
- the range selector is place correctly under the transformation
- there is only one range selector for each object type in each
triangle (experimental -- doesn't seem to make a difference in speed
or memory)
This patch removes Curt's patch that randomized ranges slightly, since
individual random objects no longer have their own range selectors.
It also leaves the object-group-range value unused, for now.
- tidies up the update-time-step handling (making it a simple "dt");
- makes the altimeter get a proper pressure, and the (unused) vacuum
calculation get a proper RPM (*);
- replaces property name look-ups with static pointers to property nodes.
Notes from DPM:
- the static pointers are a very bad idea, but they're only temporary;
I plan to make FGSteam into a proper subsystem soon, and then they
can be member variables
- I fixed the patch to get the current static pressure from the
/environment/pressure-inhg property, so that the altimeter interacts
properly with FGEnvironment
The present sets of bindings result in the throttle being "squared"
about its centre, which is silly. This is because the "squared"
parameter is not set by the throttle binding, but the default is
"true". We discussed this before and I think there was general
agreement that the default should be "false" on the basis of
generality.
situations for every kind of airplane. But at the moment we have nothing
implimented and this will cover the simpler cases until someone has a
chance to impliment a fuller solution.
GL/gl.h can't be included at the first position in windows. It requires
the inclusion of windows.h that must be included in other fgfs header
file. I only move down #include <GL/gl.h>
This patch eliminates about 10 of valgrind's "Use of uninitialised
value of size ..." messages. They are all caused by approachlist building
incomplete FGApproach class instances and then copying them into the
approchlist container, hence copying data garbage.
I know, I couldn't win a beauty contest with this patch, but the
alternative approach -- letting operator<< always leave complete
entries -- didn't look any better. And I do only add those seemingly
useless initialization where the values would be used uninitialized
else. The constructors are only run during setup and won't slow fgfs
down at runtime.