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

[Lester Vecsey]

It took me some time to find a copy of freeglut.dll to place into my system
folder, eventually retrieving it from
http://www.turtle.dds.nl/gl4newlisp/index.html

On windows the freeglut source is currently only meant to be built with
MSVC, as opposed to mingw/msys, and it may be some time until thats
resolved. So it might be a good idea to make a copy of the above mentioned
freeglut.dll available at the common-lisp.net/project/cl-opengl page.

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

As I understand it cl-opengl is currently dependent on freeglut to open a GL
canvas. Is there any interest in having a few C functions to call in to, or
perhaps written entirely in Lisp as CFFI to each of the required underlying
functions, to generate the Windows HWND and XWindows surfaces? On windows,
the WndProc functions which takes care of mouse and keyboard events would be
handled with a separate package, and similarly for XWindows with its
Xevents. The benefit here is that for many applications you may not need the
extensive menu system of freeglut and thus can eliminate the dependency on
that library.

The other question I have is about the scope of cl-opengl, in terms of
handling applications meant to run at 60hz frame rate in the following
sense; it would seem that cl-opengl would be the place to have a compiler of
sorts, to handle a common situation where conditionals are placed in the
main rendering loop to draw sets of Gl primitives. Suppose in my
application I toggle one of these such that now the rendering loop makes an
additional call into a function that has a glDrawArrays call for some set of
polygons, along with other conditionals in the function that branches for 
choosing
between other GL primitives. An extra set of polygons may be drawn with a 
bright color
 to draw attention to some part of the visual model, and so on.
This is where cl-opengl functions or macros would step in because my Lisp 
code thus wrapped with some opengl-with
statements would effectively have these gl primatives bundled into 
consecutive display lists where
applicable such that in the final analysis there are just a minimal set of
glCallList statements being made to the hardware. Those very same calls to
glCallList would persist for many frames until the application toggles
additional code so that only the affected and adjacent display lists get 
rebuilt.
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.

As I understand it that was one of the stated goals of the cells opengl 
framework though having looked through the current cl-opengl code the 
closest thing I can come to this is found in util.lisp, and no examples as 
of yet to do the above. If this can be cleanly addressed conceptually by 
adopting some layout when implementing applications I'd like to hear about 
that too. Currently for my OpenGL programs I've amassed a set of lower level 
C functions that take variables representing states, i.e. packed into an 
unsigned 32 bit value, and use display lists and just recompute the 
important ones where appropriate. A set of Lisp wrappers would probably 
dramatically change the way such code would look and is approached, making 
it much more compact in terms of number of lines and perhaps even packed 
maximally linearly efficient, so to speak, for eliminating unnecessary gl 
statements in the main loop, all with little effort from the programmer.

As a specific example, a call to reset the glColor to white at the beginning 
of a functions processing that may have much more work to do, depending on 
its current toggles, could actually be tossed into a preexisting display 
list from the previous function that had its trailing end of work to do. 
However doing that manually is out of the question since it would involve 
much more code, either a dedicated display list for that one area or even 
more time consuming if statements in other functions so it can be tacked on. 
Overall, once packed into the list it would be a very minor performance win 
by reducing just that one call for a gl primitive, for sure, however it 
could add up when you consider the overlap of various functions in the main 
loop each of which are doing some subwork.

In a C language perhaps the framework would look something like having 
function pointers to a heading and trailing set of gl primitive code which 
would be considered static for each of the subwork functions, perhaps 
labeled header and footer, and the actual dynamic code that the subwork 
function implements itself. Assuming the guts of the subwork function 
becomes ``static'' for at least a few frames, then all of it can be absorbed 
into a display list and in fact the entire function with all its 
conditionals effectively disappears, from a gl runtime perspective. Later 
that portion of the display list can be regenerated to that depth when 
requested by a mouse or key toggle, i.e., an outside function, and be called 
again down to that depth so it is fully rebuilt with current values, and 
re-absorbed into the current master chain or set of the minimal amount of 
display lists.

Imagine a scenario where hundreds of frames have gone by with no changes 
from network, mouse, or keyboard events. Then its possible that all the gl 
calls can be placed into a single display list and at some point the list 
will have to be split so that different code can be inserted. So if the main 
list was previously in two sublists before, and some feature was just 
toggled back on then it might be a good idea to have kept those sublists 
around for a while so now three lists are ready to be called; the outer two 
sublists, and the newly recomputed feature. After many frames pass, sublists 
that have gone unchanged can be merged together. And again, code that is 
likely to change every frame would simply never be wrapped with these lisp 
macros to begin with.