Luís, you're right. OpenGL ES 1.1 is a subset of OpenGL 1.5 plus the egl* functions and a new data type: the fixed-point.
Bart, I don't know much about WebGL other than it's based on OpenGL ES 2.0.
I haven't had enough time to fiddle with cl-opengl nor with the parser. So I think my opinion might not be well informed enough.
From my ignorance, I would vote for loading only the relevant bits for
ES. Given that it's going to run in a constrained environment, less loading is better (less memory consumption, faster loading time... although the difference in both could be dismissible). Plus, it might be safer. Would ugly things happen if you call a function defined in cl-opengl that isn't in OpenGL ES 1.1?
I have some questions about the cl-opengl-base approach: would it require subtracting the common bits from the spec for cl-opengl? Or would the common bits be overwritten in cl-opengl?
Would the cl-opengl-base approach scale nicely? Let's say we want to add ES 2.0, do we revise cl-opengl-base so that it is the intersection of functions in OpenGL 4.1, OpenGL ES 1.1 and OpenGL ES 2.0? Would this also be necessary if someone wanted to add WebGL, and when a new version of OpenGL is released?
I guess the other approach would be to have independent systems.
Yes, it's a shame ES doesn't have a spec file. If we take the independent system route, we could start from the spec of OpenGL 1.5 and remove the functions that aren't in ES 1.1.
As Luís says, the egl* functions are few. Maybe we could also add them by hand to the ES 1.1 spec file.
What do you guys think?
-- Simón Ortiz B., M.Sc., Ing. en Computación Linux Registered User #388735
On Tue, Jun 28, 2011 at 20:15, Luís Oliveira luismbo@gmail.com wrote:
On Tue, Jun 28, 2011 at 3:35 AM, Bart Botta 00003b@gmail.com wrote:
The "spec" that cl-opengl parses is a more-or-less machine readable file available at http://www.opengl.org/registry/, not the actual specification. I'm not aware of anything similar for ES, so if the functions are not included in the main .spec files some other strategy would be required.
Right, I was assuming that ES would also have a .spec file. That doesn't seem to be the case.
I'd probably just parse the .h files to get a rough translation then edit it by hand from there, if the versions don't overlap as much as desktop GL.
The set of egl* functions seems small enough to take this route. I'd probably even skip the .h parsing step.
The remaining questions are: do we want a cl-opengl-es-1.1 system that only loads the relevant bits? (As opposed to defining the egl* bits then loading all of the remaining cl-opengl.) If so, what would be the best way to do it?
One solution would be to list the ES's gl* functions somewhere in our spec directory and have the spec parser output those definitions to a separate directory/system, let's call it cl-opengl-base. Both cl-opengl and and cl-opengl-es-1.1 would then depend on cl-opengl-base.
Simon, does this look like a sane approach?
-- Luís Oliveira http://r42.eu/~luis/