GP2X Opengl For The Gp2x

[Dingo_aus]

Is there any further documentation on how to compile anyway.....or a compiled static lib to code against?

EDIT: To answer my own question -> to compile a static library with the Official Windows SDK is very easy.
1) Grab latest HEAD from SVN
2) Start a new project in DevCpp. Make it a Static Library. Make is a C program not C++.
3) Add in all the files in the src directory
4) Switch the compiler to gp2x
5) Compile

EDIT AGAIN:
Banging my head against an error stating "cannot find -llibGL_gp2x" despite that file being on the library include path:

-L"G:/gp2xsdk_windows/GP2XSDK/ogl2"

...and I've even tried copying it to other locations that ld should find it at.

ANy idea what noob thing I'm doing to cause this?

EDIT AGAIN:
Oh I'll tell you what noob thing I was doing, I had -llibGL_gp2x not -lGL_gp2x <smacks forehead> very noob indeed.

 

[nuclear]

Banging my head against an error stating "cannot find -llibGL_gp2x" despite that file being on the library include path:
-L"G:/gp2xsdk_windows/GP2XSDK/ogl2"
...and I've even tried copying it to other locations that ld should find it at.

Not necessary, just link the static lib with your program directly, i.e. if you were to run the compiler directly for linking something like "gcc -o foo foo.o bar.o libgl_gp2x.a -lm" should do fine.

 

[Dingo_aus]

For those just wanting to see the example cube spinning on their GP2X:
executable

 

[Trip]

Looks pretty good
What FPS is it running at any idea?

 

[torpor]

wow, this looks great .. i've just downloaded the code, built it, and run it, and i have to say this looks like a very smooth way to get some 3D objects displayed on the GP2X ..

so the big question is: what about pushing this API onto the 2nd CPU as soon as possible - i.e. *before* completing the OpenGL implementation - so that its fresh and starts out that way 'early on' in the project? I for one will be investigating what it'd take on this when I get a bit of spare time, so I'll be eager to hear what you guys think about it now ..

Really looking forward to seeing what can be done with this. I can imagine a decent-performing 3D user interface for tons of things worth running on the GP2X ..

 

[nuclear]

so the big question is: what about pushing this API onto the 2nd CPU as soon as possible - i.e. *before* completing the OpenGL implementation - so that its fresh and starts out that way 'early on' in the project? I for one will be investigating what it'd take on this when I get a bit of spare time, so I'll be eager to hear what you guys think about it now ..

Why not... I haven't had the time to investigate how the second gp2x processor can be used. If you want to give it a try, drop me an email (nuclear@siggraph.org) so that we can figure the best way to do this without breaking the library for other platforms. Also I'm generally on #gp2xdev on efnet around 1-2am GMT these past couple of days, so you may find me there as well.

 

[Julius]

Did you have a look at this project:

http://gna.org/projects/gpu940/

With this demo as an early example on how the second cpu can be used:
http://www.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,38,1706

 

[dockthepod]

I hope that we can get a similar level of performance out of this lib as the gpu940 lib. I had a look at that one, and while it does offer much better performance, it looks much harder to use. Maybe I'm just used to the openGL API.

In regards to the performance of libfixgl, I did a really quick profile run in the PC build (using the standard GP2X SDK) and at least on windows, most of the time is spent in -

fill_scanlines (26%)
scan_fixed (19%)
__fivdi3 (14%)
glClear (8%)
gl_shade(8%)

Granted, this is on my pc, so the floating point stuff isn't going to be much of a hit. Have you profiled this on the GP2X?

I'd offer some help, but a) I'm not really a low level programmer and B) I have absolutely no time... damn you holiday driven gaming market...

Awesome looking lib, can't wait to see it speed up

 

[nuclear]

In regards to the performance of libfixgl, I did a really quick profile run in the PC build (using the standard GP2X SDK) and at least on windows, most of the time is spent in -

fill_scanlines (26%)
scan_fixed (19%)
__fivdi3 (14%)
glClear (8%)
gl_shade(8%)

Granted, this is on my pc, so the floating point stuff isn't going to be much of a hit. Have you profiled this on the GP2X?

I haven't profiled on the GP2X, but given the fact that I can see a *very* visible speedup when I disable lighting, it doesn't take much to realize gl_shade is the bottleneck there (due to floating point stuff

I have a few ideas on how to go about doing all the lighting in fixed point, I'll try it out soon when I find some time to work on this.

I'd offer some help, but a) I'm not really a low level programmer and B) I have absolutely no time... damn you holiday driven gaming market...

You don't need to be a low level programmer. Just get the code and add some missing OpenGL functions or something
Time however, is a big problem indeed

 

[dockthepod]

Indeed, lighting is a big hit. However, when I run the just the spinning cube with lighting disabled I still don't see the framerate I'm hoping for. It could be that the cube demo isn't so great because it's using all floats for the verts. I've been meaning to try to create a fully fixed-point, unlit scene to see what I can see.

When my company gets this game out the door I'll have some more free time to hack on this. It's very interesting stuff.

 

[BradN]

Maybe the cube demo isn't a really great thing to test with... it could be more dominated by once-per-frame processing instead of the actual 3d calculations and such - unless this is more complex than the usual cube demo . I suppose you'd have to check.