Saturday, December 10, 2011

OpenGLES I want my GL_QUADS back :(

The minimalism of OpenGLES2 is beginning to bug me.  I know too much about mechanical sympathy and graphics to completely see eye-to-eye with the architecture astronauts that the companies send to Khronos meetings just to get them away from the people who can do real work ;)

I have two approaches you can take when porting existing, working OpenGL code to OpenGLES2 whilst trying to have a common-as-possible codebase that targets all the OpenGL flavours:

  1. Rewrite things to use attribute arrays and OpenGLES2-supported calls and it will mostly work on the newer, other OpenGL flavours.  Stuck trying to run the same code on Windows with OpenGL 1.1 is not so fun though
  2. Write a mapping layer

As it is I started on (2) but have ended up doing (1).  (1) is less effort time-wise for me than (2), but if (2) already existed then it would be the clear winner.  Does such a useful mapping already exist?

You could imagine a mapping layer that stored all the glVertex() calls in an array and punched out a modern call when you do the glEnd().  And likewise storing all the various client-side state in, guess what, client-side variables and so on.  You could imagine it being like GLEW but loading OpenGL dynamically at runtime and so exposing classic superset of all supported OpenGL that it then maps to the target.

Myself my code is all VBOs but glVertexPointer etc don’t exist on OpenGLES2.  And they don’t seem to have anything like hand-holding of interleaving arrays, meaning when I interleave my arrays myself.

Oh the pain!

Its like they don’t want to have any sensible migration path for existing code.  They put so many small barriers to cheap migrating that in the end it adds up to a massive hurdle.  Its about as much hassle to move to OpenGLES2 as to move to DirectX11 instead.

Of all the things missing in OpenGLES2 its GL_QUADS that irritates and inconveniences me most.  All my font glyths and particle effects and some game tiles are GL_QUADS and I can’t think of a good reason for not supporting them.  It really grates to be duplicating a couple of vertices for each quad when targeting precisely the most memory-constrained target.  I guess in the end its no big deal, but it just feels wrong.

Its all too easy to imagine the architecture astronauts sitting around a table saying ‘well you can make a quad from two triangles, and sometimes if they aren’t on a plane you want to control the fold anyway, so lets get rid of yet another primitive!’.  I guess I’m bitter and cynical about design-by-committee.

What possible justification can there be for not having GL_QUADS?  If there’s some mechanical antipathy, I want it explained!

Notes

  1. williamedwardscoder posted this

 ↓ click the "share" button below!