the cause for the disappearing shadows is, that SimGear doesn't tell plib
to call the pre-traversal-callback function on culled objects. These calls,
however, are necessary to execute the transform animation that does, for
example, translate a shadow back into the frustum! Curretnly, the callback
is only executed, and the shadow only magically pops up again, when the object
enters the frustum because the view has changed significantly.
The plib documentation does only talk about TRUE and FALSE for possible
return values from the pre-traversal-callback. But src/ssgEntity.cxx reads
like this:
int ssgEntity::preTravTests ( int *test_needed, int which )
...
int result = (*preTravCB)(this,which) ;
if ( result == 0 ) return FALSE ;
if ( result == 2 ) *test_needed = 0 ;
...
So the return value needs to be 2 to bypass the cull test for pretraversal,
and get the pretraversal in any case. I only changed the return values in
four animations: scale, rotate, translate, and range, because these are
the most likely to move an object out of the frustum. It's not necessary
for blend/alpha/texture manipulation etc. Of course, this is a bit more work
for plib, but the performance will probably not be affected, because:
* these four animations are mainly used for the aircraft model (the spin
and billboard (trees!) animations are not affected)
* the number of extra nodes to process is quite low
* a part of the time spent for the extra nodes to be processed, was before
used for workarounds that are now not necessary any more
I didn't observe a frame rate drop, at least.
code generation of constant objects to use real identity and not Nasal
equality, so (e.g.) the constants 1 (number) and "1.0" (string) do not
get turned into the same object in the generated code.
This patch adds support to the model animation system for modifying emissive
states on the fly so that it is possible to make "lights" appear to dimm.
This is an example of a configuration entry which should explain how it is used:
<animation>
<type>material-emission</type>
<object-name>Face</object-name>
<property>/controls/lighting/instruments-norm</property>
<emiss-red>1.0</emiss-red>
<emiss-green>0.8</emiss-green>
<emiss-blue>0.5</emiss-blue>
</animation>
Note the color entries are the emissive colors when the "property" value is
1.0. They are useful for tinting the light. The "property" itself must be
float or double and is clamped to values between 0 ~ 1.0 inclusively. The
"property" value is multiplied against the colors to get the actual material
properties. Thus property value 0.0 = darkest, and 1.0 = brightest.
If alcOpenDevice( NULL ) is NULL, then context is never assigned a
value, and it's pointless to ask for it in the next "if". But as the
ALCcontext that context points to doesn't seem to be fully defined
(OpenAL bug), valgrind still complains ...
Erik Hofman:
Extend this some further and define context=0 otherwise and check for
context != 0 before using it.
Trying to find the bug in tower.cxx (that crashes fgfs quite frequently
for me!), I'm playing with valgrind again. Until I'm in the ATC subsystem
there will be some other bugs and nitpicking along the way.
valgrind doesn't like that imgage->tmp is once allocated with new and
once with new[], sometimes with malloc() (via map), and sometimes freed
with delete (not delete[]!) and sometimes with free(). With simple types
such as GLubyte this shouldn't really make a difference, but anyway.
Also, I promised that I'd send patches for "if (foo) delete foo;" as
I'm making other changes to concerned files. texture.cxx is one with a
few occurrences thereof. (Remember: C++ explicitly allows to delete
null-pointers, so this check is redundant, and hence not tolerated in
other projects, such as KDE. Doesn't have to impress us, of course. :-)
Also, fixes 4 signed/unsigned warnings (gcc 3.3.4)
The error properly belongs to the enclosing scope, not the called
(non-)function. This bug was fixed a few months back in my private
tree, but Melchior just discovered that the new Concorde scripts
tickle it. I really need to re-synchronize SimGear with my own Nasal
tree...
this is the animation code that do randomisation of the spin animation. The XML tags are modified to support the syntax below :
<use-personality type="bool">true</use-personality>
<factor>
<random>
<min>1.8</min>
<max>2.2</max>
</random>
</factor>
<starting-pos-deg>
<random>
<min>0</min>
<max>360</max>
</random>
</starting-pos-deg>
instead of usual :
<factor>1.42</factor>
<starting-deg-pos>42.0</starting-deg-pos>
1. Remove the dependency on alut which (on certein platforms) might pose
some restrictuons on commercial use.
2. Create a sound source just prior to playing the sound and destroy it
again when the sound has stopped. This should greatly reduce the
error reports from Windows users.
The following patches to SimGear & FlightGear ...
- create an FGMetar abstraction layer, whose purpose is:
* provide defaults for unset values
* interpolate/randomize data (GREATER_THAN)
* derive additional values (time, age, snow cover)
* consider minimum identifier (CAVOK, mil. color codes)
- add rain/hail/snow/snowcover support on the METAR side
- add max age of METAR data handling (currently set to
- add support for an external METAR cache proxy server
- add CAVOK handling
- set missing year/month in regular METAR messages
- fix a small bug in metar.cxx (wrong return value)
