On Thu, Jun 20, 2013 at 2:09 AM, James Ashley james.ashley@gmail.com wrote:
The original version seems to work fine on SBCL. cl-opengl doesn't claim to run on CCL. I haven't had a chance to try it on different platforms to even begin getting a clue about whether it's isolated that way (though 64-bit linux can't be a common target platform).
cl-opengl should work pretty much wherever there's CFFI (and OpenGL of course).
I'm inclined to suspect that the actual problem lies in CCL, but it seems like it could also just relate to ambiguity in interpreting the spec. So maybe it really is more just a matter of lee-way in cl-opengl's defglfun.
I agree that the problem is likely to be with CCL. First off, try running the CFFI test suite just to weed out any obvious issues specific to CCL on linux/x86-64.
Afterwards we want to replicate what's going on in DEFGLFUN without CFFI. I got to this by calling M-x slime-macroexpand-1-inplace on the (defglfun ("glOrtho" ...) ...) form a couple of times:
(in-package :%gl)
(declaim (inline ortho))
(defun ccl-ortho (left right bottom top znear zfar) (multiple-value-prog1 (let ((g2863 (cl:float left 1.0d0))) (let ((g2864 (cl:float right 1.0d0))) (let ((g2865 (cl:float bottom 1.0d0))) (let ((g2866 (cl:float top 1.0d0))) (let ((g2867 (cl:float znear 1.0d0))) (let ((g2868 (cl:float zfar 1.0d0))) (ccl:external-call "glOrtho" :double-float g2863 :double-float g2864 :double-float g2865 :double-float g2866 :double-float g2867 :double-float g2868 :void))))))) (check-error 'ortho)))
If you replace your original call to gl:ortho with %gl::ccl-ortho, does it still trigger the bug your originally reported? (Make sure you compile everything properly, since I suspect some inlining bug might be involved.)
Cheers,
-- Luís Oliveira http://kerno.org/~luis/