OpenGL 3 spec has been released: http://www.opengl.org/registry/doc/glspec30.20080811.pdf
Instead of the originally planned rewrite, it ended up being just more stuff piled onto the old API, but they did add a mechanism for deprecating old features, and a way to create contexts which cannot use deprecated features.
Any opinions on adding a cleaned up, gl3+ only version of cl-opengl which doesn't support the deprecated features or most of the older extensions, either as a fork, a separate mode for the main codebase (alternate .asd or with compile time checks), or some other way?
--- -b-
On Tue, Aug 12, 2008 at 2:55 AM, Bart Botta 00003b@gmail.com wrote:
Any opinions on adding a cleaned up, gl3+ only version of cl-opengl which doesn't support the deprecated features or most of the older extensions, either as a fork, a separate mode for the main codebase (alternate .asd or with compile time checks), or some other way?
Adding a cl-opengl3 system sounds like a good idea.
On Thu, Aug 14, 2008 at 11:30 AM, Luís Oliveira luismbo@gmail.com wrote:
Adding a cl-opengl3 system sounds like a good idea.
With completely separate code, or with it shared in some way?
Keeping the ffi level stuff separate is probably easier than trying to split it into 3 parts (common, parts of 3+ not shared by older versions, and parts of older versions removed from new versions). For lisp level stuff, it might be worth factoring out common code, though differences in valid arguments might make that harder...
By my count, full gl3 core has about 620 functions total. Without deprecated functions, there are 286 left. (for comparison, I count 336 in gl1.0 + 1.1, of which 78 remain after removing deprecated functions)
-b-
On Thu, Aug 14, 2008 at 5:57 PM, Bart Botta 00003b@gmail.com wrote:
On Thu, Aug 14, 2008 at 11:30 AM, Luís Oliveira luismbo@gmail.com wrote:
Adding a cl-opengl3 system sounds like a good idea.
With completely separate code, or with it shared in some way?
I clearly don't understand the difficulties involved. :-) But what about this: cl-opengl3.asd would load whatever is needed by the non-deprecated parts of GL 3.0. cl-opengl.asd would load everything. (including cl-opengl3.asd, on which it would depend.)
Would that work?
On Sun, Aug 17, 2008 at 8:30 PM, Luís Oliveira luismbo@gmail.com wrote:
I clearly don't understand the difficulties involved. :-) But what about this: cl-opengl3.asd would load whatever is needed by the non-deprecated parts of GL 3.0. cl-opengl.asd would load everything. (including cl-opengl3.asd, on which it would depend.)
Would that work?
I think so, main problem i can think of offhand is that there are probably places where some arguments are only valid for the full context. I guess we already have that situation with extensions though, so that is just a case of not cleaning up the gl3fc code quite as much as is theoretically possible.
So add a gl3/ and then split the existing files in gl/ between the two?
-b-
On Mon, Aug 18, 2008 at 2:49 PM, Bart Botta 00003b@gmail.com wrote:
So add a gl3/ and then split the existing files in gl/ between the two?
Sounds good.
Another issue with GL3 that I forgot about: the enums for GL_DEPTH_BUFFER_BIT etc. accepted by glClear are abbreviated to :depth-buffer in current cl-opengl, but gl3 adds unrelated enums like GL_DEPTH_BUFFER that would conflict with some of those. Should we just remove the abbreviations (and update the samples that use them)? Possibly add a warning in glClear if the old names are used?
-b-
cl-opengl-devel@common-lisp.net
-
Bart Botta -
Luís Oliveira