Destructo2000
Member
Before I was pretty impressed by this game but now I'm beginning to worry. After playing it some more, it has begun to crash almost every time I try to play it.
New Port : Egoboo2x
- Thread starter rixed
- Start date
Parkydr
Developing for the GP2X since 2006
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:
Last edited by a moderator:
rixed
Member
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:
Cervante
PS3 ID: Cervante1
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 ...
halo9
Member
Try holding R and moving the stick, up/down for zoom in/out and left/right for rotate.
Tobriand
Well-Known Member
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
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
sam fisher
Well-Known Member
that sounds like a good idea, actually.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
Last edited by a moderator:
rixed
Member
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:
ldesnogu
Well-Known Member
Did you consider focusing on OpenGL ES? For a small device it makes much more sense (even the PS3 uses it instead of OpenGL
).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:
Yono
Active Member
Vincent has poor gp2x support. IIRC, they just released one beta and then ended support, it never ran very fast.Did you consider focusing on OpenGL ES? For a small device it makes much more sense (even the PS3 uses it instead of OpenGL
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
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:
yodaofborg
Assimilated you will be!
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
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 ldesnogu
Well-Known Member
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
Last edited by a moderator:
Tobriand
Well-Known Member
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
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
hal9000
Member
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:
Dunny
Exophase Approved® Forum Troll
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:
rixed
Member
Did you consider focusing on OpenGL ES? For a small device it makes much more sense (even the PS3 uses it instead of OpenGL
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:
gaterooze
Coltrane Sundia
You made a great choice with Egoboo as the first port. Thanks again.
Love to see what else comes along using gpu940!
Love to see what else comes along using gpu940!
Blah
Wanna Be Programmer
Nice work rixed, although I don't really get Egoboo.
rememberthe8bit
Member
- Joined
- Aug 27, 2006
- Messages
- 231
- Age
- 35
- Location
- Western New York, USA
- Website
- rememberthe8bit.blogspot.com
I have to do some change in the GPE to work on my GP2x MKI but realy impressive realise
#!/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:
