Xmoto And Opengl Games

[hal9000]

Hello,

Has someone planned to work on a XMoto porting? It is a great little open source physics engine based game and porting should be (I think) pretty straightforward to port, as long as OpenGL is not a problem. I could work on it if I have some time...

I was wondering how advanced were OpenGL drivers right now? Even though this is not the developper track, I would be interested in some feedback about early OpenGL development on Pandora.

Thanks for you answers.

 

[WizardStan]

OpenGL is non-existent. We have OpenGL ES, a version of OpenGL designed for mobile platforms that's not quite compatible with regular OpenGL. Anything that uses OpenGL should be changed to support OpenGL ES before it can run on the Pandora.
There is a wrapper library which seems to be able to take OpenGL and convert it to OpenGL ES calls at runtime, which I think is how Quake is being run, but it's not a guaranteed run, and the wrapper adds its own overhead, so best to actually port to OpenGL ES if possible. Usually it is possible, and should not be exceptionally difficult, just need to find someone to do it.

 

[skeezix]

GL ES is not too bad compared to 'modern GL'; the 'problem' most run into is GL immediate mode (ie: glBegin) is missing, since its a big pita for driver authors to handle gracefully, without code duplication, and without performance problems. So when GL ES was designed, they tossed out immediate mode, though a number of people think glBegin() etc could be implemented in terms of GL ES without too much trouble, I've never looked into it

(I really like immediate mode

jeff

 

[mindlord]

So... Everything has to be done with display lists or what? Ah CRAP. I guess it's going to take some re-writing to port my current project over then. I planned on dropping immediate mode rendering anyway, but I was hoping to save it for the performance tuning phase.

 

[lulzfish]

Display lists, vertex arrays, vertex buffers, whatever works. I don't know if ES supports display lists, but it might. They're a very strange concept and I personally don't like them.

 

[JayFoxRox]

+ you loose the whole fixed function pipeline.

This means you have to put anything into shaders - without shaders you are not able to draw (at least not much.. - clearing etc works, but who draws with that?). This does also mean that you have to do all matrix, fog, lighting calculations etc. on your own.

However, last time I tried it I couldn't get ODE to compile for ARM as it depended on something which used x86 assembly. However it was part of another - larger - project so the code was probably modified.


Cross-compiling libraries is a pain in the arse tho imho, so I'd just wait for the Pandora and try compile all libraries on that, then move them to my dev machine and work from there, if I were you.
I still think the pandora team should have set up a public git which hosts makefiles for common libraries to make cross-compiling easier. I wanted to add that to my Pandora SDK but I just suck with makefiles and I ran into tons of problems as Arch linux doesn't even have a multilib gcc [which is necessary for some libraries during the build steps to generate code.] (I have one, but it's old and some libraries don't like it)

//Edit: Can't remember about displaylists as I never used them. It is recommended that you submit all your data in interleaved indexed vertices as degenerated TRIANGLE_STRIP which are stored in VBOs and IBOs. So even if you use displaylists you would have to create - AT LEAST - a vertex array iIrc.

 

[mindlord]

Meh, maybe I'll just accept the performance hit from wrapping it in NanoGL.

 

[hal9000]

However, last time I tried it I couldn't get ODE to compile for ARM as it depended on something which used x86 assembly. However it was part of another - larger - project so the code was probably modified.

Probably. ODE has been ported to various architectures. It would be great to have it on Pandora. I really believe that physics engines are great for homebrew games.

 

[JayFoxRox]

Physics engines - imo - are cancer for todays video-games.

They are usually very hardware demanding and run out of sync in network, give slightly different results everytime on the host etc. (unless the timestep is fixed, but even then you run into problems with precission and a bit of chaos)
I like most games and I like good physics, but you can't compare yourself to other players anymore. A game should always run the same way imo, unfortunaly most physics engines at the moment make heavy use of approximations and have a dynamic timestep in their samples to run on any sort of machine (which is a bad thing as the game starts to behave differently, personally I'd like to see the framerate drop for slow systems instead if this gives correct results on the majority of all systems).
ODE appeared VERY instable to me. Especially in "Jackass: The game", simply putting the PSP into standby was able to glitch you through objects etc.
Newton is still my fav physics engine, but imo, a physics engine should only be used for visuals, arcade physics which might not be "real" but "exact" and "reproducable" should be used for the game logic.

 

[hal9000]

Try XMoto. It is fun, it is entirely based on score comparison with other players, and I don't think there is any problem with "reproducability" there. The chaotic behaviour starts when too many objects are colliding together.