OpenGL ES 1.1, 2.0 References

Discuss programming topics that involve the OpenGL API.
Post Reply
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

OpenGL ES 1.1, 2.0 References

Post by Baker »

Almost all mobile devices support OpenGL ES 1.1 (name a phone and it supports OpenGL 1.1 ... even other portable devices stuff like the Pandora [if anyone still ever thinks of that device] and well ... the PS3 which isn't really a mobile device) and almost all the popular mobile devices currently sold (as opposed to a couple of years old) support OpenGL ES 2.0.

Official References for OpenGL ES 1.1 and OpenGL ES 2.0:

OpenGL ES 1.1: http://www.khronos.org/opengles/sdk/1.1/docs/man/
OpenGL ES 2.0: http://www.khronos.org/opengles/sdk/docs/man/

[Interesting note: Note in the Wikipedia articles that OpenGL ES 2.0 is apparently the standard for WebGL. And *cough* it won't work on older Intel GMA which according to Wikipedia "In early 2007, 90% of all PCs sold had integrated graphics." because "Many older Intel graphics cards (e.g. GMA950) don't support programmable shaders, so they cannot be used to render WebGL content. " ... ]

OpenGL ES 1.1 does not support glBegin or glEnd or any of the "manual" vertex stuff or glTexCoord2f type of stuff. (Hmmm ... how would, say, Quake animation interpolation look in that. And just by that thought you can tell I haven't poked around at that part of DarkPlaces or FTE or even Qrack for that matter or anything else that uses vertex arrays.)

OpenGL ES 2.0 does not support any of the "immediate" functions like glPopMatrix and you don't use glRotatef or glScalef or glTranslatef apparently. *sniff* I understand the advantage of the "fixed function pipeline stuff" but I kinda have always liked the ability to use glPushMatrix to offset from the "camera" and then draw something and use glPopMatrix to restore everything back to how it was. In some ways this is preferable to ... I guess ... having to calculate your own matrix as Spike has described how it works. I suppose this disallows some of the other matrix fun too (in favor of having to wrap your head around some complicated calculations.) And I guess OpenGL ES 2.0 hates quads.

[I bet 3 months from now I'll probably look back on these things with 2.0 as trivial ... but today it seems like a headache ...]
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: OpenGL ES 1.1, 2.0 References

Post by mh »

GMA 950 does support programmable shaders, in D3D via HLSL/Shader Model 2.0 and in GL via GL_ARB_vertex_program and GL_ARB_fragment_program.

PS3 supports PSGL which is GLES 2.0-like but everybody uses the lower level libgcm instead.

Quads aren't supported natively by any consumer hardware; the driver must convert them to triangles during setup. Not supporting quads is a sensible move towards actually exposing what's on the hardware and only what's on the hardware; the ancient esoteric crap in GL is a primary source of the problems with GL drivers. Triangles have the advantage that all 3 points are guaranteed to lie on the same plane; not so with quads. The driver can make assumptions and optimize based on that.

For animation interpolation you use a vertex shader. One array pointer at the current frame's verts, one array pointer at the previous frame's (you can abuse a texcoord pointer but you really should be using generic attrib arrays), send the blend as a uniform and let the GPU do the work. Put them into VBOs and you never have to update the verts during runtime. This is a pet peeve of mine - loading work onto the CPU when the GPU is better able to do the job. Classic id Quake is only using at most 40% of your GPU; you can get it to 97% by just shifting appropriate work over. I really need to write a rant about that some day.

If you don't have shaders you might have GL_ARB_vertex_blend but that's not very widely supported; the extension came in at much the same time as vertex shaders, any hardware that can support vertex blending also supports shaders, so it really has no reason to exist. (D3D can do fixed pipeline vertex blending though so the hardware is definitely still capable; it's just not supported in the driver.)

The matrixes thing is not that big a deal; you can write your own wrapper (or use one of the available free matrix libraries) to replicate the job of the old function calls.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Post Reply