[ODE] Visual Studio project files and small bug in test_buggy?
Frank Compagner
Frank Compagner <frank at compagner.com>
Wed May 7 15:38:02 2003
Hi,
i've just finished creating MSVC 6 project files, roughly according to
the recipe at: http://q12.org/cgi-bin/wiki.pl?Building_ODE_With_MSVC6
I did split it up into three projects, though: one for ODE proper, one
for Drawstuff, and one for the test app. This way, to add ODE to
another app, you just need to add the Ode.dsp project, add the include
dir and you're set. Debug and Release Configurations will be linked
correctly, and ODE debug info and browse info will be automatically
available. I did have some problems using make (specifically, my app
would crash in atexit()), which have been cleared up by this. I think
this might have to do with the fact that i have about 9 different
compilers and linkers in my PATH alone, so there was possibly some
make confusion.
What i would like to do is to add all the test apps to the MSVC
workspace, make sure all the project settings are nice and tidy
and upload them to the Wiki pages. Then i'd like to update the
description at http://q12.org/cgi-bin/wiki.pl?Building_ODE_With_MSVC6
to reflect the changes (and to provide a link to the workspace files
of course). Does anybody have a problem with this?
I'll also take a look at the MSVC 7 project files to see how they
work. What might be a nice idea if the resulting project files were
added to the next distribution of ODE as (eg.) Vc6.zip and Vc7.zip,
this would likely save newcomers quite a bit of time. Sdl and Ogg-
Vorbis do it this way too. What do you think? Finally, i would also
like to be able to switch between float and double with a single
#define, but maybe that isn't quite compatible with make configure.
That way, it would be possible to have a Ode_Single.dsp and
Ode_Double.dsp for easy selection of your precision. But maybe that is
pushing it a bit too far.
And while building test_buggy, i ran into a smallish bug in the
cleanup code. No idea if this know/fixed, but for what it's worth:
Right now it says (at the end of main()):
dSpaceDestroy (space);
dWorldDestroy (world);
dGeomDestroy (box[0]);
dGeomDestroy (sphere[0]);
dGeomDestroy (sphere[1]);
dGeomDestroy (sphere[2]);
But that crashes (for me at least) because the body attached to box[0]
has already been deleted by the call to dWorldDestroy when dGeomDestroy
tries to destroy it a second time. Changing it to:
dGeomDestroy (box[0]);
dGeomDestroy (sphere[0]);
dGeomDestroy (sphere[1]);
dGeomDestroy (sphere[2]);
dSpaceDestroy (space);
dWorldDestroy (world);
fixed it.
Frank
-------------------
frank@compagner.com