Nanogl

[benjymous]

Can anyone give me more info on NanoGL?

I'm working under the assumption that I can code a regular OGL application, then link in the NanoGL libs on Pandora / Wiz, and have NanoGL do all the translation to OGLES.

Is that right, or am I being somewhat naive?

(I'm only using pretty basic OGL1.1 stuff atm - drawing lots of blended textured quads)

Also I haven't been able to find any concrete info about it, other than posts here about Quake running on the devkits - does it have a proper site somewhere?

Cheers guys!

 

[dflemstr]

No proper site afaik, but NanoGL should work out-of-the-box. I'd still target OGLES 2.0 if I were you, if only for the performance boost and future compatibility.

I rely on there being a lwjgl port in the near future, so NanoGL should better work, or else...

 

[Butterman]

Can anyone give me more info on NanoGL?

I'm working under the assumption that I can code a regular OGL application, then link in the NanoGL libs on Pandora / Wiz, and have NanoGL do all the translation to OGLES.

Is that right, or am I being somewhat naive?

(I'm only using pretty basic OGL1.1 stuff atm - drawing lots of blended textured quads)

Also I haven't been able to find any concrete info about it, other than posts here about Quake running on the devkits - does it have a proper site somewhere?

Cheers guys!

You should be able to compile as OGL ES 1.1, the only real change from OGL is the lack of glBegin() and glEnd(), which you shouldn't be using anyway. I've got a tutorial on the move to ES 1.1 here.

CODE
http://pandorawiki.org/OpenGL_ES_1.1_Tutorial

 

[Pickle]

I'm working under the assumption that I can code a regular OGL application, then link in the NanoGL libs on Pandora / Wiz, and have NanoGL do all the translation to OGLES.

Is that right, or am I being somewhat naive?

It might be possible, but keep in mind nanoGL only supports a subset of opengl.
The better way is to as butterman suggested, use native opengles from the start.

 

[benjymous]

The better way is to as butterman suggested, use native opengles from the start.

Is everything that OpenGLES supports supported in OpenGL? (i.e. can I continue using OpenGL on Windows as my main dev platform, as long as I make sure I'm not using any features not supported by ES?) or are there other syntax differences?

 

[lulzfish]

Yes, ES is a subset of OGL.
You'll need to move geometry from glBegin..glEnd to vertex arrays, and the shading and texturing in ES is all shader-based, so you'll need to make shader programs for everything.
I think there's a few other things, but that's most of it, vertex arrays and shader-based pipeline.

 

[Butterman]

Yes, ES is a subset of OGL.
You'll need to move geometry from glBegin..glEnd to vertex arrays, and the shading and texturing in ES is all shader-based, so you'll need to make shader programs for everything.
I think there's a few other things, but that's most of it, vertex arrays and shader-based pipeline.

If you only use ES 1.1, you don't need to make shader programs for everything. But you can't use shaders at all. Having to use your own matrices in ES 2.0 is such a pain in the arse, so if you're not using shaders, just stick with ES 1.1.

 

[Xmas]

Is everything that OpenGLES supports supported in OpenGL? (i.e. can I continue using OpenGL on Windows as my main dev platform, as long as I make sure I'm not using any features not supported by ES?) or are there other syntax differences?

Have a look at the difference specifications that can be found on the Khronos website (http://www.khronos.org/opengles/). In ES 1.1 there are a handful of OpenGL commands which only take parameters of type GLdouble, these have been replaced with equivalent GLfloat variants: glClearDepth, glClipPlane, glDepthRange, glFrustum, glGetClipPlane, and glOrtho. That's easy to fix with a few target specific macros. Then there's the addition of GLfixed fixed point parameters and vertex data, which you can safely ignore.

ES2.0 has some other additions and differences but sticking to the lowest common denominator you can still write easily portable code. Some things to watch out for: In OpenGL you need to have a vertex array for vertex attribute 0 and you have to enable GL_TEXTURE_2D, etc., in OpenGL ES 2.0 you don't. And fragment shaders in ES 2.0 need precision qualifiers. gl_PointCoord and matrix-from-matrix constructors are available in GLSL ES 1.00 but require GLSL 1.20 on desktop OpenGL.

 

[Pickle]

Heres where the original source is: CODE
http://koti.mbnet.fi/hinkka/Download.html


My version primarily just adds wrapper code for other opengles functions.

 

[darkblu]

glTexGen* (i.e. envmapping texcoord generation) are not supported by es 1.x, in case anybody cares.

 

[Adventus]

At the moment I'm writing a wrapper that aims to mimick most of the common OpenGL 1.5 functionality on top of OGLESv2. Currently i have a fairly optimised matrix transformation pipeline, begin / end rendering, Lighting, Alpha Test and Fog done. I've partly implemented (I'm working through the Nehe tutorials) TexGen, Multitexturing, Clip planes and the OpenGL texture formats (GL_BGR, etc). Its probably more complete than NanoGL at the moment. Can anybody tell me what the most commonly used functionality missing from OGLESv2 is?

Performance is a focus, so much of the OpenGL error checking has been dropped and I'm not aiming for complete conformance. It's mostly an academic exercise and should serve as a good reference but, if all goes well, i plan to use it to port some games (TORCS, etc). After it matures I'll release it as GPL.

I'm wondering if a Neon-ized matrix transformations might actually outperform the OGLESv1.1 driver, do they use Neon in the driver?

[\b]Edit:[\b] Too stop the confusion....

 

[Butterman]

^^

The matrix math, that's the big one, pin that down perfectly and you're sorted.

 

[Pickle]

At the moment I'm writing a wrapper that aims to mimick most of the common OpenGL 1.5 functionality on top of OGLESv2. Currently i have a fairly optimised matrix transformation pipeline, begin / end rendering, Lighting, Alpha Test and Fog done. I've partly implemented (I'm working through the Nehe tutorials) TexGen, Multitexturing, Clip planes and the OpenGL texture formats (GL_BGR, etc). Its probably more complete than NanoGL at the moment. Can anybody tell me what the most commonly used functionality missing from OGLESv2 is?

Performance is a focus, so much of the OpenGL error checking has been dropped and I'm not aiming for complete conformance. It's mostly an academic exercise and should serve as a good reference but, if all goes well, i plan to use it to port some games (TORCS, etc). After it matures I'll release it as GPL.

I'm wondering if a Neon-ized tranformation pipeline might actually outperform the OGLESv1.1 driver, do they use Neon in the driver?

cool i wonder if it will be faster. If your up for testing it on the pandora let me know.
Doing an objdump might couldnt you tell if neon instructions were used?

 

[darkblu]

At the moment I'm writing a wrapper that aims to mimick most of the common OpenGL 1.5 functionality on top of OGLESv2. Currently i have a fairly optimised matrix transformation pipeline, begin / end rendering, Lighting, Alpha Test and Fog done. I've partly implemented (I'm working through the Nehe tutorials) TexGen, Multitexturing, Clip planes and the OpenGL texture formats (GL_BGR, etc). Its probably more complete than NanoGL at the moment. Can anybody tell me what the most commonly used functionality missing from OGLESv2 is?

Performance is a focus, so much of the OpenGL error checking has been dropped and I'm not aiming for complete conformance. It's mostly an academic exercise and should serve as a good reference but, if all goes well, i plan to use it to port some games (TORCS, etc). After it matures I'll release it as GPL.

I'm wondering if a Neon-ized tranformation pipeline might actually outperform the OGLESv1.1 driver, do they use Neon in the driver?

glad to hear you're doing that. onto you question about common gl functionality missing from es2, you have got it pretty much covered (and i'd say that begin/end paradigm was unnecessary, but since you already have it it is ok). what i'm not seeing in your list are semantically pre-bound vertex arrays - i.e. glVertexPointer* & co - a fairly fundamental feature (even before we consider VBOs) . actually they are so fundamental that you'll need to have those covered before you consider the wrapper gl-functional; at the same time their implementation on top of es2 should be straight forward (and you need to have something along that line already for the begin/end gizmos).

other than that, automated texture mipmap generation (glTexParameteri(GL_GENERATE_MIPMAP)) and tex combiners (glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_COMBINE)) would be very nice to have, but their absence would not stop earth's turning.

glad to hear you intend to publish the code, too!
i sincerely wish you best of luck in this endeavor.

ps: i dont believe that neon alone could beat sgx at vertex shading, but it could be used as a nice aux transform engine.

 

[Adventus]

@Pickle Thanks for the offer. I'm pretty happy with using the PVR emulator at the moment. I'll probably have my own pandora once i start Neon-izing stuff. Try the objdump, i really have no idea if it will detect Neon instructions.

QUOTE
what i'm not seeing in your list are semantically pre-bound vertex arrays - i.e. glVertexPointer* & co - a fairly fundamental feature (even before we consider VBOs)
Yep I've done that, but i haven't tested them yet. They are very simple, basically just wrappers around the generic glVertexAttrib.

QUOTE
ps: i dont believe that neon alone could beat sgx at vertex shading, but it could be used as a nice aux transform engine.
Woops sorry for not begin clear, i meant neon-ized matrix operations (glRotate, glScale, glTranslate, glFrustrum, etc). They look like prime targets, ie a full 4x4 matrix mulitplication costs 64 fmul and 48 fadd (however you can reduce this significantly by tracking what types of operations were previously done on the matrices).

But using Neon for vertex tranformations might be a good idea aswell.... but a significant amount of work (unless i just altered parts of Mesa's software renderer). I would definitely do display lists first though.

 

[ldesnogu]

I'm wondering if a Neon-ized tranformation pipeline might actually outperform the OGLESv1.1 driver, do they use Neon in the driver?

The version of the drivers I have don't use NEON. But I'm not sure it makes sense to use NEON or the ARM processor to process vertices, I'd expect that to be done by some vertex shader, and in that case I bet the vertex shader will outperform NEON code

EDIT: oups sorry missed the last 2 answers...