OpenGL 2.0 to OpenGL ES 2.0 Wrapper. GPLv3.

[Adventus]

1. Will this library be usable on all OGLES-2.0 platforms?

Yep it should be entirely portable. Except maybe the runtime library loading which is fairly trivial. However I will optimise it for Pandora (NEON, etc) once i get an opportunity but i'll try to maintain portability.

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)?

I'm unlikely to ever implement the full OGL2 feature set. There are heaps of rarely used / redundant features which would be a waste of time wrapping. It will however get close enough that most games would be easily portable. As it matures I'll through a few games determining what functions and defines are used (I've written a tool for this).

3. How much performance is lost because of boilerplate?

This is a hard question. Not that this is even close to a benchmark but at the moment running the NeHe tutorials through the PVR emulator i get around 1700fps, compiled with full OGL i get 1800fps. If you used just OGLES2 functionality in the wrapper you would pretty much get the exact same performance as standard OGLES2, apart from consuming some RAM, the overhead would be almost zero.

Some good questions.

 

[PokeParadox]

Sounds good so far... with the shift to using LGPL and the low overhead... I'm tempted to give this a try.

 

[darkblu]

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.

today on my commute from work i was thinking how to fix the clipping while still retaining the per-vertex dot product. and the answer is dead simple (i must have been really asleep last night while posting).

so, the solution is in getting the plane dot products per vertex, but keep the clipping check per fragment. for the purpose you'll have to have as many "vFactor.y" factors as CLIPPLANE_NUM, so that solution may turn out to be varying-attributes-limited. still, as long as you don't go greedy with CLIPPLANE_NUM, say keep them at 4, this solution might prove to be both fast and fragment-correct.

so, your original vFactor.y computation in the vshader should change from

        vFactor.y = 1.0;
        for(int i = 0; i < CLIPPLANE_NUM; i++){
                if (uEnableClipPlane[i]){
                        if (dot(lEye, uClipPlane[i]) < 0.0){
                                vFactor.y = 0.0;
                        }
                }
        }

to

        for(int i = 0; i < CLIPPLANE_NUM; i++){
                if (uEnableClipPlane[i])
                        vClipDistance[i] = dot(lEye, uClipPlane[i]);
                else
                        vClipDistace[i] = 1.0;
        }

and your fshader from

#ifdef DEF_CLIPPLANE
        gl_FragColor.w *= vFactor.y;
#endif

to

#ifdef DEF_CLIPPLANE
        for(int i = 0; i < CLIPPLANE_NUM; i++){
                if (vClipDistance[i] < 0.0)
                       gl_FragColor.w = 0.0;
        }
#endif

and voila - you're fragment-precise.

 

[Adventus]

so, the solution is in getting the plane dot products per vertex, but keep the clipping check per fragment. for the purpose you'll have to have as many "vFactor.y" factors as CLIPPLANE_NUM, so that solution may turn out to be varying-attributes-limited. still, as long as you don't go greedy with CLIPPLANE_NUM, say keep them at 4, this solution might prove to be both fast and fragment-correct.

Thanks that should work perfectly. I don't have to worry too much about the varyings yet, I can still do alot of packing. The spec requires a minimum of 8 varying vec4s... since I'm only using 2 components of the texcoords (although this may change) i can pack two in one vec4. I can also pack the clip plane factors into vec4s.

BTW don't know where you got my fragment shader from.... i thought i deleted it from the SVN. :twisted: I'm no longer using it (its dynamically generated in the wes_fragment.c file).

 

[cb88]

you nay have deleted the file... but it would still be in svn in an older revision.. which doesn't really know the meaning of delete

maybe he got it from an older revision of your source

 

[lulzfish]

lol SVN is working perfectly, then.

 

[knikkane]

Interesting project.

Has someone been able to test this already in Linux platform? When checking out the code you'll get an punch of c/h files and one shader file but what to do next? How to compile the library?

Also something that came to my mind,
has this concept ever been thought in the other way around. Now with this we are creating an wrapper for GL commands on top of GLES. How about if we would just generate an script which would go through our GL code and generate GLES code out from it? Sure we might not find 100% translation compatibility with this but this is also the case with the wrapper.

 

[Adventus]

Sorry for the ultra late reply, i rarely check this board.... most of us have moved back to GP32X.

Has someone been able to test this already in Linux platform? When checking out the code you'll get an punch of c/h files and one shader file but what to do next? How to compile the library?

This library is not really ready for usage yet, i haven't tested on Linux.... the only non portable code will be the stuff in "context.c" which makes a window and a context. To use the library you must simply compile all the c files and link them together. I tend to use very simple build systems because i often encounter complex ones which are a real pain to work around, especially when cross compiling. I have a very generic makefile which does this.... maybe i should include it in the svn.

has this concept ever been thought in the other way around. Now with this we are creating an wrapper for GL commands on top of GLES. How about if we would just generate an script which would go through our GL code and generate GLES code out from it? Sure we might not find 100% translation compatibility with this but this is also the case with the wrapper.

You can get much better translation capability with a wrapper, there are many things that are not known at compile time. Very simple code might work with your idea bit as soon as you encounter something like:

glbegin()
for(i=0;i<n;i++) draw_shadow();
glend()

Your screwed.