jump whenever you cross a tile, but there are currently a lot of other
positioning problems as well, so this doesn't really detract too much and
means you can play with 3d clouds from just about any starting point.
I removed some pending random code and I also fixed a
small cosmetic glitch where dt_play was cleared before it was printed.
Curt: Erik changed the sound update intervale and I further I tweaked it.
The issue is that if we put too much into the sound buffer, then we can't react
quick enough to sounds like tire squeek that need to be synced with the visuals
and the action. We put too little into the sound buffer and we risk the
audio dropping out for moment if a frame takes longer to draw than the amount
of audio in the buffer.
I've modified the code to display a brief help message instead of the
whole bunch of options. To get the complete message -v or --verbose has
to be added to the command line.
Here is a FGIO class derived from FGSubsystem that replaces the fgIOInit()
and fgIOProcess() functions. The FGIO::update(double delta) doesn't use the
delta argument yet. I suspect it could be used as a replacement for the
calculated interval value but I'm not familiar enough with that piece of code
just yet.
I've also added two "command properties" to fg_commands.cxx that select the
next or previous view. Writing any value to these properties triggers the
corresponding action. As an example I modified my keyboard.xml:
<key n="118">
<name>v</name>
<desc>Next view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/next</property>
<value type="bool">true</value>
</binding>
</key>
<key n="86">
<name>V</name>
<desc>Prev view</desc>
<binding>
<command>property-assign</command>
<property>/command/view/prev</property>
<value type="bool">true</value>
</binding>
</key>
And of course these actions can also be triggered from external scripts via
the props server.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
Animations are now contained within the scene graph itself and are
updated whenever the graph is traversed -- that saves time by not
updating animations not currently in sight, and it allows animations
to be used for static objects and random objects as well.
Added new FGModelLoader and FGTextureLoader classes. These are intern
tables for models, to guarantee (mostly) that no model is loaded more
than once. FGTextureLoader is not yet used anywhere, but
FGModelLoader is now in place everywhere that ssgLoad* used to be
used (thus adding the ability to use animations).
In the future, FGModelLoader will add some interesting functionality,
including the ability to reload 3D models on the fly.
I've merged FGProps and FGTelnet so there is just a single property server.
I've left in the --telnet=port# command line option but it could be removed
if we wanted to. The command line accepts two forms of the --props option.
The original (--props=medium,dir,hz,host,port#,style) and the shorter
--props=port#. If you accept this change then src/Network/telnet.[ch]xx
can be removed from the cvs repository.
the triangles containing the objects were out of the view Frustum,
they were never traversed by ssg (and thus, never culled). Now, every
200 frames, do a pass through the whole scene graph with cull-testing
disabled and without drawing anything; that will allow random-objects
to be collected incrementally.
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.
