From web at lamberta.org  Fri Oct  2 04:57:24 2009
From: web at lamberta.org (Billy)
Date: Fri, 2 Oct 2009 00:57:24 -0400
Subject: [cl-opengl-devel] uniformf problem (and patch)
Message-ID: <e23971950910012157q1a2f5f02sa0aca2f067ab57c4@mail.gmail.com>

Hi, I was running into some problems setting a uniform variable with
UNIFORMF - I could give it a number, but for some reason it wasn't
evaluating anything else passed to it, reporting "The value X is not
of type REAL."

Anyway with some discussion on #lisp, stassats came up with a little
patch that seems to work.

Here's my original effort that had problems: http://paste.lisp.org/display/88062

And the patch:
diff -rN -u old-cl-opengl/gl/opengl.lisp new-cl-opengl/gl/opengl.lisp
--- old-cl-opengl/gl/opengl.lisp        2009-10-02 08:37:02.397150466 +0400
+++ new-cl-opengl/gl/opengl.lisp        2009-10-02 08:37:02.454149983 +0400
@@ -633,11 +633,15 @@

 (define-compiler-macro uniformf (&whole form location x &optional y z w)
   (declare (ignore form))
-  (cond
-    (w `(%gl:uniform-4f ,location ,(float x) ,(float y) ,(float z) ,(float w)))
-    (z `(%gl:uniform-3f ,location ,(float x) ,(float y) ,(float z)))
-    (y `(%gl:uniform-2f ,location ,(float x) ,(float y)))
-    (x `(%gl:uniform-1f ,location ,(float x)))))
+  (flet ((float* (x)
+           (if (numberp x)
+               (float x)
+               `(float ,x))))
+    (cond
+      (w `(%gl:uniform-4f ,location ,(float* x) ,(float* y) ,(float*
z) ,(float* w)))
+      (z `(%gl:uniform-3f ,location ,(float* x) ,(float* y) ,(float* z)))
+      (y `(%gl:uniform-2f ,location ,(float* x) ,(float* y)))
+      (x `(%gl:uniform-1f ,location ,(float* x))))))

 (defun uniform-matrix (location dim matrices &optional (transpose t))
   (check-type dim (integer 2 4))



From 00003b at gmail.com  Fri Oct  2 18:36:56 2009
From: 00003b at gmail.com (Bart Botta)
Date: Fri, 2 Oct 2009 13:36:56 -0500
Subject: [cl-opengl-devel] uniformf problem (and patch)
In-Reply-To: <e23971950910012157q1a2f5f02sa0aca2f067ab57c4@mail.gmail.com>
References: <e23971950910012157q1a2f5f02sa0aca2f067ab57c4@mail.gmail.com>
Message-ID: <77cb99c00910021136g63e792aalada06e894015e732@mail.gmail.com>

On Thu, Oct 1, 2009 at 11:57 PM, Billy <web at lamberta.org> wrote:
> Hi, I was running into some problems setting a uniform variable with
> UNIFORMF - I could give it a number, but for some reason it wasn't
> evaluating anything else passed to it, reporting "The value X is not
> of type REAL."
>
> Anyway with some discussion on #lisp, stassats came up with a little
> patch that seems to work.

Thanks, slightly modified version checked into my tree at
http://github.com/3b/cl-opengl/

--
3b



From 00003b at gmail.com  Fri Oct  2 18:32:06 2009
From: 00003b at gmail.com (Bart Botta)
Date: Fri, 2 Oct 2009 13:32:06 -0500
Subject: [cl-opengl-devel] Incorrect re-initialization of cl-glut on
	image loading
In-Reply-To: <200909130359.25919.Kalyanov.Dmitry@gmail.com>
References: <200909130359.25919.Kalyanov.Dmitry@gmail.com>
Message-ID: <77cb99c00910021132i148932amefe1ee33cea613fe@mail.gmail.com>

On Sat, Sep 12, 2009 at 6:59 PM, Kalyanov Dmitry
<kalyanov.dmitry at gmail.com> wrote:
> If I load cl-opengl, save the Lisp image (e.g., with sb-ext:save-lisp-and-die
> on SBCL) and then load the image and call (cl-glut:init), then cl-glut::
> %glutInit doesn't get called because the variable cl-glut::*glut-initialized-
> p* is set to T (it retains its value when the image is saved). For me, this
> manifests in the following error:
>>freeglut ?ERROR: ?Function <glutSolidTeapot> called without first calling
> 'glutInit'.
>
> If I set cl-glut::*glut-initialized-p* to NIL before saving the image, then
> cl-glut works after restarting the saved image.

This is already fixed for non-mac platforms in my tree
(http://github.com/3b/cl-opengl) by limiting the *glut-initialized-p*
stuff to threaded mac builds. (patch is at
http://common-lisp.net/~loliveira/patches/cl-glut-init-state.diff if
anyone wants to try it with the main repo)

> (defun clear-initialized-p () (setf *glut-initialized-p* nil))
> #+sbcl (pushnew 'clear-initialized-p sb-ext:*save-hooks*)
>

I suspect this is still a problem on threaded mac lisps though, can
anyone verify it there and test the above fix (and/or a ccl version,
it looks like the function should go on ccl:*save-exit-functions*)?

--
3b



From malcolm.reynolds at gmail.com  Mon Oct  5 18:43:52 2009
From: malcolm.reynolds at gmail.com (Malcolm Reynolds)
Date: Mon, 5 Oct 2009 19:43:52 +0100
Subject: [cl-opengl-devel] Some issues porting an example from
	nehe.gamedev.net
Message-ID: <dcb2fcee0910051143o4b52d6ecl7102951ce0b951c2@mail.gmail.com>

Hello,

I'll start by saying I'm fairly new to Common Lisp and almost entirely
new to doing any practical graphics programming, and I could well have
missed something hugely obvious here.. but I hope not.

I'm going to need to write some graphics code in the phd program I've
just started. Someone pointed me at nehe.gamedev.net's opengl
tutorials and after slogging through up to number 5 -
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=05 - reading
through people's objective C, I decided to try and port it to Lisp
using cl-opengl. I looked at a couple of examples (cube.lisp and
gears.lisp) to get the boilerplate about window generation, and from
there it was pretty much just a case of porting the drawRect method
from the Objective C version to the glut:display method for my code.

I have clearly missed something though, as the visibility for my
geometry is all off - for example the base of the triangle is drawn in
front of anything else and most faces of the cube do something a bit
whacky. I know that which order points are drawn in is crucial because
that defines the 'front' of a triangle/quad, but I'm pretty sure I
have copied the points in the same order as my Objective C version
(which works fine, see screenshots)

Working version (objective C): http://img260.imageshack.us/i/picture3g.png/
Non working version: http://img209.imageshack.us/i/picture4k.png/

In case it's not clear, in the non-working version above the corner
you see in the pyramid is actually the back corner. It shouldn't be
visible. When the pyramid rotates so that you should be looking down
on the point at it, you see only the base instead of only the four top
faces. I have similar issues with the cube faces, some of them only
being visible from the 'inside'.

>From what I can tell from M-.'ing through the source, cl-opengl passes
directly through to the corresponding C functions, so I'm pretty
confident the 'which order to specify points' hasn't changed. This
means presumably something in my setup is off, something to do with
the depth buffer maybe? I guess the issue might be in the keyword args
in function calls in #'glut:display-window method but it's hard to
figure out exactly what the arguments to these functions will be
except a guess at translating them into lisp-ish hyphenated lowercase.

Here's the entire source to my lisp program:
http://paste.lisp.org/display/88230

and the relevant file from my Obj-C version (I basically tried to copy
everything from the drawRect and reshape methods):
http://paste.lisp.org/display/88231


If anyone can point me in the right direction that would be most
appreciated.. I'm looking forward to using Lisp for some serious work
once I get these niggles sorted out.

Cheers,

Malcolm



From 00003b at gmail.com  Mon Oct  5 19:36:23 2009
From: 00003b at gmail.com (Bart Botta)
Date: Mon, 5 Oct 2009 14:36:23 -0500
Subject: [cl-opengl-devel] Some issues porting an example from
	nehe.gamedev.net
In-Reply-To: <dcb2fcee0910051143o4b52d6ecl7102951ce0b951c2@mail.gmail.com>
References: <dcb2fcee0910051143o4b52d6ecl7102951ce0b951c2@mail.gmail.com>
Message-ID: <77cb99c00910051236x6869e1f7j2bb114c507826170@mail.gmail.com>

On Mon, Oct 5, 2009 at 1:43 PM, Malcolm Reynolds
<malcolm.reynolds at gmail.com> wrote:
> Working version (objective C): http://img260.imageshack.us/i/picture3g.png/
> Non working version: http://img209.imageshack.us/i/picture4k.png/
>
> In case it's not clear, in the non-working version above the corner
> you see in the pyramid is actually the back corner. It shouldn't be
> visible. When the pyramid rotates so that you should be looking down
> on the point at it, you see only the base instead of only the four top
> faces. I have similar issues with the cube faces, some of them only
> being visible from the 'inside'.
>
> means presumably something in my setup is off, something to do with
> the depth buffer maybe? I guess the issue might be in the keyword args
> in function calls in #'glut:display-window method but it's hard to
> figure out exactly what the arguments to these functions will be
> except a guess at translating them into lisp-ish hyphenated lowercase.
>

Right, you probably need to enable a depth buffer, and you probably
also want double buffering on modern platforms, both are controlled by
the :mode parameter to glut:window instance creation, easiest way to
fix that is changing the ":mode '(:single :rgb)" in the (defclass
test-window ...) form to ":mode '(:double :rgb :depth)".

If you switch to double buffering (using :double instead of :single
there), you will also need to do (glut:swap-buffers) after drawing
each frame, probably in place of the (gl:flush) in the glut:display
method.

You may also want to get rid of the (glut:post-redisplay) in the
keyboard method, since that kills my lisp when i try to exit the
window (yay for C libraries that think exit() is a good response to
unexpected situations)

Seems to work with those changes though.

--
3b



From malcolm.reynolds at gmail.com  Mon Oct  5 21:10:36 2009
From: malcolm.reynolds at gmail.com (Malcolm Reynolds)
Date: Mon, 5 Oct 2009 22:10:36 +0100
Subject: [cl-opengl-devel] Some issues porting an example from
	nehe.gamedev.net
In-Reply-To: <77cb99c00910051236x6869e1f7j2bb114c507826170@mail.gmail.com>
References: <dcb2fcee0910051143o4b52d6ecl7102951ce0b951c2@mail.gmail.com> 
	<77cb99c00910051236x6869e1f7j2bb114c507826170@mail.gmail.com>
Message-ID: <dcb2fcee0910051410o12b681d0y9e7a253d04a262f1@mail.gmail.com>

> Right, you probably need to enable a depth buffer, and you probably
> also want double buffering on modern platforms, both are controlled by
> the :mode parameter to glut:window instance creation, easiest way to
> fix that is changing the ":mode '(:single :rgb)" in the (defclass
> test-window ...) form to ":mode '(:double :rgb :depth)".
>
> If you switch to double buffering (using :double instead of :single
> there), you will also need to do (glut:swap-buffers) after drawing
> each frame, probably in place of the (gl:flush) in the glut:display
> method.

Lovely. This is now working properly, thankyou!

> You may also want to get rid of the (glut:post-redisplay) in the
> keyboard method, since that kills my lisp when i try to exit the
> window (yay for C libraries that think exit() is a good response to
> unexpected situations)

Okay. Is putting #'glut:post-redisplay into my method on #'glut-idle
the preferred way (or at least, not a discouraged way) of keeping the
model updating?

One final difference between my two versions is that resizing the
window on the lisp version scales the inside accordingly (squares
become squashed) which doesn't happen on the C version. Obviously this
is a bit more of an involved question, but the part that will make
this happen is in the #'glut:reshape method, correct?

Many thanks for your quick reply!

Malcolm



From 00003b at gmail.com  Mon Oct  5 21:19:31 2009
From: 00003b at gmail.com (Bart Botta)
Date: Mon, 5 Oct 2009 16:19:31 -0500
Subject: [cl-opengl-devel] Some issues porting an example from
	nehe.gamedev.net
In-Reply-To: <dcb2fcee0910051410o12b681d0y9e7a253d04a262f1@mail.gmail.com>
References: <dcb2fcee0910051143o4b52d6ecl7102951ce0b951c2@mail.gmail.com>
	<77cb99c00910051236x6869e1f7j2bb114c507826170@mail.gmail.com>
	<dcb2fcee0910051410o12b681d0y9e7a253d04a262f1@mail.gmail.com>
Message-ID: <77cb99c00910051419y78e33cd0g835f8556b983b06b@mail.gmail.com>

On Mon, Oct 5, 2009 at 4:10 PM, Malcolm Reynolds
<malcolm.reynolds at gmail.com> wrote:
>> You may also want to get rid of the (glut:post-redisplay) in the
>> keyboard method, since that kills my lisp when i try to exit the
>> window
>
> Okay. Is putting #'glut:post-redisplay into my method on #'glut-idle
> the preferred way (or at least, not a discouraged way) of keeping the
> model updating?

Yeah, it looks like that is the correct way to do that.

> One final difference between my two versions is that resizing the
> window on the lisp version scales the inside accordingly (squares
> become squashed) which doesn't happen on the C version. Obviously this
> is a bit more of an involved question, but the part that will make
> this happen is in the #'glut:reshape method, correct?

Right, you could either switch it to use glu:perspective and translate
the objc code directly, or you could use for example +/- (/ height
width) in place of +/- 1 for the bottom/top args to gl:frustum.

--
3b



From luke at balooga.com  Tue Oct  6 00:27:27 2009
From: luke at balooga.com (Luke J Crook)
Date: Tue, 6 Oct 2009 00:27:27 +0000 (UTC)
Subject: [cl-opengl-devel] sdl:set-gl-attribute
Message-ID: <loom.20091006T022220-6@post.gmane.org>


Pardon the question concerning lispbuilder-sdl in this list, but I have a 
feeling more developers here use lispbuilder-sdl and cl-openl in combination 
and I may have a better chance of having this question answered.

The set-gl-attribute command in lispbuilder-sdl breaks when using SBCL in 
Windows 7 or OS X. This command is most often used to set doublebuffer mode; as 
shown below;

(sdl:set-gl-attribute :SDL-GL-DOUBLEBUFFER 1)

Is there a way to set the OpenGL attributes using cl-opengl, and if there is, 
does this work on Windows 7 and OS X? 

I'm trying to determine if this is a lispbuilder-sdl problem, a SDL problem, or 
a CFFI problem

In SBCL:

* (sdl:with-init () (sdl:set-gl-attribute :sdl-gl-doublebuffer 1))

debugger invoked on a SIMPLE-ERROR: EXCEPTION_ACCESS_VIOLATION

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

("bogus stack frame")

And in OS X;

CORRUPTION WARNING in SBCL pid 69894(tid 2693764352):
Memory fault at 17c (pc=0x8654d, sp=0x11ffa80)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
 
debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD  
"initial thread" RUNNING {119BEB99}>:
   Unhandled memory fault at #x17C.

Thanks,
- Luke




From luke at balooga.com  Fri Oct  9 00:30:08 2009
From: luke at balooga.com (Luke J Crook)
Date: Fri, 9 Oct 2009 00:30:08 +0000 (UTC)
Subject: [cl-opengl-devel] sdl:set-gl-attribute
References: <loom.20091006T022220-6@post.gmane.org>
Message-ID: <loom.20091009T022810-988@post.gmane.org>

Luke J Crook <luke <at> balooga.com> writes:

> The set-gl-attribute command in lispbuilder-sdl breaks when using SBCL in 
> Windows 7 or OS X. This command is most often used to set doublebuffer mode;
> I'm trying to determine if this is a lispbuilder-sdl problem, a SDL problem,
> or a CFFI problem

User error, sorry. The sdl video subsystem must be initialized prior to setting 
an OpenGL attribute or very bad things happen.

- Luke