[Openmcl-devel] opengl

[Gary Byers]

On Thu, 3 Mar 2005, David Steuber wrote:
>
> GLUT is a separate framework on OS X.  I haven't done anything with
> it.  I was under the impression that GLUT was somehow related to the
> aux stuff from the red book.  Perhaps I'm wrong?

GLUT provides a portable (and not-too-deep) layer for OpenGL programs
that deals with inherently non-portable things (like window management
and event handling.)  In theory (and in practice, to a large degree),
GLUT programs are portable between OSX and Windows and X11 and ...

"ccl:examples;opengl-ffi.lisp" is an (early) example that uses GLUT.

GLUT_BITMAP_HELVETICA_10 is (conditionally) defined as

#define GLUT_BITMAP_HELVETICA_10	((void*)6)

(in /System/Library/Frameworks/GLUT.framework/Headers/glut.h ),
and neither the interface translator nor the rest of OpenMCL believes
much in the concept of constant-valued pointers.  (There's presumably
-some- difference between (%INT-TO-POINTER 6) and a pointer returned
from a call to #_malloc; the former is "constant valued" in some sense
and the latter isn't, but it's not entirely clear how to maintain that
distinction.)

SAVE-APPLICATION basically changes the type of all MACPTRs to be
CCL::DEAD-MACPTR, which is supposed to help catch cases where a
saved image references something allocated dynamically (via #_malloc).
If it decided that a pointer with a "small" address couldn't possibly
have been allocated dynamically, it could skip this and the concept
of "constant valued pointer" would be a little more meaningful.  "Small"
might be something arbitrary, like "16 or fewer significant bits in
the address, if it's treated as a signed integer."

If that "concept of a constant-valued MACPTR" existed, the interface
translator could probably translate things like ((void*)6) into
something like the result of (%INT-TO-PTR 6), but it currently doesn't
even try.