How Many People Know How To Use Opengl Es?

[TrevorBradley]

I'll jump in here late.. Is there any kind of online resource similar to lazyFoo's SDL tutorials?

http://lazyfoo.net/SDL_tutorials/

I've found them invaluable for getting off the ground for SDL programming.

It doesn't need to be super polished (LazyFoo did an awesome job) but it would be good to get a good overview of what OpenGL ES can and can't do.

Generally surfing Google, this looks pretty good:

http://www.zeuscmd.com/tutorials/opengles/index.php

I believe I'm doing too much graphics primitives in my projects to justify a switch, but I still have to be thinking ahead to the next game.

 

[JayFoxRox]

I knew Direct3D8, then moved to Direct3D9, some OpenGL between that but found it too hard to use.
Now learned HLSL and GLSL (for both, OGL and OGLES) and I have no problem to find out how to get the graphics the way I want them by looking at samples etc.
I never learned any of the above using books or something, I usually read alot on gamedev and I have a huge collection of samples collected from the internet or applications and SDKs
The worst thing about OGLES is probably the matrix stuff because I m still having problems constructing these, however, my matrix and vector classes are almost done now, so the fun can begin

 

[Eniko]

Feel free to tell me if this is a patently silly idea (as in there's no real benefits) but wouldn't it be possible for those in the community who are OpenGL ES buffs to create a set of "standard shaders" everyone who isn't quite so adept could use to move their code from 1.1 to 2.0?

Or would that be silly because there's no benefit at all from doing that instead of just keeping people using the fixed function pipeline?

 

[Capn_Fish]

Or would that be silly because there's no benefit at all from doing that instead of just keeping people using the fixed function pipeline?

That would be inventing the wheel again, AFAIK. The current fixed-function pipeline is set up to be as generic as possible, and that's what this would have to be. It could always be smaller or something, but if you're looking for specialized, that's what the shaders are for.

If you still want some, there's a fairly large one in the Gold Book that is supposedly quite similar to the 1.1 fixed stuff. I don't know if it can be downloaded, though (and it would be a pain to just type it all up).

 

[BenTolputt]

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...

*laugh* One of the 'next-gen' consoles as an embedded system! I don't know if you were being serious or not, but that was funny. The XBox 360 (to take your example) has three cores at 3+GHz each and a 500Mhz GPU with 48 parallel floating-point dynamically-scheduled shader pipelines. The closest that unit comes to embedded is it's RAM being only 512MB.

I wish I had embedded systems like that to play with!

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.

The issue is the matrix of having individual "features" turned on & off... unless you have some very wasteful shaders. Think about just the following items (nowhere near a comprehensive list):

• Polygon Offset on/off
• Fog on/off (exponential or linear)
• Multitexturing on/off (for varying numbers of textures and differing operations)
• Lighting on/off (with up to eight different lights being individually turned on & off)

Just those features alone creates alot of complexity. Each individual combination is a piece of cake - but as the GPU driver writer, you don't know which ones they are going to iuse so you have to cater for them all. That code would go on top of the vertex/fragment shader architecture that already exists. No problems for a desktop machine, but not something that would fit well into your standard mobile phone platform (the maini driver of "embedded" 3D graphics today).

 

[darkblu]

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...

*laugh* One of the 'next-gen' consoles as an embedded system! I don't know if you were being serious or not, but that was funny. The XBox 360 (to take your example) has three cores at 3+GHz each and a 500Mhz GPU with 48 parallel floating-point dynamically-scheduled shader pipelines. The closest that unit comes to embedded is it's RAM being only 512MB.

I wish I had embedded systems like that to play with!
erm, a game console is and embedded system, by definition - http://en.wikipedia.org/wiki/Embedded_system

QUOTE

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.

The issue is the matrix of having individual "features" turned on & off... unless you have some very wasteful shaders. Think about just the following items (nowhere near a comprehensive list):

• Polygon Offset on/off
• Fog on/off (exponential or linear)
• Multitexturing on/off (for varying numbers of textures and differing operations)
• Lighting on/off (with up to eight different lights being individually turned on & off)

Just those features alone creates alot of complexity. Each individual combination is a piece of cake - but as the GPU driver writer, you don't know which ones they are going to iuse so you have to cater for them all. That code would go on top of the vertex/fragment shader architecture that already exists. No problems for a desktop machine, but not something that would fit well into your standard mobile phone platform (the maini driver of "embedded" 3D graphics today).

as somebody who's been down this road, i.e. implementing a shader mimicing the fixed pipleline (bloody artists' apetite has no end), i have to side with BenT here - such a shader ends up so utterly inefficient, that you are entirely at the mercy of the shader compiler, hoping it'd figure out its way in the uniforms-ridden hell in there. last thing you want is computing 7 black lightsources for your overbudget geometry.

 

[Svartalf]

*laugh* One of the 'next-gen' consoles as an embedded system! I don't know if you were being serious or not, but that was funny. The XBox 360 (to take your example) has three cores at 3+GHz each and a 500Mhz GPU with 48 parallel floating-point dynamically-scheduled shader pipelines. The closest that unit comes to embedded is it's RAM being only 512MB.

I wish I had embedded systems like that to play with!

If you work in the telecom space or the land mobile radio space, you actually do end up with stuff in that class- regularly... Right now we're playing with 12-core Cavium boards with similar class of CPUs for the application processor. You can't do deep packet inspection or traffic monitoring at the OC3-OC12 levels without that sort of stuff and you can't do server or desktop type coding because they expect at least four nines if not 5+ out of the stuff.

QUOTE

The issue is the matrix of having individual "features" turned on & off... unless you have some very wasteful shaders. Think about just the following items (nowhere near a comprehensive list):

• Polygon Offset on/off
• Fog on/off (exponential or linear)
• Multitexturing on/off (for varying numbers of textures and differing operations)
• Lighting on/off (with up to eight different lights being individually turned on & off)

Just those features alone creates alot of complexity. Each individual combination is a piece of cake - but as the GPU driver writer, you don't know which ones they are going to iuse so you have to cater for them all. That code would go on top of the vertex/fragment shader architecture that already exists. No problems for a desktop machine, but not something that would fit well into your standard mobile phone platform (the maini driver of "embedded" 3D graphics today).


Heh... Yeah... Thing is, you get this with ES 1.1 anyhow. All they did is what we're talking about here on that API edge. Thye didn't concern themselves with anything else but the fixed functionality mode code- you don't get additional shader functionality- just what was precompiled for you. The fixed functionality vertex path, sans vertex skinning is very doable if you don't concern yourself with anything else (The Gold book even provides the code as an example of how complex you can get your shaders in ES...) - ditto the fragment path. Now, worrying about both, that's a mess unless you provide it as a snap-in shader that you either use IT or your other shaders- if you leave it up to the application developer, it's just a bit more precompiled shader code...

as somebody who's been down this road, i.e. implementing a shader mimicing the fixed pipleline (bloody artists' apetite has no end), i have to side with BenT here - such a shader ends up so utterly inefficient, that you are entirely at the mercy of the shader compiler, hoping it'd figure out its way in the uniforms-ridden hell in there. last thing you want is computing 7 black lightsources for your overbudget geometry.

Oh, that's just nasty. I'd tell 'em to go come up with better shaders that specifically does what they need of the programmable pipelines (I know I would- no default fixed-functionality wrapper is going to handle that nicely anyhow...) and forget the crutches there.