On Tue, Sep 2, 2008 at 12:05 PM, Bart Botta <[EMAIL PROTECTED]> wrote:
> Any objection to removing the aliases that were auto-generated for the
> names that end with _BITS but aren't bitfields? (usually queries for #
> of bits in something)
Not really. Thanks for keeping us updated!
--
Luís Oli
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 mul
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
2008/8/30 Bart Botta <[EMAIL PROTECTED]>:
> Does it sound reasonable to split the binding generation into 3 steps,
> only 2 automatic:
> First would parse the .spec files, tracking any enum groups defined in
> the file, approximately splitting up function names, etc. and write
> the results to some
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.
>
> Sound
Here's the relative thread from Jon Leech on the OpenGL forum:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=244945#Post244945
and of course the link to the registry : http://www.opengl.org/registry
___
cl-opengl-devel mailing
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.
> Can anyone remind me why were they collapsed into one enum?
Sounds like a reaso
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
On Mon, Aug 18, 2008 at 2:49 PM, Bart Botta <[EMAIL PROTECTED]> wrote:
> So add a gl3/ and then split the existing files in gl/ between the two?
Sounds good.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
___
cl-opengl-devel mailing list
cl-opengl
On Sun, Aug 17, 2008 at 8:30 PM, Luís Oliveira <[EMAIL PROTECTED]> 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-ope
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 understan
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?
Keeping the ffi level stuff separate is probably easier than trying to
split it into 3 parts (common, p
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
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 de
14 matches
Mail list logo
