[cl-opengl-devel] Re: freeglut.dll + scope of cl-opengl

[Lester Vecsey]

----- Original Message ----- 
From: "Luís Oliveira" <luismbo at gmail.com>

>
> I don't have convenient access to Windows. When I have the chance I will
> compile freeglut and upload it to c-l.net. cl-opengl is still in its
> infancy, anyway.
>

The 249,344 byte freeglut.dll from 
http://www.turtle.dds.nl/gl4newlisp/freeglut.dll worked just fine for me on 
WinXP SP2, so you could just mirror that to the common-lisp.net site for 
now. All the redbook examples and the mesa gear demo ran just fine with 
this.

>
>> A couple other minor notes with the redbook examples so far. With CLISP, 
>> the
>> character #\Esc is mentioned in rb3-lines.lisp and rb4-poly.lisp, and 
>> above,
>> and had to be changed to #\Escape
>
> #\Esc works for me in CLISP. What version are you using?
>

Its CLISP 2.38 compiled with mingw/msys on windows,

> See above. Rolling our own GLUT-like thing in Lisp might have various
> advantages. Namely, we wouldn't have to worry about the C library
> rudely calling exit(), sigh.
>
> Anyone is free to start such a project, I'd certainly use that!
>
> CL-GLUT is just a convenient way of *playing* with cl-opengl and OpenGL
> in general. That was my goal while writing those bindings anyway.
>

I can probably contribute some code for this at some point, which on windows 
creates a window and sets up a GL canvas, as well as registering a Common 
Lisp ``WndProc'' callback function which gets called by the Microsoft OS 
whenever a message is sent to the created window, i.e. a keyboard or mouse 
event. I'm currently developing an app using cl-opengl so I'll see about 
merging some of that in, and if it gets to a point where I can contribute it 
back I'll let you know.

> [...]
>> The programmer would use these wrappers only around code that would 
>> benefit
>> from having these display lists built to persist over more than a few
>> frames.
>
> One of cl-opengl's goal is to be Lispy so it only makes sense that
> a convenient way to use display lists will be designed even if not as
> fancy as what you suggest.
>
> Sounds interesting though. I've never seen the cells opengl stuff but
> surely cells-opengl can be implemented using the cl-opengl bindings.
>

cells opengl was initially meant for the hello-c FFI interface though they 
may have moved to CFFI now. It always seemed like a moving target and so the 
examples, such as a light and texturing application, never ran for me. 
Anyhow its worth looking into to see where they are going with it, if it is 
still being developed at all. The cells project itself revolves around the 
concept of having a spreadsheet so to speak, where when certain cells are 
modified then only the related ones get recomputed. So there may be a way to 
use that approach to deal with some of the display list issues.