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 <luis...@gmail.com> wrote: > 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
