GP2X Tinygl Ported To Gp2x

[Pryankster]

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

 

[Captainbubby]

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

 

[timbobsteve]

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 !

 

[Radek]

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.

 

[Octavious]

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

 

[Vimacs]

for sure not.

 

[woogal]

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.

 

[Sonic-NKT]

@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...

 

[Pryankster]

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

 

[Radek]

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.

 

[nickspoon]

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.

 

[Julius]

Yeah not so usefull for Quake, but a really nice lib for porting other OGL dependant stuff.

Great work

 

[slygamer]

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.

 

[Dzz]

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?

 

[slygamer]

hehe.

I'll post a screenshot once I work out a problem with the lua (lookup array). The texture colours are all wrong.

 

[Radek]

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.

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.

 

[woogal]

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.

 

[slygamer]

That's a SDL port. I don't want SDL.

 

[andrew_j_w]

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

 

[Julius]

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?