forums.ps2dev.org

[Shazz]

I was wondering if ODE examples should compile, I've got this pspgl error :

[Grom]

It gives the same error on my system.
(Windows XP, cygwin)

[mrbrown]

According to the commit message for rev 1232:

[AnonymousTipster]

Aha, you too eh?
Have you actually ported ODE, or are you just trying the samples?
I've got a running port of ODE, and i'm currently working on a game. If anyone's interested, I'll release the ODEPSP library to the public.
EDIT: Just to prove i'm not lying:


EDIT 2: I see, I didn't notice that there was a ps2 port of ODE. Oh well.

[jsgf]

Yeah, I wasn't quite ready to announce the SVN tree for general consumption, but its all basically there. The only test programs which are usefully working are the test_chain* ones.

All the tests rely on OpenGL, but ODE itself doesn't.

The crash test runs, but ironically, crashes after the first frame. I haven't looked into why yet.

From the look of it, ODE should be a good candidate to use the VFPU, since the core math is all matrix stuff.

AnonymousTipster, did you have to do much more to ODE? So far, I've found it has been mostly a matter of getting it to cross compile, with no other deep changes. If you have other changes, perhaps you can contribute them to the SVN tree.

[AnonymousTipster]

I haven't changed very much source-code wise, I'm not using a compiled library, I have all the files in a folder named ode, and my makefile assembles all the source files into .o files, and links them with the program at compile. The advantage to this is that it lets you change some of the source code, and compile it with the app, rather than re-compiling the library.
Whilst porting ODE, the only problems I had involved getting C++ code to work properly, because the files were mostly C++, but a couple were C. That made the compiler do some very weird things, including reading all the files back-to-front! All this means is that any program that uses ODE needs to use .cpp, and not .c. I think that using extern "C" is OK though.
The worst problems I encountered weren't to do with getting it to compile, it was getting the simulation to behave. It took me a while to get the sample in the photo (dropping cubes onto a plane) to work at a decent framerate.
In my sample code, I have a couple of helper functions which take an ODE Body and return a PSP GU matrix (much like the routine in DrawStuff), which makes implementing it with the PSPs native functions quite easy.

As for porting the ODE samples, they may prove useful to show how it integrates with PSPGL, but the physics in them are often non-applicable or non-compileable. For example, there is a buggy sample which is supposed to show how vehicles work. It has three wheels. Theoretically, it should be easy to add on another wheel to make a car, but it requires a LOT of tweaking (as I found out), because you can't get the two wheels to turn exactly in parallel, so they fight each other and end up launching the vehicle into the sky. The sample i've used I made from scratch, but borrowed the near_callback function. It's about as simple as you can get for showing how to init the GU and ODE, getting them to work together.

Phew, that was a long post ^o^. Anyways, I'll upload the files to my server and make a thread about it tomorrow (GMT).

[bengarney]

Are you capping at 60fps, or is that just a refresh/synch issue?

(The reason I ask is because if you want your whole game to run at 30fps, you usually want each component to be running at 100+fps.)

I'd be really interested to see what sort of optimizations to ODE you could do with the VFPU. Speaking of it, are there any examples on how to use the VFPU?

[AnonymousTipster]

It depends on the load, in the game I working on with it, it can go up to 100fps, but usually hovers around 70.