Re: Best practices for OpenGL ES
Hi,
On 09/05/2012 09:43 PM, Vincent Fourmond wrote:
> I'm curious: what are the differences between vanillia and ES GL ?
> Are they binary-incompatible for the symbols they share ? From other
> messages in this thread, they seem to be source-compatible at least to
> some level.
GLES is "more or less" a subset of GL, but formally, GLES can have stuff
that GL does not have, AFAIK, fixed-point arithmetic is something GLES
has and GL does not necessarly handle as well.
Example, looks like GL_FIXED, which was available in GLES 1, was
introduced in OpenGL 4.2 only :
http://www.opengl.org/discussion_boards/showthread.php/178844-GL_FIXED-documentation
But you could consider this as a detail, where GL and GLES fundamentally
differ is that GL is an "all-packed-in-one" library with backwards
compatibility, whereas GLES has an "anti-Perl, There Is Only *ONE* Way
To Do It" approach. GLES will give you one way to do things, and very
likely, only one. For instance, the fixed pipeline has been removed from
GLES2, so anything written for GLES1 needs to be rewritten, since GLES2
uses shaders and has no fixed pipeline, while GLES1 uses the fixed
pipeline and has no shaders. Plain vanilla GL will allow to use any of
these approaches, and tolerate a program written a long time ago.
Globally, the restrictions imposed by GLES are not that bad in practice,
since it might be considered good practice to choose either fixed
pipeline or shaders, and not mix them.
My opinion on the subject, however, is that while GLES might be very
well suited for proprietary programs on embedded platforms which are
written and thrown away at a very fast pace, for free stuff with
development spanned on several years, it's a pain. A program written for
GLES1 won't compile on GLES2. At all. You don't want to need to rewrite
your program just because GLES3 is out...
Have a nice day,
Christian.
--
Christian Mauduit
ufoot@ufoot.org
http://www.ufoot.org
int q = (2 * b) || !(2 * b);
Reply to: