Re: Best practices for OpenGL ES

[Sylvain <beuc@debian.org>]

Hi,

(still digging digging old threads :))

(we were discussing on supporting OpenGL ES, and implication this
presented)

I'm currently working on porting FreeGLUT for Android (which uses
GLES) and for Mesa EGL/GLES.  I also just had a look at SOIL as well.

As far as I can see, if we want to support GLES1 and GLES2 in Debian,
we'll have to double- or triple- compile, not only the OpenGL
application, but also all the OpenGL-based libraries.

For instance, we'd get:
- freeglut3
- freeglut3-gles1
- freeglut3-gles2
- freeglut3-dev
- freeglut3-dev-gles1
- freeglut3-dev-gles2

These packages, including the -dev's, will need to be installable in
parallel.  The freeglut.h file will likely be generated since: it will
not load the same gl.h; there will be double vs. float differences;
some functions may also just disappear in GLES flavours.

The application package will have to depend on the right variant.

We may also get interesting chains of dependencies.  For instance,
assuming SFML is ported to GLES someday, we could have:

  mygame-gles2 -> sfml-gles2 -> soil-gles2

Am I missing something more simple, or is this the way to go?

- Sylvain

On Wed, Feb 01, 2012 at 09:24:55PM +0100, Julien Cristau wrote:
> On Wed, Feb  1, 2012 at 09:01:33 +0100, Sylvain wrote:
> 
> > Hi,
> > 
> > On Mon, Jan 16, 2012 at 11:58:54PM +0100, Tobias Hansen wrote:
> > > Am 16.01.2012 23:40, schrieb Sylvain:
> > > > On Mon, Jan 16, 2012 at 08:29:37PM +0100, Julien Cristau wrote:
> > > >> On Mon, Jan 16, 2012 at 20:01:51 +0100, Sylvain wrote:
> > > >>
> > > >>> Alternatively, can the packages detect the OpenGL version at runtime
> > > >>> and act accordingly?
> > > >>>
> > > >> You can detect the GL version and extensions at runtime as much as you
> > > >> want.  GL vs GLES is not the same thing though.
> > > > 
> > > > Yeah, I meant "detect the OpenGL ES/non-ES variant at runtime and act
> > > > accordingly".
> > > 
> > > No, the program can't be linked against both libGLESv2 and libGL.
> > 
> > Sorry for digging an old thread but - theoretically, the program could
> > use dlopen(3) right?
> > 
> This way lies madness.
> 
> Cheers,
> Julien