New Port : Egoboo2x


Will there be a way to put all the files in some kind of "container" Format which can be used directly by the game? (wink to the devs ;) ) I remember well on the good old Quake-engine "pak"-formats... :)
Sadly, many GP2X games have this problem with zillions of files (sokoban...) or uncompressed file-formats (.bmp, .wav...)

We've done this one before
 
Last edited by a moderator:
The question is, how can one contribute to gpu940/egoboo2x and push features forward? rixed you've done a great job on this port - do you have any sort of organized idea what should happen next to make things smoother/better? Got some clues about things to be done in the gpu940 lib and/or egoboo2x to push the lib further so that we get some great new features on the 940?

For the gpu940 to be more usefull for porting other products, we need a better openGl support.
For now, that means supporting properly OpenGl alpha blending, and support for texture+color rendering (so that we can have lights in Egoboo).

For egoboo2x to be a better "demo" of gp2x capabilities, we also need to release the pressure on the 920 : I think the first thing that should be done is to remove completely all floating values (md2 format internaly uses fixed point, then egoboo convert to float for some
calculus and because vanilla OpenGl requires floats, then gpu940 OpenGL headers convert everything back to fixed !

In theory, the 920 should be waiting the 940 most of the time, and should run underclocked.

I'm writing a doc for gpu940 to help people who want to help :)
I will post a link when it's done (give me some few days).

About complaints for the number of files : I have no opinions about weither an app should have many small files or a big one. I think this is a design decision that have little to do with performance. This is not the problem (nor the fault) of Egoboo's coder (which is not me) if your operating system/file-system is slow on small files. I recommand changing both : Perhaps by using an Unix on your PC and ext2 on your SD, things will be faster ? It never took me more than a few minutes to copy everything on the SD (vfat), by the way.
 
Last edited by a moderator:
The game is crashing less for me, one problem is the camera, seems like it dosent stay locked on to the character. If i go way south or way east I start to dissapear off the camera, then I dunno what the heck is hitting me ...
 
Re small files, I've no problem with the copying time. I am frustrated that because they're all smaller than the cluster size (and since my SD cards aren't turbo, I can't use too small a cluster size, since it slows down access that's already comparatively slow), the resultant size on disk is just shy of 100mb!

Consider that the meaningful data is about 20mb, and that's a lot of wasted space!

That does not detract, of course, from the amazing achievement of getting a game as graphically splendifferous as Egoboo to run on the 2x, and using the 940 properly to boot. Idd, have you tried (just out of interest) seeing how fast it runs if you run it at a higher res and pass it all to the scaler? I imagine a lot slower, but since it's YUV you would get proper filtering, unless I'm much mistaken, which could make a pretty game even prettier :)
 
Re small files, I've no problem with the copying time. I am frustrated that because they're all smaller than the cluster size (and since my SD cards aren't turbo, I can't use too small a cluster size, since it slows down access that's already comparatively slow), the resultant size on disk is just shy of 100mb!

Consider that the meaningful data is about 20mb, and that's a lot of wasted space!

That does not detract, of course, from the amazing achievement of getting a game as graphically splendifferous as Egoboo to run on the 2x, and using the 940 properly to boot. Idd, have you tried (just out of interest) seeing how fast it runs if you run it at a higher res and pass it all to the scaler? I imagine a lot slower, but since it's YUV you would get proper filtering, unless I'm much mistaken, which could make a pretty game even prettier :)
that sounds like a good idea, actually.
 
Last edited by a moderator:
Idd, have you tried (just out of interest) seeing how fast it runs if you run it at a higher res and pass it all to the scaler? I imagine a lot slower, but since it's YUV you would get proper filtering, unless I'm much mistaken, which could make a pretty game even prettier :)

You propose to trade fps against proper filtering ??
 
Last edited by a moderator:
For the gpu940 to be more usefull for porting other products, we need a better openGl support.
For now, that means supporting properly OpenGl alpha blending, and support for texture+color rendering (so that we can have lights in Egoboo).

For egoboo2x to be a better "demo" of gp2x capabilities, we also need to release the pressure on the 920 : I think the first thing that should be done is to remove completely all floating values (md2 format internaly uses fixed point, then egoboo convert to float for some
calculus and because vanilla OpenGl requires floats, then gpu940 OpenGL headers convert everything back to fixed !
Did you consider focusing on OpenGL ES? For a small device it makes much more sense (even the PS3 uses it instead of OpenGL :D).

Plus add there is an open source project that looks rather advanced here Vincent. Just found it is even supposed to have gp2x support.
Perhaps should you consider merging with the team ;)
 
Last edited by a moderator:
For the gpu940 to be more usefull for porting other products, we need a better openGl support.
For now, that means supporting properly OpenGl alpha blending, and support for texture+color rendering (so that we can have lights in Egoboo).

For egoboo2x to be a better "demo" of gp2x capabilities, we also need to release the pressure on the 920 : I think the first thing that should be done is to remove completely all floating values (md2 format internaly uses fixed point, then egoboo convert to float for some
calculus and because vanilla OpenGl requires floats, then gpu940 OpenGL headers convert everything back to fixed !
Did you consider focusing on OpenGL ES? For a small device it makes much more sense (even the PS3 uses it instead of OpenGL :D).

Plus add there is an open source project that looks rather advanced here Vincent. Just found it is even supposed to have gp2x support.
Perhaps should you consider merging with the team ;)
Vincent has poor gp2x support. IIRC, they just released one beta and then ended support, it never ran very fast.

Rixed's project is different from OpenGL ES in that his functions are optimized for the gpu940, making them work differently than ES and the option of merging impossible.
 
Last edited by a moderator:
Also this is still software based OpenGL, ES relies on hardware support. This is a new chapter for the 940 though :) With a lot of work, some of my scene demos may even run on the GP2X, now that would be sweet, if for nobody else but me ;)
 
Vincent has poor gp2x support. IIRC, they just released one beta and then ended support, it never ran very fast.

Rixed's project is different from OpenGL ES in that his functions are optimized for the gpu940, making them work differently than ES and the option of merging impossible.
It's not because Vincent has poor support for the gp2x that OpenGL ES is not better than OpenGL for the gp2x.
OpenGL ES has been designed for embedded platforms which the gp2x is, whereas OpenGL was designed with workstations in mind. In particular OpenGL relies on double, while OpenGL ES has fixed-point.

My point is not that gpu940 should become a compliant OpenGL ES implementation, but rather it should aim at OpenGL ES instead of OpenGL. Moving an OpenGL to an OpenGL ES application can be done and has been done, for instance Q3CE.

And no I don't mean Q3 will run on the gp2x with an acceptable framerate without HW 3D :D
 
Last edited by a moderator:
Well, just a thought. Obviously, fps is a lot more important, but if you're in YUV country already, it crossed my mind that you might be able to make use of the features the 2x has for YUV that it doesn't for RGB, whether or not it would be a good idea.

Although, if I'm following along the same train of thought, it strikes me that you'd be able to get the whole thing smoothed relatively problem free by using any 4:3 non 320x240 resolution - say, 350x262 - as the framebuffer, and feeding that to the scaler. Wouldn't add any *detail* but would mean the scaler had to add an effective blur and remove sharp edges and such. Maybe. Maybe not - as I always say at this point, I'm not a coder, and I'm just throwing up an idea that probably wouldn't work. But if it did in principle, it presumably wouldn't cost too many fps for the additional 2620 pixels. Maybe.

Ok, this is probably rubbish. Ignore unless it sounds interesting, ok? Very fun game, in any event :)
 
X-moto is cross platform "2d" game where you move a dude on a dirt bike around a map to find tokens. You get to all the tokens then you have to find a final token which ends the level. The game plays in a cross section type view, but the biker is 3d. Here the site http://xmoto.sourceforge.net/

The biker is strictly speaking not in 3d. It is a (small) set of textured polygons that rotate.
Furthermore, there is a -ugly option which removes all fancy opengl effects. It looks like a very good candidate for gpu940.
 
Last edited by a moderator:
Re small files, I've no problem with the copying time. I am frustrated that because they're all smaller than the cluster size (and since my SD cards aren't turbo, I can't use too small a cluster size, since it slows down access that's already comparatively slow), the resultant size on disk is just shy of 100mb!

Consider that the meaningful data is about 20mb, and that's a lot of wasted space!

I found that also with one of the Sokoban games available on the file archive - 800 levels files all of less than 1kb each - meant that 3mb of actual data expanded to over 30mb due to cluster size. Even on a small cluster size (4kb) that would still be a hell of a lot of bloat.

I know it's been discussed before, but there doesn't seem to have been any result to that discussion.

I know for certain that my first "port" will use packed files :)

D.
 
Last edited by a moderator:
Did you consider focusing on OpenGL ES? For a small device it makes much more sense (even the PS3 uses it instead of OpenGL :D).

I would certainly consider opengl-es if I was planning to write a game for the gp2x.
But I did not write Egoboo, I ported it, and unfortunately it needs plain OpenGL not the ES restriction.

At first, I only implemented opengl-es. But I did not find any interresting open source program that uses this library.
That's why I started to add the missing OpenGL calls.

Plus add there is an open source project that looks rather advanced here Vincent. Just found it is even supposed to have gp2x support.
Perhaps should you consider merging with the team ;)

Vincent focus on cross-platform opengl-es compliant implementation, while I just want a fast 3d renderer for the GP2X, so I don't think we could merge. I'm really not interrested in GL-ES standards compliance, what I want is to hack the gp2x :)
When I started gpu940, supporting OpenGL was not even planned.
 
Last edited by a moderator:
You made a great choice with Egoboo as the first port. Thanks again.

Love to see what else comes along using gpu940!
 
I have to do some change in the GPE to work on my GP2x MKI but realy impressive realise ;) Some stability problems and a lot of batterie consumption ^^ (920 at 266 and 940 a 250 in default mode ^^)

#!/bin/sh

chmod a+x egoboo load940 stop940
sync
#./cpu_speed.gpe --cpuclk 260
./load940 gpu940_225
sleep 1
./egoboo >/tmp/egoboo.log 2>&1
./stop940
cd /usr/gp2x; ./gp2xmenu

The only thing that I don't get is why there are 250mhz and a 225 mhz versions, but no 240mhz version...

But, this is a very nice game, I can't wait to see what the future holds for OpenGL GP2X games/apps!

By the way, nice job!
 
Last edited by a moderator:
Back
Top