[Freeglut-developer] RE: Full speed ahead to 2.4.0

[Fay J. F C. AAC/W. <joh...@eg...>]

Dam,

	Thanks for your response.  Right now I'm looking to freeze the
configuration and ask JC Jones cut the first release candidate on Friday.
Unless you have already-working code, that isn't enough time to get OpenGL
ES support into 2.4.0.  If you don't have working code, I propose that we
get 2.4.0 out the door at the end of May and then look into OpenGL ES
support, planning for a new release shortly after we get that support put
in.  If you do have working code, if you send it to me I will try putting it
in with conditional compilation before Friday.

John F. Fay
850-729-6330
joh...@eg...
 
-----Original Message-----
From: Dam Backer [mailto:db...@gm...] 
Sent: Tuesday, May 03, 2005 3:15 PM
To: Fay John F Contr AAC/WMG
Cc: fre...@li...
Subject: Re: Full speed ahead to 2.4.0

John,

Apologies for not responding sooner. I just found a bug in gmail notifier,
where it disconnects without notifying the user. Sorry, lame excuse :-)

Anyway, yes there still is great interested in an OpenGL ES compatible
freeglut. My initial request for this support was based on my own SDK
development and a general feel for the usefulness of this established
library. Recently the Khronos group (in charge of defining the OpenGL ES
standard) has put forward a more direct request for GLUT support.
For those who are not aware of OpenGL ES (embedded systems), it is targeted
to be the 3D Graphics API of choice for cell phones and handheld devices
with embedded hardware accelerated 3D graphics. Here are some of the issues
that come to mind when porting freeglut to OpenGL ES:
- Since we are talking about embedded systems, the size (both storage and
memory usage) of the applications and libraries are a concern.
- Another issue with support for embedded systems is the variety of
operating systems. Though it is possible to make some assumptions
(availability of ANSI C/C++) it would be good to abstract the OS specific
parts of the code to allow easy porting to many new operating systems. Also
porting it to semi-OS's like Qualcomm's BREW would be good.
- Since OpenGL ES 1.0 is a subset of Desktop OpenGL 1.3 there are some
OpenGL functions that are not available in OpenGL ES. In my implementation I
cut out some of the functions that used in-compatible OpenGL calls and
converted some others.
- Some embedded systems lack support for double and floating point math.
OpenGL ES comes in profiles that include or exclude floating point support
and instead use fixed point math. The "Common" profile allows (but typically
discourages) floating point formats while the Common-Lite profile has no
floating point formats at all.

I'll see if I can share the Khronos groups GLUT subset proposal with this
group in a follow up email.

Looking forward to discussing the needed changes to freeglut to enable
OpenGL ES support.

Sincerely,
Dam Backer