gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > ODE + NDS (+OPAL)

#68932 - tetsu - Fri Jan 27, 2006 1:32 pm

Ever thought about using your Nintendo DS app with a physics lib? The last few days I've tried to get ODE (www.ode.org, the only open source physics lib I know of) working, and here's the result.

Move around with the arrows, L, R and use 'A' to add a new box and 'B' to make them all spin.

As you can see, after about 10 boxes in motions, the DS really starts struggeling. After a while it completely dies. Well, it's fun to try anyway.

Now, the demo isn't very complexed, we're not talking trimesh-to-trimesh collisions here. Still only with some boxes and some border planes, it gives up. First I thought that ODE probably isn't optimized for handheld devices or low-memory computers. Secondly, I used a wrapper lib called OPAL (opal.sf.net) to make things easier for me. This adds another layer which surely slows down the simulation somewhat. Also with everything in C++ would add a layer of complexity compared to if it was in just C.

But, I think the main reason is just that the NDS simply isn't powerful enough for these types of calculations. Instead, for physics, it would be better to write a specialized engine instead of using a general one like this.

#69017 - acox - Sat Jan 28, 2006 12:03 am

I just ran your demo. _Very_ cool stuff. Running floating point intensive code on a machine with no FPU is never gonna fly though.

Someone needs to code an engine in fixed point and it should be orders of magnitude faster. Vertlet integrator would be a good choice to put in its guts.
_________________
3D on GBA

#69025 - arog - Sat Jan 28, 2006 1:01 am

Here's a screen shot and a .nds version of the file.

[Images not permitted - Click here to view it]

http://www.aaronrogers.com/nintendods/files/ODEcube.zip

- Aaron Rogers
http://www.aaronrogers.com/nintendods/

#69036 - cybereality - Sat Jan 28, 2006 2:13 am

Thats a cool demo. The performance isn't good enough to use in a game, but it does work and can be optimized. I am planning on doing some physics demos on the ds (maybe a library, who knows?). I've got a verlet intergrator I wrote in flash that should be portable to the ds. I figured that porting an opensource physics engine like ODE or Tokamak wasn't possible on ds. It seems that you proved me wrong. Even so, I think a custom physics library specifically built for the ds would attain better performance (at least I hope so). Anyway, nice job.
_________________
// cybereality

#69086 - DaRk_ViVi - Sat Jan 28, 2006 11:48 am

Hmmm, I tried to run your demo but it doesn't started on my M3 CF (two white screens)...

Is it possible to run it on this flash?

Edit: Ok i fixed, i just had to press START instead of A to start a homebrew. :)

It's a great demo. :D

#69151 - tetsu - Sat Jan 28, 2006 8:43 pm

Ah, of course, I'd totally forgotten about the lack of FPU. Well, that would explain it. Still I'm pretty sure you can't get away from floating point calculations when doing physics simulations, but maybe they can be kept at a minimum. I don't know anything about this 'Verlet integrator', but I'll look it up.

Now, certainly ODE is a bit overkill for NDS, I made the demo mostly out of curiosity if it was possible to port both ODE and OPAL. I was expecting it to hold out longer though.

Now I just wonder how the collision detection in, for example, Mario DS works. From what I can see, there's a lot of box-on-trimesh checks every(?) frame. Well, I guess it's heavily optimized for these specific tasks.

#69841 - octopusfluff - Thu Feb 02, 2006 9:02 am

You can often use fixed point math in many places where you would normally use floating point. This obviously isn't useful if you don't know where your precision needs to be, but if you plan ahead you can usually get pretty good performance.
For a general library like ODE, this might not work so well, but specific planned applications (i.e. commercial games with custom engines) tend to do it just fine.

As for the specific collision methods.. Mario 64 could just well be using bounding spheres. For the gameplay in question, that's all you really need.

#130231 - jandujar - Fri Jun 01, 2007 7:37 am

Hello,

I'm trying to compile the ODE library for DS. But it seems something is wrong.

I have compiled the library opcode and then the library ode -> fixing a lot of compilation errors.

I haved build an example called "ejemplo_ode2" that uses the library "ODE" but something is wrong.

I made a square an a plane in the ground. I apply a gravitation and the square fall down, but when it touch the plane it does nothing.

I hope somebody can help me.

Here are the source.,
http://rapidshare.com/files/34203302/libode.tar.gz.html

Maybe tetsu can release the library compiled.
_________________
http://jandujar.homelinux.com
http://www.dsrobot.com

#130232 - OOPMan - Fri Jun 01, 2007 7:48 am

Kudos for managing to actually get ODE up and running on the DS mate :-)

Alas, it isn't anywhere near to being a viable solution :-( But that's already been established :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

#130236 - Ant6n - Fri Jun 01, 2007 10:10 am

octopusfluff wrote:
...
For a general library like ODE, this might not work so well, but specific planned applications (i.e. commercial games with custom engines) tend to do it just fine.
...

maybe one could still do a general library, if the user can define the maximum of variables (postion, velocity, force etc) as macros. if programmed right, one could then ensure that these values dont overflow. this seems like quite a hassle, though.
another approach could be a custom floating point format, i.e. using two words, one as exponent (shift), and one as mantissa; and using a loose rule, like that the highest set bit in the mantissa only has to be in the highest byte, instead of the highest bit. one could also create vectors or matrizes that use the same exponent for all components or rows/columns (but one would need good precision on the mantissa then, i.e. 32 bit).