3b / cl-opengl Goto Github PK

• translate official GL docs into some easier format (or figure out docbook), updating types with lisp types from %GL: bindings if possible
• add versions of translated docs for things wrapped in GL: package, updated for any automatic translations or whatever
• document any GL: features that don't correspond directly to the low-level GL API
• describe general idea of when and how to use %GL: directly
• add lisp example code, or links to example code in repo? (at least for more interesting parts of core profile)
• document automatic error checking and how to disable it
• info on GLU/GLUT?

gl:uniform-matrix takes an array of matrices to upload, but doesn't look like it would upload more than 1 correctly, probably should be (mem-aref ... (+ (* i matrix-size) j)) instead of (* i j)

(also, that is a sort of inconvenient API, should have a way to upload just 1 matrix directly, upload from lists, etc)

I saw a case where enum keyword->value->keyword conversion was giving me a different keyword.
I experienced this with :front-left which becomes the value 1024 which converted back to a keyword becomes :stencil-buffer-bit.

I have run a quick sweep to see what other cases I could find. The results can be found at the following gist: https://gist.github.com/cbaggers/76b4fa06a35a48790639

Am I misunderstanding something about cffi and enums, or is this an issue?

The gl:uniformfv function name implies that it is a binding to glUniform*fv (meaning glUniform1fv, glUniform2fv, etc.) but instead it's just a kind of vector-destructuring wrapper around gl:uniformf. Also, gl:uniformiv is missing entirely. Without bindings to glUniform*fv and glUniform*iv, it is difficult to provide certain kinds of data to shaders.

My guess is that there has been a simple misunderstanding about what glUniform*fv does. It takes a float vector of an arbitrary length (not limited to 4), and treats it as an array of vectors. glUniform1fv treats it as an array of single floats, glUniform2fv treats it as an array of float pairs (i.e. vec2's), and so on.

So in C, if I wanted to use an array of 10 vec4's, I'd create an array with 40 floats in it, then call glUniform4fv(location, 10, *my_array_of_40_floats). The first 4 items (0-3) in the array would form the first vec4, items 4-7 would form the second vec4, items 8-11 would form the third vec4, and so on, with items 36-39 forming the tenth/final vec4.

You can accomplish the same thing by querying OpenGL for the uniform location of the first element in the array, then calling glUniform*f with that location, then querying for the location of the second element in the array, then calling glUniform*f with that new location, and so on for every element in the array. But using glUniform*fv is much easier and more efficient. :-)

My recommendation is to document the current gl:uniformfv function as deprecated, to be removed at a later date. If you want to keep the "destructuring" wrapper around gl:uniformf, it should have a different name that won't be misleading.

Then, to add the missing functionality, I'd suggest adding gl:uniform-fv and gl:uniform-iv, each taking a sequence of sequences (e.g. #(#(1 2) #(3 4) #(5 6)), although lists would be allowed too). The length of the first inner sequence can be used to decide which glUniform*fv function to use, and the length of the outer sequence (i.e. the count of inner sequences) can be used for the "count" argument of glUniform*fv.

If that sounds good to you, I will be happy to write the code. Or, if you think it should have a more C-ish API (passing one long sequence, instead of nested sequences), we could do that instead.

Nickname :gl clashes with https://github.com/sharplispers/clx/blob/master/gl.lisp

need to figure out how to add the hook to reset extension pointers

Update fglrx driver solved a problem.

Platfroms:
SBCL 1.0.40.0.debian
FreeGlut 2.6.0
ATI AMD FGLRX proprietary

Step to reproduce:
(require :cl-glut)
(glut:init)
(glut:init-display-mode :double :rgb :depth)
(glut:create-window "gears)

Unhandled memory fault at #x4.
[Condition of type SB-SYS:MEMORY-FAULT-ERROR]

Bactrace:
0: (SB-SYS:MEMORY-FAULT-ERROR)
1: ("foreign function: #x4218B0")
2: ("foreign function: #x421990")
3: ("foreign function: #x8009F78A40")
4: (SWANK::EVAL-REGION "(glut:create-window "gears")\n")
............

How can I take more info for you?

I'm following the great modern OpenGL tutorial at http://www.arcsynthesis.org/gltut/.
His words:

If you're wondering why it is (void*)48 and not just 48, that is because of some legacy API
cruft. The reason why the function name is glVertexAttrib“Pointer” is because the last
parameter is technically a pointer to client memory. Or at least, it could be in the past. So
we must explicitly cast the integer value 48 to a pointer type.

If I want to use an integer index into a vertex array from CL, I have to use (cffi:make-pointer 48), which calls malloc on ECL. glVertexAttribPointer works with integers, passing a pointer to an int will actually not
work because it uses the address directly.

The same probably holds for glVertexAttribIPointer.

Since the binding is autogenerated, I'd need to special-case it to somehow not follow
the spec. What would be the best way to do that?

need to either switch ptrdiff-t back to (incorrect) unsigned type, or add uintptr or similar and use that.

Possible other option is to use :pointer as base type, but that would be more invasive change for probably no benefit.

Hello,

I have some vertex data that is stored as floats in a vector. I copy that into an array via cffi:foreign-alloc using the :initial-contents keyword argument. Then I call make-gl-array-from-pointer with that foreign-alloc'd memory. However, make-gl-array-from-pointer is not extern'd, which made me consider that I'm doing something wrong.

Is there a better way to be converting from a vector into a gl-array? In the samples I've come across, I see the conversion happening via an elment-by-element copy using setf with gl:glaref.

%gl:enum is defined as an :unsigned-int however the values for :timeout-ignored and :timeout-ignored-apple are

  (:timeout-ignored #xFFFFFFFFFFFFFFFF)
  (:timeout-ignored-apple #xFFFFFFFFFFFFFFFF)

which is outside the unsigned 32bit int range. Should these be #xFFFFFFFF ?

has happened twice, 1 each on sbcl and ccl, haven't been able to isolate it though

If the cffi api allows it, it might help to separate the lisp to foreign type conversion from the function call for extension functions, and inline the part with the type conversion, in hopes that the compiler could optimize or elide the conversion completely when types at the call site were known (for example when converting between numeric types).

Generating compiler macros to do as much of the type conversion at compile time as possible would probably also be useful, for things like enums and bitfields where the compiler is less likely to know they can be safely expanded at compile time even when it does know the lisp values.

http://paste.lisp.org/display/92279

ecl/msvc can't compile cl-opengl without patch from http://article.gmane.org/gmane.lisp.ecl.general/6176

I use quicklisp install it, but report this message:
Unable to load any of the alternatives:
("freeglut.dll" "libglut.dll" "libglut-0.dll")
[Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]

And I download freeglut.dll and put it into system/system32, but the same error was report.
i download freeglut from this website
http://files.transmissionzero.co.uk/software/development/GLUT/freeglut-MSVC-2.8.1-1.mp.zip

maybe my work is wrong, please help!

The functions that exist are pretty raw, and essential functions like gluTessCallback are commented out, or not implemented.

Freeglut:

glutInitContextVersion(3,2);
glutInitContextProfile(GLUT_CORE_PROFILE);

OSX 10.9?:

glutInitDisplayMode(... | GLUT_3_2_CORE_PROFILE);

Not sure if there is any easy way to hide the differences.

The documentation (gl4) for glTexParameter mentions the parameter GL_DEPTH_STENCIL_TEXTURE_MODE, but :depth-stencil-texture-mode errors out when used as a parameter with cl-opengl on a 4.3 context.

Probably expected, given the following comment from gl/types.lisp:

;;; XXX these will be broken on 64-bit systems that do not have 64-bit
;;; longs, such as Win64.  Need to define this type in CFFI and it may
;;; require some sort of grovelling or guessing.

It bit me recently when SDL2 returned a 64bit pointer for large (greater than 255x255px) surfaces.
Hotfix I applied to gl/types.lisp looks like this:

#+(and :WIN32 :X86-64) (defctype ptrdiff-t :unsigned-long-long)
#-(and :WIN32 :X86-64) (defctype ptrdiff-t :unsigned-long)

I am using SBCL (v1.1.17) and Windows 7. When I run the following in SLIME:

CL-USER> (ql:quickload "cl-opengl")
CL-USER> (ql:quickload "cl-glut-examples")
CL-USER> (cl-glut-examples:run-examples)

Most of the samples work fine but ... I do get errors for the SHADER-VAO demo:

  0: (CL-OPENGL-BINDINGS:CHECK-ERROR #<unavailable argument>)
  1: (CL-OPENGL-BINDINGS:GET-UNIFORM-LOCATION 3 #.(SB-SYS:INT-SAP #X01FA12E0))
  2: (CL-OPENGL:GET-UNIFORM-LOCATION 3 "angle")
  3: ((:METHOD CL-GLUT:TICK (CL-GLUT-EXAMPLES::SHADER-VAO-WINDOW)) #<CL-GLUT-EXAMPLES::SHADER-VAO-WINDOW {1004867CA3}>) [fast-method]
  4: ((LAMBDA (CL-GLUT:ID) :IN "C:/cygwin64/home/elliot/lisp/quicklisp/local-projects/cl-opengl/glut/interface.lisp") 132)
  5: ((LAMBDA (SB-ALIEN::ARGS-POINTER SB-ALIEN::RESULT-POINTER FUNCTION) :IN "C:/Users/Elliot/AppData/Local/common-lisp/cache/sbcl-1.1.17-win-x64/C/cygwin64/home/elliot/lisp/quicklisp/local-projects/cl-ope..
  6: ("foreign function: #x42CB8C")
  7: ("foreign function: #x403AD8")
  8: ("foreign function: #x200749F390")
  9: (CL-GLUT-EXAMPLES:RUN-EXAMPLES)
 10: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CL-GLUT-EXAMPLES:RUN-EXAMPLES) #<NULL-LEXENV>)
 11: (EVAL (CL-GLUT-EXAMPLES:RUN-EXAMPLES))
 --more--

I also find that if I run a sample directly, before doing anything else, then it hangs indefinitely until I interrupt it and kill the thread. For example, if I run (cl-glut-examples:rb-cube) before (cl-glut-examples:run-examples) then it will hang. But I reverse that order then (cl-glut-examples:rb-cube) will run fine.

I suspect that I might I have a version mismatch problem somewhere or perhaps some other configuration issue. Has anyone experienced anything else like this before?

Not sure if it is related, but if I run the (sdl2-examples:basic-test) before (cl-glut-examples:run-examples) then I get the same hanging behaviour. Since sdl2 depends on cl-opengl I thought I would ask here first about that issue.

I'm using CL-OPENGL with LISPBUILDER-SDL on two different machines--- a tablet pc with intel cpu/gpu, and a larger beefy media PC with an AMD processor and a pretty decent NVIDIA card. 3D acceleration works fine, and other Opengl stuff (screensavers, games etc) works,

but I cannot run any of the CL-OPENGL examples or my own code, I always get the backtrace shown below.

Indeed the single test expression (sdl:window 640 480 :opengl t) fails. I'll try playing with NVIDIA opengl options some more, Luke Crook suggested it might be color depth issues but I did not have immediate success in changing those.

Other data:
(sdl::video-driver-name) => "x11" ;;; this is also its value on the other machine, where it works fine
(sdl-cffi::sdl-get-error) => "Couldn't find matching GLX visual"

Let me know if there is any more i can do to help diagnose the issue.

Here's the backtrace:

The value NIL is not of type SYSTEM-AREA-POINTER.
[Condition of type TYPE-ERROR]

Restarts:
0: [RETRY] Retry SLIME REPL evaluation request.
1: [*ABORT] Return to SLIME's top level.
2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" RUNNING {B4022F1}>)

Backtrace:
0: (LISPBUILDER-SDL-BASE:SURF-W NIL)
Locals:
SB-DEBUG::ARG-0 = NIL
1: ((SB-PCL::FAST-METHOD LISPBUILDER-SDL::GET-RECTANGLE-* (LISPBUILDER-SDL:SDL-SURFACE)) # # #<LISPBUILDER-SDL::DISPLAY {B9D16F9}>)
Locals:
SB-DEBUG::ARG-0 = :
SB-DEBUG::ARG-1 = :
SB-DEBUG::ARG-2 = #<LISPBUILDER-SDL::DISPLAY {B9D16F9}>
2: ((SB-PCL::FAST-METHOD (SETF LISPBUILDER-SDL:CELLS) (INTEGER LISPBUILDER-SDL:SDL-SURFACE)) # # 1 #<LISPBUILDER-SDL::DISPLAY {B9D16F9}>)
Locals:
SB-DEBUG::ARG-0 = :
SB-DEBUG::ARG-1 = :
SB-DEBUG::ARG-2 = 1
SB-DEBUG::ARG-3 = #<LISPBUILDER-SDL::DISPLAY {B9D16F9}>
3: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER (LISPBUILDER-SDL::DISPLAY)) ..)
Locals:
#:ANY-FORMAT-DEFAULTING-TEMP = NIL
#:ASYNC-BLIT-DEFAULTING-TEMP = NIL
#:BPP-DEFAULTING-TEMP = 0
#:DOUBLE-BUFFER-DEFAULTING-TEMP = NIL
#:EVENT-FILTER-DEFAULTING-TEMP = #.(SB-SYS:INT-SAP #X011008D8)
#:FLAGS-DEFAULTING-TEMP = 2
#:FPS-DEFAULTING-TEMP = #<LISPBUILDER-SDL:FPS-MIXED {B9298C1}>
#:FULLSCREEN-DEFAULTING-TEMP = NIL
#:HEIGHT-DEFAULTING-TEMP = 480
#:HW-DEFAULTING-TEMP = NIL
#:ICON-CAPTION-DEFAULTING-TEMP = ""
#:NO-FRAME-DEFAULTING-TEMP = NIL
#:OPENGL-ATTRIBUTES-DEFAULTING-TEMP = NIL
#:OPENGL-DEFAULTING-TEMP = NIL
#:PALETTE-DEFAULTING-TEMP = NIL
#:RESIZABLE-DEFAULTING-TEMP = NIL
LISPBUILDER-SDL::SELF = #<LISPBUILDER-SDL::DISPLAY {B9D16F9}>
#:SW-DEFAULTING-TEMP = NIL
#:TITLE-CAPTION-DEFAULTING-TEMP = "Blocky and the Blue Dot"
#:WIDTH-DEFAULTING-TEMP = 640
4: ((SB-PCL::EMF INITIALIZE-INSTANCE) ..)
Locals:
SB-PCL::.ARG0. = #<LISPBUILDER-SDL::DISPLAY {B9D16F9}>
SB-PCL::.DFUN-MORE-CONTEXT. = -310626811
SB-PCL::.DFUN-MORE-COUNT. = 20
5: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AROUND (LISPBUILDER-SDL::FOREIGN-OBJECT)) ..)
Locals:
SB-PCL::.NEXT-METHOD-CALL. = #S(SB-PCL::FAST-METHOD-CALL ..)
SB-PCL::.REST-ARG. = (:FPS #<LISPBUILDER-SDL:FPS-MIXED {B9298C1}> :FLAGS 2 :TITLE-CAPTION ..)
LISPBUILDER-SDL::SELF = #<LISPBUILDER-SDL::DISPLAY {B9D16F9}>
6: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) # # # #<unavailable &REST argument>)
Locals:
CLASS = #
SB-PCL::INITARGS = :
7: ((SB-PCL::FAST-METHOD LISPBUILDER-SDL:WINDOW (T T)) ..)
Locals:
LISPBUILDER-SDL:HEIGHT = 480
REST = (:FPS #<LISPBUILDER-SDL:FPS-MIXED {B9298C1}> :FLAGS 2 :TITLE-CAPTION ..)
LISPBUILDER-SDL:WIDTH = 640
8: (IOFORMS::RUN-MAIN-LOOP)
[No Locals]
9: (IOFORMS:PLAY "example2")
Locals:
IOFORMS:PROJECT = "example2"
10: (SB-INT:SIMPLE-EVAL-IN-LEXENV (IOFORMS:PLAY "example2") #)
Locals:
SB-DEBUG::ARG-0 = (IOFORMS:PLAY "example2")
SB-DEBUG::ARG-1 = #
11: (EVAL (IOFORMS:PLAY "example2"))
Locals:
SB-DEBUG::ARG-0 = (IOFORMS:PLAY "example2")
--more--

I inspected the DISPLAY object:

#<LISPBUILDER-SDL::DISPLAY {B9D16F9}>

Class: #

Group slots by inheritance [ ]
Sort slots alphabetically [X]

All Slots:
[ ] CELL-INDEX = 0
[ ] CELLS = NIL
[ ] DISPLAY-SURFACE-P = T
[ ] FOREIGN-POINTER-TO-OBJECT = NIL
[ ] FREE-FUNCTION = #<FUNCTION (LAMBDA (LISPBUILDER-SDL:FP)) {C4958ED}>
[ ] GARBAGE-COLLECT = NIL
[ ] POSITION-RECT = #<LISPBUILDER-SDL:RECTANGLE {BA8D699}>

With-pushed-matrix* does. What are the issues with making with-pushed-matrix behave sanely w.r.t. non-local exits? I assume that this is a deep issue since the fix is so simple and has already been implemented in With-pushed-matrix*?

As a test case:

(dotimes (i 33) (ignore-errors (with-pushed-matrix (error "Uh-oh"))))

might break conforming OpenGL programs. I'm not an OpenGL guru, am I missing something?

need to export an API for testing values of GLenum return values against keywords

for example running (cl-glut-examples:misc-opengl-array) prints a bunch of warnings like

STYLE-WARNING:
   bare references to struct types are deprecated. Please use (:POINTER
                                                               (:STRUCT
                                                                CL-GLUT-EXAMPLES::POSITION-COLOR)) or (:STRUCT
                                                                                                       CL-GLUT-EXAMPLES::POSITION-COLOR) instead.

Please consider adding :description, :author and :license information to your ASDF system(s). This will greatly help Quicklisp users and make it easier for them to report bugs.

More information:

http://blog.quicklisp.org/2015/05/looking-for-more-metadata.html
https://www.quicklisp.org

Hello,

I am running on Windows 7 x64 with an Nvidia card using Clozure Common Lisp 1.9 64-bit. When trying to run cl-glut-examples:gears, I am getting the following error:

? (cl-glut-examples:gears)

Error: Couldn't find function glEnable
While executing: CL-OPENGL-BINDINGS::GENERATE-GL-FUNCTION, in process listener(1).
Type :POP to abort, :R for a list of available restarts.
Type :? for other options.

I do not have any issues with the 2013-07-22 quicklisp dist. Any ideas on how I would begin to debug this? Please let me know if you need more information.

Thank you,
Mick

possibly allow generic sequences?
also versions of light,material that take separate args instead of arrays

Whenever I run into a condition in any of the GLUT-window event handlers the current window turns into a zombie on OSX, SBCL.

Example:
displaying a window with a working glut:display-implementation

(defmethod glut:display ((w my-window))
  'empty)

and then changing the implementation AFTER the window has appeared to:

(defmethod glut:display ((w my-window))
  (error "BAM"))

This will put me into the debugger in emacs with 3 possible restarts (e.g retry/abort/abort), however no matter what I choose the current window is now a zombie (i.e it is still visible but won't respond to ANY events, not event "close").

Also, fixing the condition-cause and hitting "retry" re-runs my top-level command, which was display-window (make-instance 'my-window)), which causes a new window to appear, but now GLUT eats 100% of my CPU for some reason.

I am guessing maybe the GLUT main loop becomes confused when event handlers don't return normally? Is there a way to salvage the window?

I've had this happen with both glut:display and glut:tick.

Hope the description makes sense :) Thanks!

When I do (ql:quickload :cl-opengl), I get the following error:

The value
  NIL
is not of type
  SB-THREAD:THREAD
   [Condition of type TYPE-ERROR]

Restarts:
 0: [TRY-RECOMPILING] Recompile library and try loading it again
 1: [RETRY] Retry loading FASL for #<CL-SOURCE-FILE "cl-opengl" "gl" "library">.
 2: [ACCEPT] Continue, treating loading FASL for #<CL-SOURCE-FILE "cl-opengl" "gl" "library"> as having been successful.
 3: [RETRY] Retry ASDF operation.
 4: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
 5: [ABORT] Give up on "cl-opengl"
 --more--

Backtrace:
  0: (SB-THREAD:INTERRUPT-THREAD NIL #<CLOSURE (LAMBDA NIL :IN CL-OPENGL-BINDINGS::%INVOKE-ON-INITIAL-THREAD) {100B41CF2B}>)
  1: ((FLET SB-THREAD::WITH-MUTEX-THUNK :IN "/Users/sly/projects/cl-opengl/gl/library.lisp"))
  2: ((FLET #:WITHOUT-INTERRUPTS-BODY-358 :IN SB-THREAD::CALL-WITH-MUTEX))
  3: (SB-THREAD::CALL-WITH-MUTEX #<FUNCTION (FLET SB-THREAD::WITH-MUTEX-THUNK :IN "/Users/sly/projects/cl-opengl/gl/library.lisp") {2350729B}> #<SB-THREAD:MUTEX "initial thread lock" owner: #<SB-THREAD:THR..
  4: ((SB-C::TOP-LEVEL-FORM (FLET ((SB-THREAD::WITH-MUTEX-THUNK NIL (CL-OPENGL-BINDINGS::%INVOKE-ON-INITIAL-THREAD #1=??? T) (SB-THREAD:WITH-MUTEX #1# #1# #1#))) (DECLARE (SB-INT:TRULY-DYNAMIC-EXTENT #2=(F..
  5: (SB-FASL::LOAD-FASL-GROUP #S(SB-FASL::FASL-INPUT :STREAM #<SB-SYS:FD-STREAM for "file /Users/sly/.cache/common-lisp/sbcl-1.3.14.133-1a3dabf1a-macosx-x64/Users/sly/projects/cl-opengl/gl/library.fasl" {..
  6: (SB-FASL::LOAD-AS-FASL #<SB-SYS:FD-STREAM for "file /Users/sly/.cache/common-lisp/sbcl-1.3.14.133-1a3dabf1a-macosx-x64/Users/sly/projects/cl-opengl/gl/library.fasl" {100B413F53}> NIL NIL)

see if gl:get* needs fixed to deal with duplicate GLenum problems...

on all platforms: error checking problem in #10

on windows: extension function pointers are context specific, so technically it should be storing a table of function pointers per context. In practice it is probably safe to reuse the pointers for contexts from same device (or even same driver for multiple similar GPUs), but won't work with GPUs from multiple vendors.

glut:get-modifiers export with wrong name "get-modifer"

patch

https://gist.github.com/904428.js?file=gistfile1.diff

wrong enums, should be :major-version, :minor-version

From docs dir:

$ make
sh gendocs.sh -o cl-opengl --html "--css-include=style.css" cl-opengl "CL-OpenGL User Manual"
Generating output formats for ~/cl-opengl/doc/cl-opengl.texinfo
Generating info files... (makeinfo -o cl-opengl.info ~/cl-opengl/doc/cl-opengl.texinfo)
~/cl-opengl/doc/cl-opengl.texinfo:137: @top used before @node, defaulting to cl-opengl.
~/cl-opengl/doc/cl-opengl.texinfo:167: `GLUT' has no Up field (perhaps incorrect sectioning?).
~/cl-opengl/doc/cl-opengl.texinfo:163: `GLU' has no Up field (perhaps incorrect sectioning?).
~/cl-opengl/doc/cl-opengl.texinfo:167: warning: unreferenced node `GLUT'.
~/cl-opengl/doc/cl-opengl.texinfo:163: warning: unreferenced node `GLU'.
makeinfo: Removing output file `cl-opengl.info' due to errors; use --force to preserve.
tar: cl-opengl.info*: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
Generating dvi ... (texi2dvi -t @finalout ~/cl-opengl/doc/cl-opengl.texinfo)
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) (preloaded format=etex)
 restricted \write18 enabled.
entering extended mode
(./txiversion.tex
! I can't find file `texinfo.tex'.
l.1 \input texinfo.tex 
                       @bye
(Press Enter to retry, or Control-D to exit)
Please type another input file name: 
! Emergency stop.
l.1 \input texinfo.tex 
                       @bye
No pages of output.
Transcript written on txiversion.log.
/usr/bin/texi2dvi: texinfo.tex appears to be broken, quitting.
Generating postscript...
This is dvips(k) 5.995 Copyright 2015 Radical Eye Software (www.radicaleye.com)
dvips: ! unexpected eof on DVI file
gzip: can't stat: cl-opengl.ps (cl-opengl.ps): No such file or directory
ls: cl-opengl.ps.gz: No such file or directory
mv: rename cl-opengl.ps.gz to cl-opengl/cl-opengl.ps.gz: No such file or directory
gzip: can't stat: cl-opengl.dvi (cl-opengl.dvi): No such file or directory
ls: cl-opengl.dvi.gz: No such file or directory
mv: rename cl-opengl.dvi.gz to cl-opengl/cl-opengl.dvi.gz: No such file or directory
Generating pdf ... (texi2dvi -t @finalout --pdf ~/cl-opengl/doc/cl-opengl.texinfo)
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) (preloaded format=pdfetex)
 restricted \write18 enabled.
entering extended mode
(./txiversion.tex
! I can't find file `texinfo.tex'.
l.1 \input texinfo.tex 
                       @bye
(Press Enter to retry, or Control-D to exit)
Please type another input file name: 
! Emergency stop.
l.1 \input texinfo.tex 
                       @bye
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on txiversion.log.
/usr/bin/texi2dvi: texinfo.tex appears to be broken, quitting.
ls: cl-opengl.pdf: No such file or directory
mv: rename cl-opengl.pdf to cl-opengl/cl-opengl.pdf: No such file or directory
Generating ASCII... (makeinfo -o cl-opengl.txt --no-split --no-headers ~/cl-opengl/doc/cl-opengl.texinfo)
~/cl-opengl/doc/cl-opengl.texinfo:137: @top used before @node, defaulting to cl-opengl.
~/cl-opengl/doc/cl-opengl.texinfo:167: `GLUT' has no Up field (perhaps incorrect sectioning?).
~/cl-opengl/doc/cl-opengl.texinfo:163: `GLU' has no Up field (perhaps incorrect sectioning?).
~/cl-opengl/doc/cl-opengl.texinfo:167: warning: unreferenced node `GLUT'.
~/cl-opengl/doc/cl-opengl.texinfo:163: warning: unreferenced node `GLU'.
makeinfo: Removing output file `cl-opengl.txt' due to errors; use --force to preserve.
ls: cl-opengl.txt: No such file or directory
gzip: can't stat: cl-opengl.txt (cl-opengl.txt): No such file or directory
mv: rename cl-opengl.txt to cl-opengl/cl-opengl.txt: No such file or directory
Generating monolithic html... (makeinfo --no-split --html -o cl-opengl.html --css-include=style.css ~/cl-opengl/doc/cl-opengl.texinfo)
~/cl-opengl/doc/cl-opengl.texinfo:137: @top used before @node, defaulting to cl-opengl.
~/cl-opengl/doc/cl-opengl.texinfo:167: `GLUT' has no Up field (perhaps incorrect sectioning?).
~/cl-opengl/doc/cl-opengl.texinfo:163: `GLU' has no Up field (perhaps incorrect sectioning?).
~/cl-opengl/doc/cl-opengl.texinfo:167: warning: unreferenced node `GLUT'.
~/cl-opengl/doc/cl-opengl.texinfo:163: warning: unreferenced node `GLU'.
makeinfo: Removing output file `cl-opengl.html' due to errors; use --force to preserve.
This is SBCL 1.3.6, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
sed: cl-opengl.html: No such file or directory
rm: cl-opengl.html: No such file or directory
Generating html by node... (makeinfo --html -o cl-opengl.html --css-include=style.css ~/cl-opengl/doc/cl-opengl.texinfo)
~/cl-opengl/doc/cl-opengl.texinfo:137: @top used before @node, defaulting to cl-opengl.
~/cl-opengl/doc/cl-opengl.texinfo:167: `GLUT' has no Up field (perhaps incorrect sectioning?).
~/cl-opengl/doc/cl-opengl.texinfo:163: `GLU' has no Up field (perhaps incorrect sectioning?).
~/cl-opengl/doc/cl-opengl.texinfo:167: warning: unreferenced node `GLUT'.
~/cl-opengl/doc/cl-opengl.texinfo:163: warning: unreferenced node `GLU'.
makeinfo: Removing output file `~/cl-opengl/doc/cl-opengl.html/index.html' due to errors; use --force to preserve.
This is SBCL 1.3.6, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
; $ mv ~/cl-opengl/doc/cl-opengl.html/Comprehensive-Index.html.temp ~/cl-opengl/doc/cl-opengl.html/Comprehensive-Index.html
; $ mv ~/cl-opengl/doc/cl-opengl.html/GLU.html.temp ~/cl-opengl/doc/cl-opengl.html/GLU.html
; $ mv ~/cl-opengl/doc/cl-opengl.html/GLUT.html.temp ~/cl-opengl/doc/cl-opengl.html/GLUT.html
; $ mv ~/cl-opengl/doc/cl-opengl.html/Introduction.html.temp ~/cl-opengl/doc/cl-opengl.html/Introduction.html
; $ mv ~/cl-opengl/doc/cl-opengl.html/OpenGL.html.temp ~/cl-opengl/doc/cl-opengl.html/OpenGL.html
Making .tar.gz for sources...
a cl-opengl.texinfo
Writing index file...
Done!  See cl-opengl/ subdirectory for new files.

$ ls -l cl-opengl
total 48
-rw-r--r--  1 me  staff     0 21 Dec 23:09 cl-opengl.html
-rw-r--r--  1 me  staff    35 21 Dec 23:09 cl-opengl.html.gz
-rw-r--r--  1 me  staff  2894 21 Dec 23:09 cl-opengl.html_node.tar.gz
-rw-r--r--  1 me  staff    45 21 Dec 23:09 cl-opengl.info.tar.gz
-rw-r--r--  1 me  staff  1912 21 Dec 23:09 cl-opengl.texi.tar.gz
-rw-r--r--  1 me  staff     0 21 Dec 23:09 cl-opengl.txt.gz
drwxr-xr-x  7 me  staff   238 21 Dec 23:09 html_node
-rw-r--r--  1 me  staff  5715 21 Dec 23:09 index.html

When I run glut examples from slime
(cl-glut-examples:run-examples)
I get an unhandled memory fault error and a bunch of blank frozen program windows.
I tested on two of my machines that have Arch Linux OS. This error happens immediately before any shape is rendered to the screen.

shader-vao example exits with No display callback registered for window 1 error

freeglut requires setting a callback with glutDisplayFunc before running main loop, so figure out if that should be done automatically by glut wrappers, or if the example is doing something wrong.

I'm not sure that this problem is directly a problem with cl-opengl, but that's where it's getting exhibited. I'm using SBCL save-lisp-and-die to create an executable which uses cl-opengl including glut fonts. The graphics are working find in the executable, but glut:bitmap-character with glut:+bitmap-9-by-15+ is not succeeding. After going through the source a bit, it appears that this should be a pointer to a font structure in the libglut.so library. It seems like the library is not being completely loaded, or the pointer is not valid once the binary is reloaded, perhaps because the pointer is different.

Regardless, I'm able to use the font just fine when running at the REPL, but the executable keeps reporting "freeglut (SBCL): font 0xb741db40 not found".

opticl and some other libs load images as 2/3d arrays (h,w,channels), so allow passing those directly to cl-opengl as texture data.

a few places convert boolean arguments to 0/1 before passing to %gl functions, need to find them and either verify that is correct, or just pass the boolean directly

gl:light-model, gl:pixel-store, gl:light-model, gl:tex-parameter

OSX requires GL/GLUT stuff to be done from initial thread.

CCL uses first thread internally by default, so need to rearrange threads there.

SBCL should work if cl-opengl is loaded before slime, or slime isn't using :spawn communication style

not sure about other lisps...

opengl treats first image data as starting with bottom row, but most image formats/libs start with top row.

Flipping shouldn't add much cost since it is doing a copy to foreign memory anyway, and would be very convenient.

GLAREF and (SETF GLAREF) pass types to CFFI at runtime, so are mush slower than they should be.

Need to write some benchmarks to figure out how slow, and try to improve it (and test on multiple Lisps).

Possible fixes:

• dispatch on common types passing constant types to CFFI in each branch
  Much faster than letting CFFI do lookups at runtime, but a bit verbose and probably ends up inlining a bunch of unused code.
• compile specialized thunks to store in the array types, and call those to read/write the values
  Less dead code, but not sure how expensive the extra function calls will be (probably still much better than runtime CFFI types though)
• change the API to allow specifying a static type
  Should produce the fastest/smallest code, but not sure if it would be convenient to use. Breaking the existing API would probably be bad too, so would want one of the other solutions for existing code anyway.

error checking code closes over a flag used to track when it is in a begin/end pair, but it should be storing the flag per context...

Parsing %gl:enum at runtime is slow, so should try to avoid that as much as possible.

• add a cffi:expand-to-foreign method (or see if cffi can add one automatically for defcfun)

  Currently CFFI generates an extra unwind-protect and empty generic function call for every %gl:enum parameter, which adds noticeable overhead, even if callers translate the enum to an integer in advance.

  Adding a method for expand-to-foreign avoids this, but usually still requires looking up the symbol at runtime, since the value isn't a constant where it actually gets expanded. If it expands to something like (if (numberp value) value ...), and gets inlined, at least passing numbers directly is about as fast as if the argument were a uint, so callers have a workaround for specific bottlenecks.

• generate compiler macros in defglfun and defglextfun
  It might be nice to autogenerate compiler macros that check for enums, and expand them at compile time if possible.