On Thu, Jun 20, 2013 at 2:09 AM, James Ashley <james.ash...@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/
