[cl-opengl-devel] CL-OpenGL ES?

[Simon Ortiz]

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 at gmail.com> wrote:
> On Tue, Jun 28, 2011 at 4:03 PM, Simon Ortiz <o.simon at 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/
>