After looking at it a bit more, I think trying to split out the enums
is going to be too much work to block gl3 support for (and possibly
too much work in general). The .spec files have lots of parameters
mapped to enum directly, many of the enums that do exist are
incomplete or need split into
On Mon, Aug 18, 2008 at 3:05 PM, Bart Botta [EMAIL PROTECTED] wrote:
On Mon, Aug 18, 2008 at 1:29 PM, Luís Oliveira [EMAIL PROTECTED] wrote:
Actually, I wouldn't mind seeing the per-function enums come back.
Having compile-time warnings when we passed a bogus keyword was nice.
Sounds like a
On Sat, Aug 30, 2008 at 5:27 PM, Luís Oliveira [EMAIL PROTECTED] wrote:
Sounds good to me. It'd be great if this process could somehow
highlight changes in the spec so that step 2 can be focused on what
changed instead of having to review everything.
Yeah, that was the idea, though I'm
On Thu, Aug 14, 2008 at 5:57 PM, Bart Botta [EMAIL PROTECTED] wrote:
On Thu, Aug 14, 2008 at 11:30 AM, Luís Oliveira [EMAIL PROTECTED] 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
On Tue, Aug 12, 2008 at 2:55 AM, Bart Botta [EMAIL PROTECTED] 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
