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

_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel

Reply via email to