ODEPsp (Alternate Version)

[AnonymousTipster]

As promised, here is the source code to my ODE port. I have tested this, and it seems to work quite well, here is some info about the port:

-All ODE source code in one folder, making changes easy
-Sample demonstrates setting up 3D world with textures and mipmapping
-Sample demonstrates dropping cubes onto a plane using ODE and it's integration with GU functions
-ODE source includes convex mesh source, but it is not linked because convex meshes are almost impossible to use because of their stability problems. Also, this reduces EBOOT size slightly.
-Sample currently runs using frame time as ODE parameters, this can make the framerate jump about, but keeps it as high as possible. Using the alternate method (fized timestep) gives a stable 40-60 FPS, whereas framerate timestep can give 30-100FPS.
-There is some commented out source code for arranging the blocks in a wall, rather than a tower. This is included for learning purposes, and needs tweaking to become stable.
-Sample includes helper functions that return a PSP matrix from an ODE body, making GU integration easy.
-Sample includes a Pause/Unpause simulation button to compare Framerates of ODE with purely graphical load. (And it makes for some fun bullet time effects)

Download link: www.anonymoustipster.com/ODEtest.zip

Someone suggested that this sample should go into SVN; I gather that there is a direct port of ODE already in SVN, but there are questions about it's compilability.
If Oopo, Oobles, or whoever co-ordinates SVN thinks it would be worthwhile to put this in SVN, then I'd love to hear from you.

Hope you find this interesting, AnonymousTipster.

[Oobles]

I would prefer people work together to make one port best. However, if there are reason that two separate ports are required or useful then I won't stand in your way. :) If you'd like SVN write access send me a PM and I'll set it up for you.

David. aka Oobles.
http://www.livemedia.com.au/Blog

[AnonymousTipster]

I agree that it's silly to have two versions in SVN, because it could prove confusing. The difference between the two ODEs is that mine works off the GU functions, and the current SVN ODE uses a library called DrawStuff which uses PSPGL.
I am curious as to whether anyone has got SVNODE working on the PSP, or whether it isn't fully usable because of the DrawStuff library and samples causing problems.
If someone who has used SVNODE has an opinion on this, I'd like to know. I won't put my port into SVN unless it is more useable than the one currently in there, because it would just add to the confusion if there are two seperate ports.
The reason that it might be useful to add this release is because it is very easy to modify the engine itself, and when the VFPU is useable, anyone with access to SVN can update the engine and make it faster.
Again, if someone could give an educated opinion as to which engine would be best for the repository, please post here.

[rinco]

Integrating the Gu should be as simple as adding a gu.cpp to drawstuff/src/. You shouldn't need to rename .c to .cpp and eliminate the drawstuff lib.

[AnonymousTipster]

It depends whether you want to use DrawStuff or not. I didn't.

[Grom]

Great work!
I will test it at monday! ODE isn't a best physics engine but it works!!

thanks.

[jsgf]

Is the PSP ODE less stable than the same code compiled for single-precision on a desktop? If so, that suggests a library/compiler problem, because single precision FP should be the same otherwise.

[AnonymousTipster]

I've never tried ODE on Windows (I prefer Tokamak) but I've heard that it is rather unstable on a windows environment, but I don't know why that would be.

[mrbrown]

Direct3D breaks a great many libraries that aren't expecting it to change the FPU control word :P.

[AnonymousTipster]

Ah, that would explain it then.

[ector]

And that's why there's a flag you can pass D3D to not change the FP control word.

The reason D3D changes the control word by default is because some very "clever" (*cough*) people change it to raise exceptions on bad floating point values. Some graphics drivers are badly written and may cause bad floating point values, and crash... Well at least that's what I heard :P

Another reason that D3D changes the control word is that on older CPUs, having the fpu word not set to full precision causes division, sqrt and sin/cos and similar to run faster.

[mrbrown]

And that's why there's a flag you can pass D3D to not change the FP control word.

That flag is useless when using middleware that doesn't allow you to pass it... :P

Sorry for going OT.