OpenGL 2.0 to OpenGL ES 2.0 Wrapper. GPLv3.

[Adventus]

Hiya, Since the other forum is down I'll post here.

I've written a wrapper that translates some of the OpenGL 2.0 API to OpenGL ES 2.0. As far as possible i've done it by reading through the OGL2 spec ignoring error production, but there is bound to be some oversights. Currently it runs most of the Nehe tutorials. Due to the large scope of the library i have not been able to thoroughly test much of the fuctionailty. There is also some functionality that i have written into the vertex shader but not fully exposed in the interface. This post is not for a "public release", the code is too messy and undocumented at the moment, I wish it to be a discussion on the more technical aspects.

You can find the GPLv3 source code here:

http://code.google.com/p/gl-wes-v2/

If anyone would like to collaborate just contact me via PM / email / etc.

Currently Supported Features:

• Matrix Transforms: glScale, glRotate, etc
• Fixed Function shader and interface: glFog, glLight, glMaterial, etc
• Begin / End Paradigm: glBegin, glEnd, GL_QUADS, GL_QUAD_STRIP, etc
• Texture Environments and Multi-Texturing: glTexEnv, etc.
• Alpha Test: glAlphaFunc, etc.
• Support for GL_BGR & GL_BGRA texture formats.
• Some GLU functionality: gluBuildMipmaps, gluPerspective, gluLookAt, etc

Things that it doesn't support yet (but may in the future):

• Display lists.
• Color Indices.
• Many obscure texture formats.
• NEON-ized matrix math.

Notes on using in your projects:

• For a good indication of the functions i've wrapped look at "wes_gl.h" and "wes_glu.h".
• Replace instances of "gl.h" and "glu.h" with "wes_gl.h" and "wes_glu.h"
• The "context" files are not actually part of the library just functions to help with context creation on Windows (they are not portable).
• You must call wes_init() before any OpenGL calls are made and after context creation. You should also call wes_destroy() at the end of OpenGL execution.
• I link at runtime to the OpenGL ES 2.0 library, You must provide its location with wes_init().
• I develop solely on Windows but the code is designed to be portable.... there might be some minor issues.
• The fragment shader is dynamically generated after a texenv/alpha/fog state change. It expects the vertex shader WES.VSH to be in the application root (you can change it easily).

 

[Pleng]

Awesome

[broken record]
does this mean Clanlib can now be ported?
[/broken]

 

[darkblu]

good job, Adventus!

just a remark about your implementation of clipping planes: it's both clever and incorrect ; )

it's clever because you use alpha blending for clipping fragments, which could be the best viable client-side solution on the SGX. and it's broken because you compute the clipping factor (vFactor.y) per vertex, and it reaches the fragments only as a varying attribute, whereas clipping planes are fragment-exact in desktop GL, that is, clipping is computed per fragment.

 

[Adventus]

does this mean Clanlib can now be ported?

Its certaintly closer to an implementation. But you'll have to find out exactly what OpenGL functionality it uses.

it's clever because you use alpha blending for clipping fragments, which could be the best viable client-side solution on the SGX. and it's broken because you compute the clipping factor (vFactor.y) per vertex, and it reaches the fragments only as a varying attribute, whereas clipping planes are fragment-exact in desktop GL, that is, clipping is computed per fragment.

Yea, i figured the SGX is unlikely to be powerful enough to do per fragment clipplanes, so I pre-emptively made that approximation. I guess a better solution would be to put it in the fragment shader and make Per-vertex clipplanes a #define option.

Cheers,

 

[Pleng]

Its certaintly closer to an implementation. But you'll have to find out exactly what OpenGL functionality it uses.

OK Cool. How would I go about finding that out? I've scanned the website but, really, I wouldn't begin to know what I'm really looking for!

 

[lulzfish]

Someone will probably need to scan through the code and see exactly which functions it's calling.

 

[lippy]

Nice! This is the major obstacle for many porters at the moment, hopefully this wrapper will accelerate the process. Too bad that the main forums are down, because this would have garnered a lot of attention!

 

[JayFoxRox]

lulzfish: Or let the compiler do it by just not including or linking the libs into it The compiler will complain with "not defined" or "undefined reference"

How about including the vertex shader into to the final app?
I might be able to help with some assembler loops for conversion between texture formats in the near future because the PSPs GU lib is a stripped / modified / remake version of OpenGL and I need the same stuff.
I might be able to provide some shader stuff too, but I'm still hacking (haven't done this since I started with it ) the binary shader format.. - A look at wine might be useful.
Surprising that you didn't put in the display lists first - shouldn't be too hard if you start with them in the back of your head - because I see them in a lot of samples and tutorials.

//Edit: Also make sure to check out: http://web.archive.org/web/200712220858 ... shadergen/

 

[Adventus]

How about including the vertex shader into to the final app?

You mean just in a .c file. Yea, I'll do that once its final. At the moment i enjoy the syntax highlighting that the PVR tools provide. If there's performance to be gained, I may move to dynamic vertex shader generation aswell at some point.

I might be able to help with some assembler loops for conversion between texture formats in the near future because the PSPs GU lib is a stripped / modified / remake version of OpenGL and I need the same stuff.

Cheers, that would be great. I may write some in C, just to maintain portability.

I might be able to provide some shader stuff too, but I'm still hacking (haven't done this since I started with it ) the binary shader format.. - A look at wine might be useful.

Just curious, what do you need the binary format for?

Surprising that you didn't put in the display lists first - shouldn't be too hard if you start with them in the back of your head - because I see them in a lot of samples and tutorials.

Yea, its just a boring thing to code. Basically just an interpreter. I could probably modify the Mesa implementation to suit.... all 8000 lines of it.... actually on second thoughts it might be easier to it implement it my self. When you look at mesa it becomes evident why embedded systems needed ES.

Yea ShaderGen is cool. However i felt i shouldn't look at it because i approached this as a learning exercise, i wasn't expecting anything useful to come of it. Now I may aswell go through my vertex shader and make a few correction based on the ShaderGen stuff.

PS: I've only been working on/off on this for less than a month.

 

[Mithrildor]

Looks good.

Btw Adventus we havent hear anything about your arcade game project for the Pandora (Super Lumenal???), is there any progress? I really liked it.

 

[notaz]

GPLv3

With this you are banning all non-GPL projects to use your lib, please consider using LGPL.

 

[Adventus]

Btw Adventus we havent hear anything about your arcade game project for the Pandora (Super Lumenal???), is there any progress? I really liked it.

There is a bit of progress, I've added very simple music playback and a friend of mine is making some music over the weekend for it, but its on the back burner at the moment. Not having a Devboard / Beaglboard / Pandora kinda loosened my focus.

With this you are banning all non-GPL projects to use your lib, please consider using LGPL.

Yea I'm a bit fuzzy about this legal stuff. I'll change it to LGPL.

 

[JayFoxRox]

OpenGL ES 2.0 supports binary and source shaders. The source shaders are full ascii versions (the code) which is compiled into a binary file (with instructions). Therefore it makes more sense to me to generate binary shaders at runtime instead of generating long ascii strings which are compiled into a binary version after that anyway.
Thats why I try to crack the binary shader format.

I had a look at the wine wiki and that reads DirectX tokens (instructions) and outputs ascii strings for GLSL. It still works that way, but I don't like to work with ascii strings for things like this to be honest (not to forget that wine probably has no other way of doing it because OpenGL doesn't support binary shaders - or does it?).

Just thinking about it again: There might be no need for my shader compiler in your project because you probably get a full ascii source anyway..

 

[arrrgh]

About GLU functionality, you might want to check out this - it's a implementation of GLU for OGLES, although only 1.1 so I don't know how useful it will be to you. I found it while mucking around trying to port stuff, and found that most things written for desktop GL used GLU.

 

[Adventus]

OpenGL ES 2.0 supports binary and source shaders. The source shaders are full ascii versions (the code) which is compiled into a binary file (with instructions). Therefore it makes more sense to me to generate binary shaders at runtime instead of generating long ascii strings which are compiled into a binary version after that anyway.
Thats why I try to crack the binary shader format.

Yea i've used the binary format before for my other projects. It certaintly takes much more time to compile from source than upload the binary. I cache my fixed function program objects so the source upload should only happen once (unless you use all the cache = 128 programs).

Just thinking about it again: There might be no need for my shader compiler in your project because you probably get a full ascii source anyway..

Ahh i see what your getting at. I'm not yet emulating the OGL2 shaders, but it should be pretty trivial to implement since i'm generating all the inbuilt stuff missing from gles shader language (gl_ModelViewMatrix, etc). I haven't seen binary shaders in standard OpenGL, so i would just need to preprocess the shader source and keep the inbuilt uniforms up to date.

About GLU functionality, you might want to check out this - it's a implementation of GLU for OGLES, although only 1.1 so I don't know how useful it will be to you. I found it while mucking around trying to port stuff, and found that most things written for desktop GL used GLU.

Yea, looks like a useful reference. Thats looks like its based on the standard SGI version but with the unsupported texture formats removed(which happen to be the same for 1.1 and 2.0). I've probably implemented all of ES 1.1, so anything that works with that should work with this.

 

[Nation.A.List]

WOW, this thread is like reading a foreign language I do hope that this is the stuff that goes on in the background. I can see why many people tremble when coming across the Linux thing :huh:

 

[dflemstr]

WOW, this thread is like reading a foreign language I do hope that this is the stuff that goes on in the background. I can see why many people tremble when coming across the Linux thing :huh:

This isn't "the Linux thing", this is "game-developer and system-programmer talk". That's why it's in the Development forum.
And Windows is also complicated under he hood, so don't think that this "mess" is Linux-specific.

Ok, so, now... A couple of questions:
1. Will this library be usable on all OGLES-2.0 platforms?
2. Is the whole featureset going to be implemented in the future (so that it would be possible to just switch header #imports in a project and recompile it to port it)?
3. How much performance is lost because of boilerplate?

 

[Nation.A.List]

I do realise that Windows is also complicated under the hood, but its intricacy's rarely/never gets posted on 'public' forums. The 'Open' word means you guys hang your programming washing out for all to see, which is great, if if baffling for the likes of me when you happen to come across it. P.S. I don't believe I used the word "mess"

I'll leave you all in peace now.

 

[hlidegp2x]

WOW, this thread is like reading a foreign language I do hope that this is the stuff that goes on in the background. I can see why many people tremble when coming across the Linux thing :huh:
...

I do realise that Windows is also complicated under the hood, but its intricacy's rarely/never gets posted on 'public' forums.

And you think it is a good example of what it should be ? just remember that we are in "Pandora Development" category here.

 

[Kramy]

I do realise that Windows is also complicated under the hood, but its intricacy's rarely/never gets posted on 'public' forums.

You're not reading the right forums. Go talk to some Windows game developers. I assure you the threads all look just like this.

Now, back on topic. I find this thread fascinating. I don't really understand the specifics, but once this is done it means easier porting of games! ^_^