cl-opengl-devel June 2009

cl-opengl-devel@common-lisp.net

8 participants
13 discussions

[cl-opengl-devel] Find out the current matrix-mode?
by Jakob Reschke 02 Jul '09

02 Jul '09

Hello everybody, I dug a little into CFFI now to solve my selection problem and I got it to work with %gl:selection-buffer. (thread "Is this project alive?") However now I am facing another problem: how do I find out the current matrix mode (I want to save it for later return)? gl:get-integer and cl-opengl-bindings::get-integer-v don't seem to return usable values: CL-USER> (mapcar (lambda (mode) (matrix-mode mode) (list mode (get-integer :matrix-mode))) '(:modelview :texture :projection)) ((:MODELVIEW 0) (:TEXTURE 0) (:PROJECTION 0)) CL-USER> (mapcar (lambda (mode) (matrix-mode mode) (list mode (get-integer :matrix-mode))) '(:modelview :texture :projection)) ((:MODELVIEW 0) (:TEXTURE 0) (:PROJECTION 0)) CL-USER> (with-foreign-object (mm :int) (mapcar (lambda (mode) (matrix-mode mode) (load-identity) (cl-opengl-bindings::get-integer-v #xBA0 mm) ; #xBA0 is :matrix-mode according to constants.lisp (list mode (mem-ref mm :int))) '(:modelview :texture :projection))) ((:MODELVIEW 690846) (:TEXTURE 690846) (:PROJECTION 690846)) CL-USER> (with-foreign-object (mm :int) (mapcar (lambda (mode) (matrix-mode mode) (load-identity) (cl-opengl-bindings::get-integer-v #xBA0 mm) (list mode (mem-ref mm :int))) '(:modelview :texture :projection))) ((:MODELVIEW 281840) (:TEXTURE 281840) (:PROJECTION 281840)) CL-USER> (with-foreign-object (mm :int) (mapcar (lambda (mode) (matrix-mode mode) (load-identity) (cl-opengl-bindings::get-integer-v #xBA0 mm) (list mode (mem-aref mm :int))) ; now with mem-aref instead of mem-ref '(:modelview :texture :projection))) ((:MODELVIEW 675676) (:TEXTURE 675676) (:PROJECTION 675676)) CL-USER> (with-foreign-object (mm :int) (mapcar (lambda (mode) (matrix-mode mode) (load-identity) (cl-opengl-bindings::get-integer-v #xBA0 mm) (list mode (mem-aref mm :int))) '(:modelview :texture :projection))) ((:MODELVIEW 671420) (:TEXTURE 671420) (:PROJECTION 671420)) CL-USER> Obviously there it is not the matrix mode which is returned, what am I doing wrong? Thank you in advance, best regards Jakob -- I would like E-Mails beeing encrypted with OpenPGP. You can find my public key here: http://jayk.resfarm.de/key.txt

2 2

[cl-opengl-devel] Fwd: OSX glut diff
by Jean-Philippe Barette-LaPierre 27 Jun '09

27 Jun '09

On Fri, Jun 26, 2009 at 5:25 PM, xristos <xristos(a)suspicious.org> wrote: > I fixed the main loop issue with destroy-current-window. > If something else does not work as it should, someone should > post about how freeglut works for these bits. I don't have > linux or x11 here and can't test what freeglut does when > windows are destroyed. > > I can't do anything about CCL as the issue is not that simple. > The code that is commented out in interface.lisp simply interrupts > the initial thread and starts the glut event loop there. > > This does not work (window comes up but event loop is blocked > and i can't do anything) because, in CCL, the initial thread > does certain housekeeping tasks and one can not simply hijack it. > Someone familiar with how CCL does things might want to look into > this, specifically into what CCL does with their cocoa event loop > and duplicate the functionality. I did solve that issue by "cloning" code taken from examples/opengl-ffi.lisp in CCL source distribution. I still didn't had the time to get on my laptop (where the code is), but I'll be able to send it soon. > > > The same strategy of interrupting the initial thread and starting > the glut event loop there works fine in SBCL but i haven't included > the code as for most scenarios the default behavior of SBCL where > the REPL is on the initial thread (this is not true when slime is > involved of course, one has to do the interrupt trick then) > should suffice. > > New patch: > > > > > On 26 Jun 2009, at 15:55, Luís Oliveira wrote: > > On Wed, Jun 24, 2009 at 7:43 PM, xristos<xristos(a)suspicious.org> wrote: >> >>> Here is a cleaner version against current cl-opengl >>> without the extra wm-close methods. >>> >> >> Looking good, though it still doesn't seem to exit the main loop. >> Here's how I reproduce that bug: >> >> * (require :cl-glut-examples) >> ... >> * (cl-glut-examples:rb-cube) ; for instance >> <press Esc to close the window and the function won't return> >> >> Also, this patch doesn't work on at least CCL because of that >> threading issue I mentioned earlier. >> >> -- >> Luís Oliveira >> http://student.dei.uc.pt/~lmoliv/ <http://student.dei.uc.pt/%7Elmoliv/> >> > > > _______________________________________________ > cl-opengl-devel mailing list > cl-opengl-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel > >

1 0

[cl-opengl-devel] OSX glut diff
by xristos 26 Jun '09

26 Jun '09

Here is a cleaner version against current cl-opengl without the extra wm-close methods. It uses the existing close generic function in darwin too. I think this is fine to merge as is provided luis or someone else take a look at interface.lisp and figure out if the things i do in close are sane.

2 2

[cl-opengl-devel] sbcl "sb-ext:save-lisp-and-die" does not run (glutInit ?)
by padovani 24 Jun '09

24 Jun '09

hello, I am making some tests with cl-opengl to make standalone executables with "sb-ext:save-lisp-and-die"... I am usign SBCL 1.0.29 in Mac OSX and have downloaded the "thomas" version available from (http://www.esden.net/content/lisp/cl-mac-native-opengl-thomas-0.1.tar.bz2)... (is this one the recommended version for Mac OSX?) My first attempt was to create an external from the redbook cube.lisp example... so, after evaluating through slime "(require 'asdf)" and all the functions of cube.lisp, I have evalueted this code: (sb-ext:save-lisp-and-die "rb-cube-binario" :executable t :save-runtime-options t :toplevel 'rb-cube) But when I try to run the executable binary "./rb-cube-binario" from terminal I get this error: /Users/ze/sbcl-lib/cl-opengl-thomas-0.1/examples/redbook/rb-cube-binario ; exit; 2009-06-24 01:14:32.606 rb-cube-binario[67793:10b] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: Error (1002) creating CGSWindow It seems to be related to "glutInit(&argc, argv);", in a C syntax, but I have no idead on how to add this in cl-opengl style... When running "(rb-cube)" from slime I get no errors... Thanks for any tips. josé -- http://www.padovani.googlepages.com

3 2

[cl-opengl-devel] cl-opengl not running with CLisp
by Greg Santucci 22 Jun '09

22 Jun '09

I'm using the latest cl-opengl, cffi, babel, alexandria and trivial-features, and I get the following errors when I try to run glut examples: [3]> (cl-glut-examples:gears) *** - FFI::WRITE-MEMORY-AS: 5.0s0 cannot be converted to the foreign type SINGLE-FLOAT [3]> (cl-glut-examples:rb-robot) *** - FFI::FOREIGN-CALL-OUT: 0.0s0 cannot be converted to the foreign type SINGLE-FLOAT I've tried several versions of CLisp, it happens on all of them.

2 1

[cl-opengl-devel] Native glut support for mac os x: Draft
by Jean-Philippe Barette-LaPierre 04 Jun '09

04 Jun '09

Here's a first working draft for GLUT.Framework support. I'm not familiar with either lisp or opengl, so if you want me to improve the patch in any way, just tell me what you want and I'll modify it. Currently, the first obvious problem is that there's no way to choose between the freeglut library or the native one (GLUT.Framework). So, how do you want to manage the future patches I'll send? Do you want to store a branch somewhere? BTW, I want to thanks "esden": http://www.esden.net/blog/ >From which I took most of the changes: http://www.esden.net/blog/2007/12/31/cl-opengl-thomas-mac-os-x-bindings-wit…

2 1

[cl-opengl-devel] gl:clear and depth-buffer
by Sumant Oemrawsingh 03 Jun '09

03 Jun '09

Hi, After successfully installing cl-opengl, I ran into the following problem when trying to run the examples. I found that the demo's ran without explicit errors, but the output didn't look right. Basically, gl:clear wasn't doing its job. After some messing around and help from people on #lisp, I found that after (gl:clear :color-buffer :depth-buffer), a (gl:get-error) returned INVALID-VALUE. When removing the :depth-buffer bit, it returned ZERO. When keeping the :depth-buffer and removing the :color-buffer, it returned INVALID-VALUE again. The constants in constants.lisp match those in GL.h, so that shouldn't be the problem. I'm using SBCL 1.0.28, nvidia binary drivers as well as intel (crappy) drivers. The libGL.so is symlinked to the card that I'm using, and I've verified that when loading cl-opengl, the correct library is used for the card that I'm running. So this is more of a "is this a bug?" or "help, it doesn't work!" type mail, and am not sure if I should have sent it to devel. However, I didn't know what else to do. Regards, Sumant

2 4

[cl-opengl-devel] GLUT on Mac OS X
by Jean-Philippe Barette-LaPierre 02 Jun '09

02 Jun '09

I know this question seems to be asked quite frequently, but I was wondering what is the status of the bindings of GLUT.Framework on Mac OS X? I know that some time ago, there was a branch named thomas that I heard succeeded to use GLUT.Framework instead of freeglut. That branch was supposed to be merged in the main branch. I'm asking, because I tried to use GLUT.Framework, but it seems that I there's many obstacles. If I remember correctly, I'm not using an old version of cl-opengl. So, I was wondering if there was a person working on this. If there is such a person (or not), I would like to help getting this working.

2 1

[cl-opengl-devel] cl-opengl and *READ-DEFAULT-FLOAT-FORMAT*
by Sumant Oemrawsingh 02 Jun '09

02 Jun '09

Hi, I recently installed cl-opengl, but had problems during compilation, regarding an asserted type (single-float) not matching a derived type (double-float). After some time of looking into the problem, I found that I was compiling in a lisp (sbcl) where I redefined *READ-DEFAULT-FLOAT-FORMAT* to DOUBLE-FLOAT) for something or other. Setting this back (or restarting) allowed compilation. I would expect that a library is independent on this. I.e. constant floats should be consistently written as either 1.0d0 or 1.0f0, no? Anyway, just thought to let you know that this _might_ cause problems for others. Or maybe others aren't so stupid to globally change *R-D-F-F*... -Sumant

2 1

Re: [cl-opengl-devel] Clozure and cl-opengl
by Greg Santucci 02 Jun '09

02 Jun '09

--- On Tue, 2/6/09, Luís Oliveira <luismbo(a)gmail.com> wrote: > > Exception occurred while executing foreign code > > Are you using FreeGLUT? If not, you should. > > -- > Luís Oliveira > http://student.dei.uc.pt/~lmoliv/ > Yes, I'm using FreeGLUT. Its the same freeglut.dll I used with CLisp 2.42 that worked without any problems. It comes from here: http://www.turtle.dds.nl/gl4newlisp/freeglut.dll I also rebuilt it with MingW. It works with CLisp. I don't know if I am using a version of cffi that Clozure doesn't like. In the kernel debugger, if I choose "Exit from this debugger, asserting that any exception was handled", it runs for one frame, refreshes the display, then throws another exception. Thank you for your time. Regards, Greg Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cl-opengl-devel June 2009