Alright!
Let me see if I got it all straight:
For our first approach, I'll do a cl-opengl-es-1.1 system which will depend on cl-opengl as is. I'll write the CFFI definitions for the egl* functions by hand. I guess I'll define the fixed-point data type by hand too.
Then we see how to clean it up, if it's worth it.
I'll start working this weekend. Since I still need to understand cl-opengl in more depth, this could take a while.
I'll keep you posted with the progress (and troubles ;-)
Thanks!
-- Simón Ortiz B., M.Sc., Ing. en Computación Linux Registered User #388735
On Wed, Jun 29, 2011 at 00:57, Luís Oliveira luismbo@gmail.com wrote:
On Tue, Jun 28, 2011 at 4:03 PM, Simon Ortiz o.simon@gmail.com wrote:
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 thing you'd simply get an undefined function error from CFFI.
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?
The former seems cleaner.
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?
Not sure about nicely, but I suppose you could have a cl-opengl-base-1.1, cl-opengl-base-2.0, etc. If one's going to think about a layout like this in depth, it'd be interesting to take OpenGL profiles into account too.
I guess the other approach would be to have independent systems.
However, we most certainly want to avoid duplication on the GL package since that package contains high-level abstractions that aren't automatically generated.
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.
I don't think adding them to the spec file is worth the trouble. Writing the CFFI definitions by hand is probably much simpler. I suggest you create a cl-opengl-es-1.1 system, make it depend on cl-opengl and add the egl functions to a new EGL package.
We can then tackle the cl-opengl-base issue if it's worth the trouble.
Cheers,
-- Luís Oliveira http://r42.eu/~luis/