How Many People Know How To Use Opengl Es?

[Capn_Fish]

I'm mostly wondering how much support I can expect with OpenGL ES stuff from people on this forum.

I'm also curious how people learned OGLES (I've got the Gold Book, but would like to know of other useful resources), so if you'd be so kind to post links to websites/books/etc., that would be great, or even just a book title.

I hope this hasn't been posted before (I DID search), and hope I can get some help when I need it.

Thanks.

 

[darkblu]

plenty of people around here are ok with es - don't be shy to ask gl/es question on this forum : )

re how they learned it - i'm willing to bet you a dollar that the majority of them just came from desktop gl (missing from your poll, btw : )

in this regard, and since you seem to be looking for advice on that - learning the gl ecosystem is smoothest on the desktop - almost every desktop has it (vistas nonwithstanding). just stay away from the begin/end paradigm. also, for es 2.x you will need to learn to manage with shaders alone, but glsl is a breeze anyway.

anyway, best of luck with your gl/es studies - the pandora will surely be the best pocket R&D platform for that.

 

[Eniko]

also, for es 2.x you will need to learn to manage with shaders alone, but glsl is a breeze anyway.
What do you mean by this exactly?

 

[Lazrhog]

If you know openGL, openglES is easy. If you don't it's about the same as learning openGL. I'll post some code samples when Ive got a pandora (missed 1st batch, but have neverball and neverputt waiting to go straight on !)

 

[Capn_Fish]

also, for es 2.x you will need to learn to manage with shaders alone, but glsl is a breeze anyway.
What do you mean by this exactly?

"The OpenGL ES Shader Language is easy" is about what I get out of it, with the addition of "you need to learn to code without the fixed-function pipeline and to code your own shaders."

I am somewhat familiar with OpenGL, but ES is throwing me for a loop. I guess I should just go start posting questions...

Good to know people are willing to help!

 

[lek]

I have the 'OpenGL ES 2.0 Programming Guide':

http://www.amazon.co.uk/OpenGL-ES-2-0-Prog...9336&sr=8-1

Although I'm completely new to OpenGL ES myself. I bought it as more of a reference for (hopefully) making use of ES 2.0 on the Pandora. It has lots of examples and plenty of confusing bits too, shaders appear to be covered in detail.

I'm certainly willing to help with anyone's questions where I can (wouldn't be much help at the moment though! )

 

[Svartalf]

I'm mostly wondering how much support I can expect with OpenGL ES stuff from people on this forum.

I'm also curious how people learned OGLES (I've got the Gold Book, but would like to know of other useful resources), so if you'd be so kind to post links to websites/books/etc., that would be great, or even just a book title.

I'm more of an OpenGL type of guy...

The Gold Book is a good start. Realizing that OpenGL ES is more of a subset of each type of OpenGL that it was derived from than a different API, one can also use a bit of good OpenGL books with hints on what to/not to do to make it largely OpenGL ES compatible so that you don't tie yourself to ES specifics without full knowlege of what you did to yourself (It would be nice if you could do your homebrew/indie stuff for more than just Pandora, right? ). With that in mind, I suggest the book from my former boss (who now works for AMD's ES group as one of their managers...), the OpenGL Superbible by Wright, Lipchak (my former boss), and Haemel (the team lead for my group when I was contracting for AMD...). It covers all sorts of OpenGL topics, including ES in a nice and handy reference for this sort of thing.

"The OpenGL ES Shader Language is easy" is about what I get out of it, with the addition of "you need to learn to code without the fixed-function pipeline and to code your own shaders."

There's two ES targets on the Pandora. ES 1.1 and ES 2.0. If you target ES 2.0, you need to specify shaders from start to finish (there's no default behavior, per se, there...), and the vertex array, VBO, etc. coding is largely the same from OpenGL ES 1.4->2.1 past that. Shaders aren't as complicated as one would think they are, but they CAN be a pain in the backside as you've got to come up with all the things like Fog, etc. yourself. Since you're used to the "old" OpenGL, perhaps using 1.1 might be a better fit there?

QUOTE

I am somewhat familiar with OpenGL, but ES is throwing me for a loop. I guess I should just go start posting questions...



Heh... Best way of going about this, I suspect.

also, for es 2.x you will need to learn to manage with shaders alone, but glsl is a breeze anyway.
What do you mean by this exactly?


Heh... What he means is that there's extra coding work involved if you use OpenGL ES 2.0.

OpenGL provides this rendering pipeline model that has things like lighting, fog, etc. all accounted for and you just specify what values you want to apply to this fixed functionality model to render your scene. OpenGL 1.5 and then later on 2.0 specifies an advanced scheme where you have a default behavior, but you can programatically override this with an "assembly language" or later a C-like high-level description language (GLSL...) that applies whatever sorts of behaviors you want to the pixel data being put to the screen. DirectX went through a similar iteration of steps, with an "assembly language" and a C-like specifcation language called HLSL...

ES 1.1 provides a similar (almost identical, actually) means for the fixed functionality path programming.

ES 2.0 strips all the fixed functionality away and provides only the programmable path. If you want fixed
functionality behaviors, you will have to come up with an appropriate set of shaders to apply to the rendering path and transform path. I think you might get the simplest of default behaviors, but past that, you're on your own.

. just stay away from the begin/end paradigm.

Also avoid display lists. ES doesn't support those either.

 

[zacaj]

The book OpenGL ES 2.0 Programming Guide has been useful, and http://www.zeuscmd.com/tutorials/opengles/index.php are useful for 1.1

 

[Capn_Fish]

It's encouraging that nobody's voted for either of the "I know OGLES but won't help people" options.

@Svartalf: So if I don't need fog or lighting, I can basically ignore the shading language? Also, I've been planning on using "GLfloat VertexList[] = {...}; glDrawArrays(...)", or maybe glDrawElements (whichever makes more sense in the context). That's the appropriate way to go about it, right?

<shameless plea for answer>
My questions, FWIW:
http://www.gp32x.de/board/index.php?showtopic=45979
</shameless plea for answer>

The book OpenGL ES 2.0 Programming Guide has been useful, and http://www.zeuscmd.com/tutorials/opengles/index.php are useful for 1.1


Bookmarked! I assume at least some stuff transfers to OGLES 2.0, hopefully basic rendering stuff (not fog/lighting/etc, but drawing primitives in 3D space)?

 

[Eniko]

ES 2.0 strips all the fixed functionality away and provides only the programmable path. If you want fixed
functionality behaviors, you will have to come up with an appropriate set of shaders to apply to the rendering path and transform path. I think you might get the simplest of default behaviors, but past that, you're on your own.
Can anyone shed light on why this was done? Seems rather silly to make everyone reinvent the wheel every time.

Also, just so I don't have to recode my OpenGL rendering (again) is it possible to use vertex buffers and fixed functionality (at least I'm assuming it is...) like this on the Pandora?CODE
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
gluOrtho2D(0, ScreenWidth, 0, ScreenHeight)
glMatrixMode(GL_MODELVIEW)
Or do I need to start looking for GLSL shaders for the most basic of things?

 

[BenTolputt]

Eniko:
It was probably done for purposes of memory/performance. Remember that OGL ES2.0 was designed for MUCH lower-end platforms than the Pandora. I have worked in mobile phone software development (GIS/mapping display and routing and social network interfaces) and most phones do not have much to work with. A large executable/DLL to provide both the "scripted" (GLSL) functionality along with the fixed-function pipeline is likely too much for most developers.

That said, OGL ES2.0 is not hard to learn, and with the capability of ignoring features of the fixed-function pipeline you don't need - you can improve performance quite a bit. I would not be surprised if it simplified hardware design too

 

[Svartalf]

It's encouraging that nobody's voted for either of the "I know OGLES but won't help people" options.

Nice that nobody's chose to be obnoxious?

QUOTE

@Svartalf: So if I don't need fog or lighting, I can basically ignore the shading language? Also, I've been planning on using "GLfloat VertexList[] = {...}; glDrawArrays(...)", or maybe glDrawElements (whichever makes more sense in the context). That's the appropriate way to go about it, right?



As for the actual rendering calls, yeah, you want to use array rendering operations as that's how you do things in ES. For 2.0, though, you WILL have to provide some shader support (I checked back up on it and you'll need to supply SOME sort of shader... If you're not using fog, etc. this is as simple as:

CODE

GLbyte vShaderStr[] =
"attribute vec4 vPosition; \n"
"void main() \n"
"{ \n"
" gl_Position = vPosition; \n"
"} \n";
GLbyte fShaderStr[] =
"precision mediump float; \n"
"void main() \n"
"{ \n"
" gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0); \n"
"} \n";



..where vShaderStr is the vertex path shader fShaderStr is the fragment path one. This reproduces the fixed functionality path with NO options turned on.

QUOTE

Bookmarked! I assume at least some stuff transfers to OGLES 2.0, hopefully basic rendering stuff (not fog/lighting/etc, but drawing primitives in 3D space)?


It should handle the drawing part well enough. Keep in mind, we are supposed to get the 1.1 API edge as well, and unless you're needing the pipelines or the few extra functionalities that 2.0 brings over 1.1, you should probably stick with 1.1 as it's what you've got in hand and it'll do precisely what you're looking for without needing the few extras from 2.0.

 

[Svartalf]

Eniko:
It was probably done for purposes of memory/performance. Remember that OGL ES2.0 was designed for MUCH lower-end platforms than the Pandora. I have worked in mobile phone software development (GIS/mapping display and routing and social network interfaces) and most phones do not have much to work with. A large executable/DLL to provide both the "scripted" (GLSL) functionality along with the fixed-function pipeline is likely too much for most developers.


Heh... You'd be amazed at what they've got under the hood of an OpenGL API layer and the supporting driver underneath. In most modern GPU driver/API combos, you have a programmable pipeline engine with NO fixed functionality present. With the DX10 capable devices, you can even pick and choose which GPU processing elements are actively Vertex, Fragment, Geometry, or GPGPU in varying combinations.

Now, you might say, "if there's no fixed functionality present, how does the API provide it?"

To this, I will reply that the driver provides emulation shaders that get placed in the mix that provide the desired fixed functionality behavior (ShaderGen's about to be revisited again (It lives but the good working version only resides on my HD right at the moment as something I revived from 3DLabs' lost past...) because it's a helpful tool for people to wean themselves OFF of fixed functionality...). These do not arbitrarily replace the programmable pipeline operations, they get applied with this complex set of rules and while the rules are largely followed to the letter, these rules don't always give you what you expect.

QUOTE

That said, OGL ES2.0 is not hard to learn, and with the capability of ignoring features of the fixed-function pipeline you don't need - you can improve performance quite a bit. I would not be surprised if it simplified hardware design too


I'd have to concur on that aspect- overall, ES 2.0 isn't too hard to learn and it can unlock a lot more cool stuff for you if you pay attention to what you're doing. Having said this, if you've got an older piece of code or you're not ever going to need the programmable stuff for your project, it's not unreasonable to stick with ES 1.1 instead.

As for ignoring features of the fixed function pipe improving performance, that remains to be seen. The fixed function pieces didn't get applied even in the old days when we didn't have programmable pipelines until you specified something other than the default behavior. As for simplification...it dramatically simplifies the driver and API layer code and little else at this point.

]Can anyone shed light on why this was done? Seems rather silly to make everyone reinvent the wheel every time.

This is because of the fact that most embedded system solutions using ES are going to be memory constrained (technically, we're that ourselves, but the constraint's so big compared to what they were envisioning using this with, that it might as well be unlimited for us... )- moreover, it's simple enough to supply a basic shader that does this that it's a minimal thing on your part and if people are going to mostly do shader based stuff, having defaults on that piece on an embedded system equates to extra bloat there just to make it 'easy' on the people that're not going to use it.

QUOTE

Also, just so I don't have to recode my OpenGL rendering (again) is it possible to use vertex buffers and fixed functionality (at least I'm assuming it is...) like this on the Pandora?CODE
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
gluOrtho2D(0, ScreenWidth, 0, ScreenHeight)
glMatrixMode(GL_MODELVIEW)
Or do I need to start looking for GLSL shaders for the most basic of things?

You can use the basic ones I provided in a previous comment or you can use the ES 1.1 API edge instead and sidestep the problem completely.

 

[Capn_Fish]

I thought OGLES 2.0 and 1.x weren't compatible, or is that just code-wise and if OGLES 2.0 acceleration is hardware-supported, 1.1 is as well?

To be honest, I like the whole idea of shaders. It seems like it should make it easy to get exactly what I want with fewer calls (especially for simple lighting, which requires way too many calls in OGL, IIRC). Also, learning new stuff is fun.

Thanks for all the help. I think I'm finally getting this stuff!

 

[Svartalf]

I thought OGLES 2.0 and 1.x weren't compatible, or is that just code-wise and if OGLES 2.0 acceleration is hardware-supported, 1.1 is as well?

It's more code-wise than anything else- what we call OpenGL ES 1.1 and 2.0 aren't "drivers" but rather API edges that talk to a much more primitive driver layer. The APIs in question tell the graphics hardware how to express the rendering that the programmer requests. In the case of ES 1.1 on the SGX we've got, it's something that supplies a set of pre-defined shaders lego-block stuck together to provide the fixed functionality and doesn't expose ANY of the programmable parts whatsoever. So, you'll compile and link against either the ES 1.1 or the ES 2.0 API library when you do this stuff, depending on if you're coding fixed functionality or doing programmable pipeline stuff.

QUOTE

To be honest, I like the whole idea of shaders. It seems like it should make it easy to get exactly what I want with fewer calls (especially for simple lighting, which requires way too many calls in OGL, IIRC). Also, learning new stuff is fun.



Indeed it is. I'm probably going to stick with 1.1 stuff for the first couple of ports I'm doing just so we can get the games done and out the door for the Pandora, otherwise I'd be trying to do the 2.0 rendering version of it.

QUOTE

Thanks for all the help. I think I'm finally getting this stuff!


You're welcome.

 

[Xmas]

I know OpenGL ES well and am willing to help newbies – after all that's my job.

 

[BenTolputt]

Heh... You'd be amazed at what they've got under the hood of an OpenGL API layer and the supporting driver underneath. In most modern GPU driver/API combos, you have a programmable pipeline engine with NO fixed functionality present. With the DX10 capable devices, you can even pick and choose which GPU processing elements are actively Vertex, Fragment, Geometry, or GPGPU in varying combinations.

Actually, I wouldn't be amazed at all. I've worked on low-level stuff before (admittedly not GPU drivers), and I am well aware of how things get done at this level. On the other hand, what DX10 does underneath has no bearing on what would be done in an embedded environment (i.e. where OGL ES is deployed).

Now, you might say, "if there's no fixed functionality present, how does the API provide it?"

Other's might say that, but I wouldn't

Seriously though, the fact that they can add code to implement the fixed function using GLSL-writing mechanisms under the hood is a problem in low memory environments. I can tell you from experience that when you're coding something on a mobile platform - having an extra 50K-100K of memory can make or break functionality (at least for applications likely to be using OGL ES). Given a competent OGL ES developer, that extra "interface" code in the OGL ES driver is wasted memory that could be used for something the developer needs.

For the purposes of the actual thread topic though - I know how to use OGL ES and have no hassles sharing my knowledge. On the other hand, I'm kinda impatient so I'll give some advice & code snippets but am not the person to come to for an indepth tutorial

 

[PokeParadox]

I have to make my leap to adapt to using ES. I'm a GL guy myself. But I'd be willing to pass on what I learn...

 

[Svartalf]

Actually, I wouldn't be amazed at all. I've worked on low-level stuff before (admittedly not GPU drivers), and I am well aware of how things get done at this level. On the other hand, what DX10 does underneath has no bearing on what would be done in an embedded environment (i.e. where OGL ES is deployed).

If you count the X-Box 360 as an embedded system, it actually, perversely has bearing. Having said this, I wouldn't care to know...

QUOTE

Other's might say that, but I wouldn't



I kind of boggled the first time I'd heard what they did out of Benj's mouth in the first week of my stint with AMD's GPU division. Thinking on it, though, it made sense. It also makes sense what they did with ES and what a lot of people had hoped they'd do with Longs Peak.

QUOTE

Seriously though, the fact that they can add code to implement the fixed function using GLSL-writing mechanisms under the hood is a problem in low memory environments. I can tell you from experience that when you're coding something on a mobile platform - having an extra 50K-100K of memory can make or break functionality (at least for applications likely to be using OGL ES). Given a competent OGL ES developer, that extra "interface" code in the OGL ES driver is wasted memory that could be used for something the developer needs.



Actually, you'd be surprised what they can do. In the case of the fixed functionality support, you can do everything but vertex skinning on the vertex side with only about 75 or so lines of GLSL, if the Gold Book is to be believed. Looking at what ShaderGen produces, I'd have to say that it's possible for the bulk of it to be framed in via a special set of vertex and fragment shaders, leaving the compiler out of the picture and the 2.0 extras out as well. At that point you're mostly there with the fixed path stuff. As for the 50-100k making or breaking you- I'm VERY familiar with that. Been there, done that, with critical applications like P25 trunking systems.

QUOTE

For the purposes of the actual thread topic though - I know how to use OGL ES and have no hassles sharing my knowledge. On the other hand, I'm kinda impatient so I'll give some advice & code snippets but am not the person to come to for an indepth tutorial



Heh... I'm working around the quirks between ES and OpenGL myself- being a bit of an OpenGL guy.

 

[Capn_Fish]

I've actually been pleasantly surprised that OGLES2 seems like a better version of OGL. The whole making your own shaders thing seems to me like the way things should be done (more specialized, fewer layers to go through, probably faster if well-written).

In other words, I haven't found OGLES2 to be quirky (as of now, that could well change).