just to point out for too those that have not seen it
<b =“postauthor”>Adventus ha <span =“postauthor”>written a wrapper that translates some of the OpenGL 2.0 API to OpenGL ES 2.0
for more info see here http://forum.openhandhelds.org/viewtopic.php?f=14&t=884
just to add more info
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).
<span =“post”>
This is an interesting project - please keep us posted as to how it develops. 
I read the thread you’ve linked to and I thought I might mention a few things, however.
The VFrame emulation we provide in our works in the opposite way to what you’re doing here. It takes ES 2 calls and passes them through to the desktop GL implementation on your system; i.e. it’s an OpenGL ES 2.0 wrapper for OpenGL 2.0. The acceleration is then provided by the GPU on your PC. This GPU is most likely to be from another manufacturer than Imagination and very unlikely to behave like an SGX. Basically, you can’t rely on the VFrame wrapper to give you any feedback on performance on real hardware.
VFrame has to do a few things like stripping the precision modifiers from shaders and decompression of compressed formats because they aren’t supported on the underlying 3D hardware. We’ve found these are a source of major optimization on actual SGX platforms - you can double your framerate in some cases - but obviously VFrame won’t reflect this.
For quick ports where performance isn’t necessarily a priority your wrapper may be useful. I’m concerned that directly wrapping desktop GL will always miss specific ES optimizations though.
I am currently trying to port this on “real” hardware (OMAP3530, PowerVR SGX530) and I am running into the following issue (no sure this is related with the fact that nothing shows up on the display), but I thought it’d be interesting mentioning it here.
I am an absolute OpenGL beginner so I might be totally wrong.
At some point, the wrapper tries to create some fragment shader, but for some reason, this fails.
Here’s the code:
GLuint
wes_shader_create(char* data, GLenum type)
{
GLuint index;
GLint success;
char src[1];
src[0] = data;
//Compile:
index = glCreateShader(type);
glShaderSource(index, 1, src, NULL);
wes_gl->glCompileShader(index);
//test status:
glGetShaderiv(index, GL_COMPILE_STATUS, &success);
if (success){
return index;
} else {
wes_shader_error(index);
wes_gl->glDeleteShader(index);
return (-1);
}
}
The following sources (stars are not included, I put them there for reading comfort) fail to compile. Log returns “Compile failed”. any idea what’s wrong in the sources?
Please bear with me if this is not meaningful. As I said, I am an absolute beginner.
********************************************
#define LIGHT_NUM 8
#define CLIPPLANE_NUM 6
#define MULTITEX_NUM 4
#define FACE_NUM 2
struct sMultiTexture {
lowp vec4 EnvColor;
sampler2D Unit;
};
uniform lowp vec4 uFogColor;
uniform sMultiTexture uTexture[MULTITEX_NUM];
uniform highp float uAlphaRef;
//Varyings:
varying lowp vec4 vColor;
varying lowp vec2 vFactor;
varying mediump vec4 vTexCoord[MULTITEX_NUM];
void main(){
gl_FragColor = vColor;
lowp vec4 arg0, arg1, arg2;
arg0 = gl_FragColor;
arg1 = texture2D(uTexture[0].Unit, vTexCoord[0].xy);
gl_FragColor = arg0 * arg1;
arg0.rgb = vColor.rgb;
arg0.a = gl_FragColor.a;
arg1 = texture2D(uTexture[1].Unit, vTexCoord[1].xy);
gl_FragColor.rgb = arg0.rgb * arg1.rgb;
gl_FragColor.a = arg0.a;
if (gl_FragColor.w == uAlphaRef) discard;
}
*********************************************
and
*********************************************
#define LIGHT_NUM 8
#define CLIPPLANE_NUM 6
#define MULTITEX_NUM 4
#define FACE_NUM 2
struct sMultiTexture {
lowp vec4 EnvColor;
sampler2D Unit;
};
uniform lowp vec4 uFogColor;
uniform sMultiTexture uTexture[MULTITEX_NUM];
uniform highp float uAlphaRef;
//Varyings:
varying lowp vec4 vColor;
varying lowp vec2 vFactor;
varying mediump vec4 vTexCoord[MULTITEX_NUM];
void main(){
gl_FragColor = vColor;
lowp vec4 arg0, arg1, arg2;
gl_FragColor = texture2D(uTexture[0].Unit, vTexCoord[0].xy);
}
********************************************
Quote:
I am currently trying to port this on "real" hardware (OMAP3530, PowerVR SGX530) and I am running into the following issue (no sure this is related with the fact that nothing shows up on the display), but I thought it'd be interesting mentioning it here.
I am an absolute OpenGL beginner so I might be totally wrong.
I am an absolute OpenGL beginner so I might be totally wrong.
I'm the Author of gl-wes-v2.... I'm probably a bit late to help you. The Shader you posted appears to have correct syntax. Some others have run into similar problems (ie correct shader code but generates an "illegal instruction") when trying to run it on actual hardware, i suspect its something to do with the DOS line formatting used through out the project. Maybe a PVR employee could shed some light on this?
Anyway I will be getting some hardware soon, so i will need to fix this problem.
There is probably nothing wrong with the shader code itself and you hit a compiler bug. The compiler currently does not support structs containing samplers (this is tracked as bug BRN28336).
A quick workaround would be to replace the uTexture array with two arrays, one for EnvColor and one for the samplers.
