GP2X Tinygl Ported To Gp2x


Pryankster

Still Fresh
Joined
Jan 23, 2006
Messages
5
I've ported TinyGL (Homepage here) to the GP2X. My port is very basic right now, and uses rlyeh's minlib for drawing.

Future improvements will include fixed point support and probably offloading most of the computation to the second processor.

The 'gears' sample runs at about 10 fps. The texobj sample runs at about 25 fps.
The mech sample runs at about 5 seconds per frame :-(

You can find it Here.

Please forward any changes to me, and I'll integrate them.

--pryankster
 
Well the ramafactions for this are huge! Wonderful! Does this mean taht Flash has a better chance of being succesfully ported? As I know a lot of the open-source flash players use OpenGL
 
Not only that... but does it mean we can finally use GL wrapped in SDL on the 2X?...

If the answer is yes, then the games list for 2X just grew 10-fold !
 
timbobsteve posted on Feb 6 2006 at 02:54 PM said:
Not only that... but does it mean we can finally use GL wrapped in SDL on the 2X?...

If the answer is yes, then the games list for 2X just grew 10-fold !

But at what fps? Not that I'm against any support of opengl (even if very slow) but there are many obstacles to defeat until the perfomance will get to decent. First there is enough bandwith for up to (edit: I should assume 16bpp not 8) 12,5mpix/s z-buffered alpha-blended pixels (as the cpu can read and write at 100MB/s) but let assume just 10mpix (to give similar relative power as the Voodoo1). So every pixel could be outputed every 20 machine cycles and that isn't much for 3d routiness. So decrease that value to 5mpix/s (should be yet accetable) then 40-50 cycles... perhaps could be done with some harsh compromises...?

Then we have the transforms, perhaps could be offloaded to the second core?

The more I think about it the more I going to the conclusion that without some kind of tilling/deferred engine there will not be too many mpixels of filltrate for the opengl. Custom made 3d engines can be much quicker at the other hand but they don't have the compatibility of the opengl.

edit:

And don't forget about the alphablending... This one needs true multiplications to be done for every RGBA channel and generally can not be speeded up like say the color addition. But without alphablends most of applications will not look correctly.

So compatibility but with slowness and quickness but with issues - these are choices for the opengl.
 
Last edited by a moderator:
So, in a nut shell, can we use this to get Quake 1 - 2 running faster/looking better?

I sure hope so, cause I am itching to do a Quake mod...

~Octavious
 
Octavious posted on Feb 6 2006 at 02:35 PM said:
So, in a nut shell, can we use this to get Quake 1 - 2 running faster/looking better?

I sure hope so, cause I am itching to do a Quake mod...

~Octavious
GL is very powerful and very cpu intensive. Without 3d and fpu hardware it will only make software engines much slower. If you want to make a Quake mod for the gp2x then you should be creating a mod that is optimised for the gp2x speed instead of creating a mod that is large and slow and expecting the engine to suddenly improve.
 
Last edited by a moderator:
@woogal
are you still activily working on Quake 1/2, quake 1 runs fullspeed with overclocking and Quake2 gets somhow playable..
but a fully playable quake 2 would be awesome...
 
Let's not get too far ahead of ourselves :)

First, this is TinyGL, it's not a full OpenGL implementation. Also, since there's no hardware acceleration available for 3d, it's always going to be pretty slow (I'll do what I can, but there's only so much that can be done)

On the other hand, I think that if I rip out all of the floating point and replace it with fixed point, and rewrite the triangle rasterizer in ASM, I think I can get some better speed out of it.

I don't think that this particular port will be useful for (for example) quake, but who knows, there are many more clever folks than I out there.

Not only that... but does it mean we can finally use GL wrapped in SDL on the 2X?...

No, it's not wrapped in SDL, it's wrapped in rlyeh's minlib (though it could probably be trivially updated to use SDL).

Right now, it only supports 16bpp and I've heard that there are some annoying texture ramifications for TinyGL (I heard that all textures are 256x256, but I haven't investigated yet)


-- pryankster
 
Pryankster posted on Feb 6 2006 at 10:03 PM said:
Let's not get too far ahead of ourselves :)

First, this is TinyGL, it's not a full OpenGL implementation. Also, since there's no hardware acceleration available for 3d, it's always going to be pretty slow (I'll do what I can, but there's only so much that can be done)

On the other hand, I think that if I rip out all of the floating point and replace it with fixed point, and rewrite the triangle rasterizer in ASM, I think I can get some better speed out of it.

I don't think that this particular port will be useful for (for example) quake, but who knows, there are many more clever folks than I out there.

Problem with opengl and Quake is that it's using multitexturing for lighting so it needs to texture every surface twice and combine them using alphablending... And better the lightmaps be interpolated too because otherwise it will hardly look better than non opengl renderer (and will be much slower). And the whole scene has to be z-buffered too (not only characters like in non ogl renderer). Unless ogl implementation gets at least 5mpix/s with features then we might just use software version because it'll be superior.
 
Last edited by a moderator:
I compiled the fixed-point version of TinyGL that was ported to the GP32 for the GP2X, and got texobj running. However, the two players I tried that used OpenGL (there were only 2 that supported Flash 7, both with OpenGL :() needed some fairly vital functions that TinyGL doesn't have (such as texture mapping generation), and therefore didn't work. Sorry to those who were optimistic.
 
Pryankster posted on Feb 7 2006 at 06:03 AM said:
Right now, it only supports 16bpp and I've heard that there are some annoying texture ramifications for TinyGL (I heard that all textures are 256x256, but I haven't investigated yet)
That is correct. TinyGL upscales any smaller textures to 256x256.

I had TinyGL running on the GP2X a few months ago and got the same fps that you have in the gears demo. I haven't touched it since except to do a port of the PSP version of TinyGL. I also had Vincent OpenGL-ES ported, but that is sitting on the back burner as well.

I'm now playing with Yeti3D. My first attempt has the demo running at 30fps with CPU time to spare.
 
Last edited by a moderator:
slygamer posted on Feb 6 2006 at 05:11 PM said:
I'm now playing with Yeti3D. My first attempt has the demo running at 30fps with CPU time to spare.

Nice! How about a blurry photograph of the screen with your thumb over the lens and plenty of glare?
 
Last edited by a moderator:
slygamer posted on Feb 7 2006 at 12:11 AM said:
Pryankster posted on Feb 7 2006 at 06:03 AM said:
Right now, it only supports 16bpp and I've heard that there are some annoying texture ramifications for TinyGL (I heard that all textures are 256x256, but I haven't investigated yet)
That is correct. TinyGL upscales any smaller textures to 256x256.

That is luxurious for gp2x because even at 8bpp it's 64KB.

slygamer posted on Feb 7 2006 at 12:11 AM said:
I had TinyGL running on the GP2X a few months ago and got the same fps that you have in the gears demo. I haven't touched it since except to do a port of the PSP version of TinyGL. I also had Vincent OpenGL-ES ported, but that is sitting on the back burner as well.

I'm now playing with Yeti3D. My first attempt has the demo running at 30fps with CPU time to spare.

What is really needed here?

A triangle based primitives plus texturing, Z-buffer (or equivalent like sorting), some support for transparencies (addition and substraction only) and transforms. The guardshading and stencil could be not supported imho. The filtering has to be pointsampling only probably and such stripped down engine could be fast enough for realtime rendering.

It could be working in deffered mode binning triangles' scanlines into tiles. There can not be too much triangles as speed of transforms will never be high on gp2x so such aproach is probably worth the effort.
 
Last edited by a moderator:
Dzz posted on Feb 6 2006 at 11:25 PM said:
slygamer posted on Feb 6 2006 at 05:11 PM said:
I'm now playing with Yeti3D. My first attempt has the demo running at 30fps with CPU time to spare.

Nice! How about a blurry photograph of the screen with your thumb over the lens and plenty of glare?
You mean like http://gp2x.sector808.org/yeti2x.jpg :) (photo of synkro's sdl port, taken a few months ago). I'm not sure if synkro's version is still available (the link on his site was broken a while ago), but I think http://gp2x.sector808.org/yeti3d.zip is a version that should work. Don't know what fps it runs at, but it slows down a lot if I underclock to 133mhz which isn't good as I think the gp32 version ran at 133mhz and was full speed.
 
Last edited by a moderator:
That's some nice work, keep it up!

I'm still busy working on my written-from-scratch-specially-for-the-GP2x OpenGL renderer, GL2x. I hope to submit something for the coding competition, so no previews until them I'm afraid!

I've got a spinning flat shaded cube running on my pc, and I'm in the middle of writing my replacement for Ryleh's minimal library so I can get it running on the GP2x.

Andrew
 
andrew_j_w posted on Feb 7 2006 at 02:14 PM said:
That's some nice work, keep it up!

I'm still busy working on my written-from-scratch-specially-for-the-GP2x OpenGL renderer, GL2x. I hope to submit something for the coding competition, so no previews until them I'm afraid!

I've got a spinning flat shaded cube running on my pc, and I'm in the middle of writing my replacement for Ryleh's minimal library so I can get it running on the GP2x.

Andrew

Now that sparked my interest ;) Are you working with the second CPU?
 
Last edited by a moderator:
Back
Top