GP2X Opengl For The Gp2x

[nuclear]

Hello, this is my first message in this forum, good to meet you all.

I just wanted to announce, that I started a project recently for creating a fixed point OpenGL implementation, for the gp2x (which of course could also be used on other fpu-less platforms). I just finished a first working version of the library, and thought it would be a good idea to create a sourceforge project, and post this announcement to see if anyone is interested.
The code is free (as in freedom), provided under the GNU General Public License (yes GPL, *not* LGPL, I only want to help free software developers).

Development status
The library still has many things to be implemented yet, optimizations to be done, and in general a lot of work before it's deemed a complete OpenGL implementation for the gp2x (although it DOES work, check out this shot: http://libfixgl.sourceforge.net/img/gp2x.jpg ). But then again, if I had done the whole thing myself, it wouldn't be fun for the rest of you So in the spirit of free software development, I invite anyone who is interested to participate in the development of this library.

At this point, most of the OpenGL state is there, texturing, zbuffering, gouraud (and additionally phong shading, lighting, the usual modelview/projection matrix stacks, etc. The library works with 16.16 fixed point math internally, and provides additional fixed point API functions along with the regular floating point ones. So for example, glVertex3f is now a wrapper that converts its floating point arguments to fixed point and calls glVertex3x, which is the "new" fixed point equivalent.

Important missing features at this point
The most glaring ommision at this point is the total absence of 3D clipping. The rasterizer handles 2D image-space clipping but if the polygons cross the XY plane (go behind the camera) you're toast

The rasterizer handles blending, as well as color, depth, and (if requested) normal interpolation, BUT does not yet support perspective-correct texture mapping.

The lighting code is slow at this point. Vector normalization is handled with floating point arithmetic, due to overflow problems with fixed point vector calculations.

Download
You can get the code from the sourceforge subversion repository like this: "svn co https://svn.sourceforge.net/svnroot/libfixgl". For more information, visit the project homepage which I just uploaded: http://libfixgl.sourceforge.net/
There you can also find contact information if you wish to contribute to the development or, you just want to say hi, whatever
I'll try to watch this thread also, and answer any questions here...

 

[craigix]

Wow, this is an unexpected suprise!

 

[PokeParadox]

hmm must try this out... I'd lik to see how it compares in performance to the Vincent OpenGL ES library

Nice to have an alternative, so thanks.

 

[mth411]

I should have mentioned this a while ago,
but there is a fixed point version of TINYGL that renders to the framebuffer,
and there is that ported version of Tinygl that someone did for the gp2x that uses floating point maths.

I have the source for both if anyone is interested, I have been meaning to merge them, but never get any spare time.
mth411@yahoo.com

Someone was also trying to move tinygl to the second processor, but I don't have any clue about that.

 

[Captainbubby]

Does this yet again bring hope that flash can be played on the Gp2x? Wonderful suprise!

 

[dockthepod]

Wow, this looks awesome.

Edit: any reports on speed for simple scenes?

 

[PokeParadox]

Don't hld your breath, because I sometimes take ages to do anything... but I intend to make a simple game/techdemo with one of the GLlibraries

 

[nuclear]

any reports on speed for simple scenes?

In the libfixgl source there is an example program, but it's a bit extreme, it displays a model with 10 thousand polygons, with lighting and everything, which is very slow on the gp2x at the moment. (it also switches to a simple cube with a spacebar, which works if you run it through STerm, and you can see it textured if you run with -t foo.png or something .

As I said, it's very early in the development, and the lighting code uses floating point math for vector normalization which is slow. These should be fixed later on.

 

[Trip]

Even a half decent OpenGL implementation could add so much more to the 2x.
There are plenty of opensource games that rely on it, even though they don't come anywhere near using the full power of it.
Good stuff nuclear & thanks

 

[hackgrid]

Tux/PPracer could be on the gp2x? Incredbile ^^

 

[nuclear]

Good to hear its finally ported to GP2X, it should open up a few more software possibilities.

Is it OK if I include a built version of libs in a package I am putting together? Full credit etc is given to the authors of the various gp2x versions of the libs, I just put it in a package for people that dont want to build their own. I will put a note that this is an early release with some bugs etc.

You don't even have to ask my permission, you are free to do whatever you like within the bounds of the GNU GPL, meaning (in this case) that you can redistribute all you like provided you also redistribute the code, or give some sort of indication on where the code can be found.

However let me stress that this is not just "an early release", essentially it hasn't even reached a point to make a "release" out of it, like libfixgl 0.1 or whatever. It's an early development version of the code. Having said that, you can still do it if you think it'll be useful. And I would be glad to know that you are willing to provide easy to use compiled versions of this library at various points as the development continues.

 

[Guyfawkes]

i think i deleted my post when i went to update it earlier, changed the browser tab to another site and came back and it was gone.

thanks for letting me know, i will probably release a new version of the package tomorrow or monday and I will add a build of your libs to it with a warning that its an early release. the readme will contain links to all the sourcecode.

 

[zaiprzie]

10 thousand polygons! Heck, the DS can only do 2048 polys per frame(at fullspeed of course). Maybe I should try loading a 2048 model on the gp2x and see how well it does with this lib

 

[Dingo_aus]

This is great news and well could end up with a lot of devs backing it.

I think a great step forward will come when some version (even a very early one) of OGL is found within the official SDK, that is when every Tom Dick and Harry will see the GP2X in a new light

Again, excellent work.

 

[hmw]

There a a bunch of posts about "OpenGL" implementations in this forum. I just thought it might be helpful for evryone to understand that there is a whole series of requirements around the correct use of this term. If not and somebody in SGI's legal departments has nothing better to do, it can happen that you receive nasty letters. One such letter was the rason why Daniel had to rename "SoftGL" to "Klimt", or why the description of Mesa-3D on the project homepage and its relationship to the OpenGL API specification is so vague.

So for those of you working on 3D APIs that use entry points similar to the ones defined in the OpenGL API specification, you might want to take a look at the OpenGL trademark usage guidelines. There are similar guidelines for the use of the term "OpenGL ES".

So keep on working on those 3d libraries, but obeying those terms might save you some unnecessary trouble.

- HM

 

[nuclear]

There a a bunch of posts about "OpenGL" implementations in this forum. I just thought it might be helpful for evryone to understand that there is a whole series of requirements around the correct use of this term. If not and somebody in SGI's legal departments has nothing better to do, it can happen that you receive nasty letters.

I realize that the name OpenGL is trademarked by SGI, and thus it's "usage" controlled. So I ensure you that if Silicon Graphics has nothing better to do in its current state (bunkrapcy), than to pay lawyers to hunt down OpenGL implementations to make them call their ducks, monkeys, due to trademark restrictions on the name "duck", I will oblige (or not, I'll have to think about it)

The whole trademark issue is rediculus, like all those UNIX implementations out there (BSD, GNU/Linux, etc) calling themselves "UNIX-like systems"....

Anyhow, please refrain from turning this thread about legal issues, if you want to discuss something of this nature, contact me through email.

 

[Trip]

Don't think he meant anything bad by it nuclear. Just wanted to make sure that people understood the terms before they get in trouble

 

[hmw]

Don't think he meant anything bad by it nuclear. Just wanted to make sure that people understood the terms before they get in trouble

That was exactly my point. As said, one such letter lead to Daniel having to rename "SoftGL" to "Klimt", and whatever I had been using before to "Vincent". So the point is, yes, there are folks in SGI legal department having time for this, and particular in the presence of a sell-out "protecting the company's IP assets" can become an issue.

- HM

 

[hmw]

Now, coming back to the technical side. How do you plan to achieve performance in your rasterizer given the many options the OpenGL spec. forsees:

• Scanline building-block routines like Mesa?
• A specific rasterizer for every possible combination (like PocketGL)?
• Runtime code generation (like Vincent)?
• Plans for using the second processor core?

- HM

 

[nuclear]

Now, coming back to the technical side. How do you plan to achieve performance in your rasterizer given the many options the OpenGL spec. forsees:

• Scanline building-block routines like Mesa?
• A specific rasterizer for every possible combination (like PocketGL)?
• Runtime code generation (like Vincent)?
• Plans for using the second processor core?

These are all very good ideas for consideration, I have only thought about the last one. The rasterizer is quite fast, as far as general purpose polygon fillers which also perform various per-pixel tests go and optimizing it further is not my first priority right now for two reasons:
1) It's not the bottleneck right now as far as I can tell (lighting is)
2) I believe that focusing on implementing a big part of the OpenGL features is much more important right now. A lot of things are missing yet.

Then of course, I'm not planning on passing any OpenGL conformance tests with this. It'll be more performance oriented, so any obscure rasterizer options not generally used or having a minor impact on the output quality aren't even considered at this stage.
Still if someone cares to contribute code that adds polygon stippling or something like that, I will of course include it.
Also if anyone wants to suggest improvements and optimizations I would be happy to hear any ideas (through email would be preferable, or irc if you prefer, I understand there is a gp2x dev channel somewhere, I might visit it one of this days).