[Chris Marshall <chm@al...>]

On 2/24/2011 7:34 PM, Jason Wilkins wrote:
 >
> My bindings to GLUT are new, so I you could not have seen them.  There
> is an existing lua/glut wrapper but it was incomplete and wasn't
> exactly what I wanted so I started a new set which I haven't made
> public yet.

Ok.

> But you are right about the idea.  Start with straight bindings then
> make it more idiomatic.
>
> I plan on making a LuaGLEW as well, but it is such a big project that
> right now I'm just using LuaGL but it doesn't cover modern OpenGL,
> only up to like 1.3

Well, I'm planning to implement Perl OpenGL using GLEW
instead of a hand-rolled implementation.  That has the
advantage of increased portability and simplified
development of the bindings (since GLEW does a lot
of the work for you).  It also has the benefit of
instant support for OpenGL up through 4.1.  I'll let
report back on how that goes if you are interested.

Regarding GLUT/FreeGLUT, I plan to implement support
for the new glutInitErrorFunc() and glutInitWarningFunc()
along with support for GLUI.  I would also like to
figure out a way to support original GLUT as much as
possible (maybe through a reverse-callback approach).

Cheers,
Chris

> LuaGL reduces the number of functions from GL considerably since it
> only uses doubles (Lua's only numeric type) and does some nice things
> to hide C arrays and the functions are all variadic.  I'll probably
> copy that pretty much, but I'll also give access to all of OpenGL's
> extensions.
>
> On Thu, Feb 24, 2011 at 6:17 PM, Chris Marshall<chm@...>  wrote:
>
>> On 2/24/2011 1:42 PM, Jason Wilkins wrote:
>>>
>>> I'm keeping faithful to the original GLUT API, even though it would
>>> probably be better to allow any Lua object to be passed to a timer
>>> callback.  It's the same with menu callbacks.  My preferred technique
>>> for handing menus is to just have all the Menu item ids in a hash
>>> table.  Then the callback function becomes very simple.
>>
>> For the Perl OpenGL and GLUT implementations we've
>> started with a direct translation of the OpenGL
>> and GLUT C APIs.  That allows someone to use the
>> module based on existing code and documentation.
>>
>> The next step is to make things more idiomatic
>> perl (e.g., all the various routines for different
>> data types can be merges into a single, simpler
>> routine that does the right thing).  This is the
>> same thing you have done already in some of your
>> bindings.
>>
>> One difference in the Perl FreeGLUT bindings is that
>> we use an array to link the various identifiers with
>> the data/refs/callbacks/... as needed.  GLUT itself
>> uses integers so it works quite naturally.  In perl
>> data access by array index is *much* faster than hash
>> table lookup by key.
>>
>> Cheers,
>> Chris