uninitialized data bug in naHash_cget(). When the hashcode field of
naStr was introduced, I forgot to set it in this function, which
creates a temporary naStr on the stack.
but contain <glyph> entries with <name>, <left> and <right>. The latter two
describe where in the texture a letter or symbol begins and where it ends.
(range 0-1). <xscale> defines a horizontal scaling factor.
from provided node
"* minor redundant gl call in DrawCone2 optimized away (twice per frame)
* corrected the glRotatef() order in drawRain even further (a less
obvious mistake than before, which is noticed by looking skywards and wiggling
the mouse in the view direction change mode)
* all the "magic numbers" used in the rain rendering code have been
provided a default (based on the old hardcoded value) in a form of a
define, and a meaningfully named static member in SGEnviro"
subvec() to mean "the whole vector". Melchior showed a use case
(removal of the first element from a vector) where getting a
zero-length subvector is actually desired. And since I can't come up
with a good reason for why the "feature" was there in the first place,
out it goes...
inspect the string pointers. It also failed to properly sort strings
where one is a prefix of the other. It looks to me like I just never
finished this, and it ended up in CVS because it just happened to
compile...
(We are currently getting a lot of aborts in the condition code when
running MP. I don't expect this to fix it, but a bug is a bug.)
(reviewed by Fred, who also fixed *my* bugs :-)
Add MAC OS X Render Texture support:
Most texture modes seem to work on my Powerbook, but I don't have a wide array
of machines to test it on otherwise.
If you have problems, please let me know and I'll see if I can help track down
the source of the bug. I'd love to keep working on it if time permits (I use
RenderTexture in a few other projects), so I'll keep you informed if there are
any changes that I make for the better.
add abstract class SGModelData. If a pointer to such a class is handed over
to sgLoad3DModel, then its modelLoaded() method is called with path, property
node and branch. And then it's added to the scene graph so that it's
destroyed when the model branch is removed from the graph.
modellib.[ch]xx:
only cache objects when asked to. This is the case for OBJECT_SHARED
and random objects (like before), but no longer for OBJECT_STATIC.
These are now removed from the graph when they are "out of sight". This
prevents accumulation of static models, and makes destroying model data
possible (e.g. removing Nasal modules)
matmodel.cxx:
set cache flag for random objects (same behavior as before)
- don't unlock an already unlocked mutex (Someone wanted to be on
the safe side with this, but the result is undefined and makes
pthread_mutex_destroy fail. Reference: manpage for
pthread_mutexattr_gettype/The Open Group[1]: "Attempting to
unlock a mutex of this type which is not locked results in
undefined behaviour.")
- re-enabled all subsystem destructors again (this has been disabled
because fgfs hung on exit, due to the mutex destroy failure from
above.)
Reference:
http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_mutexattr_gettype.html
- new FSF address
- removed a few hundred trailing spaces
- fixed a few $Id$ lines
- copied two license headers from *.hxx files to their respective
*.cxx counterparts
- added two test aps to .cvsignore
- don't unlock an already unlocked mutex (Someone wanted to be on
the safe side with this, but the result is undefined and makes
pthread_mutex_destroy fail. Reference: manpage for
pthread_mutexattr_gettype/The Open Group[1]: "Attempting to
unlock a mutex of this type which is not locked results in
undefined behaviour.")
- re-enabled all subsystem destructors again (this has been disabled
because fgfs hung on exit, due to the mutex destroy failure)
This patch makes use of the vectors now available in simgear with that past
patch. And using that it simplyfies the carrier code somehow.
- Small additional factory's to the quaternion code are done in the simgear
part. Also more explicit unit names in the factory functions.
- The flightgear part makes use of them and simplyfies some computations
especially in the carrier code.
- The data part fixes the coordinate frames I used for the park positions in
the carrier to match the usual ones. I believed that I had done so, but it
was definitly different. Also there are more parking positions avaliable now.
mfranz