cl-opengl-devel

cl-opengl-devel@common-lisp.net

214 discussions

[cl-opengl-devel] Problems running cl-openl on Snow Leopard
by Malcolm Reynolds 15 Feb '10

15 Feb '10

Hello all, I'm having issues getting cl-opengl working on Snow Leopard 10.6.2. I definitely had some working Lisp OpenGL stuff on my previous laptop (plain old Leopard) but the switch to SL seems to have caused a show stopper (maybe something to do with 64 bits?). I'm using SBCL 1.0.35.2, compiled myself from git. I haven't enabled threads because they are a bit shaky on Mac, and I've specifically compiled a 32 bit version because I have some 32 bit libraries I'd like to link to. I'm using the latest version of cl-opengl from darcs. I open up a new lisp, load :cl-glut-examples using ASDF, and then move into the package and try to run a demo (for the sake of argument #'RB-HELLO although this appears to happen with everything) and the lisp dies with this fairly cryptic error message: * (in-package :cl-glut-examples) #<PACKAGE "CL-GLUT-EXAMPLES"> * (rb-hello) 2010-02-15 16:33:44.197 sbcl[766:903] GLUT Warning: invalid glutGet parameter: 124 Mon Feb 15 16:33:44 mreynolds-mbp.local sbcl[766] <Error>: kCGErrorInvalidConnection: CGSGetCurrentCursorLocation: Invalid connection Mon Feb 15 16:33:44 mreynolds-mbp.local sbcl[766] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. Mon Feb 15 16:33:44 mreynolds-mbp.local sbcl[766] <Error>: kCGErrorInvalidConnection: CGSGetCurrentCursorLocation: Invalid connection Mon Feb 15 16:33:44 mreynolds-mbp.local sbcl[766] <Error>: kCGErrorInvalidConnection: CGSNewWindowWithOpaqueShape: Invalid connection 2010-02-15 16:33:44.233 sbcl[766:903] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: Error (1002) creating CGSWindow The only clue I have is that when loading the fasl files (I've deleted and recompiled all these a bunch of times so I'm pretty sure there's nothing stale in here) I get the warning you can see at the bottom of this snippet - the style warning may be nothing but the GLUT warning looks ominous. ; loading system definition from ; /Users/malc/opt/lisp/asdf-reg/cl-glut-examples.asd into #<PACKAGE "ASDF0"> ; registering #<SYSTEM CL-GLUT-EXAMPLES {12760E39}> as CL-GLUT-EXAMPLES ; loading system definition from /Users/malc/opt/lisp/asdf-reg/cl-glut.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM CL-GLUT {11A9AA61}> as CL-GLUT ; loading system definition from /Users/malc/opt/lisp/asdf-reg/cl-opengl.asd ; into #<PACKAGE "ASDF0"> ; registering #<SYSTEM CL-OPENGL {11BCE579}> as CL-OPENGL ; loading system definition from /Users/malc/opt/lisp/asdf-reg/cl-glu.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM CL-GLU {11D65D59}> as CL-GLU STYLE-WARNING: Keyword :CALLING-CONVENTION is obsolete, please use :CONVENTION 2010-02-15 16:33:13.944 sbcl[766:903] GLUT Warning: invalid glutGet parameter: 124 NIL Does anyone have any ideas on how to track this down? I'm digging through the code right now but I'm by no means skilled at opengl or lisp so it's hard going.. Many thanks, Malcolm

2 3

[cl-opengl-devel] CL-Glut fix for ECL
by Michael Raskin 29 Jan '10

29 Jan '10

Hello. I am trying to make ASDF-Installing Cells-GTK simpler on different platforms. The last thing that is wrong for ECL/Linux is the following: in :cl-glut package some symbol (GET) is declared shadowing in the package definition, and some other symbols (SPECIAL, CLOSE) are later passed to "shadow" invocation. It looks non-uniform and for some obscure reason works unreliably in ECL (Although shadowing symbols from :Common-Lisp package should probably be done before it is used in the package anyway). So, is there any problem with replacing in cl-opengl/glut/package.lisp the line (:shadow #:get) with line (:shadow #:get #:special #:close) ? After that in the file cl-opengl/glut/interface.lisp lines (eval-when (:compile-toplevel :load-toplevel :execute) ;; FIXME: find good alternative names instead of shadowing these CL symbols (shadow '("SPECIAL" "CLOSE") :cl-glut) ) can be safely removed (or they can be left as-is, no difference). Thanks Michael Raskin

1 0

[cl-opengl-devel] window reopening bug and fix
by Martin Kielhorn 20 Dec '09

20 Dec '09

Hi, the test program in the bottom doesn't work as expected in slime on my linux systems: It should do the following: when calling (run) with C-M-x it opens a window. When pressing ESC in this window it will close. When calling (run) again slime is destroyed. One work around I found is to call (reinit) before calling (run) the second time. The problem is that *glut-initialized-p* isn't reset to nil after leaving the main loop in glut/main.lisp: ;; this is the fix: (defun main-loop () (without-fp-traps (%glutMainLoop)) (setf *glut-initialized-p* nil) ; add this line to fix the bug init)) ;; this is the test program: #.(progn (require :asdf) (require :cl-opengl) (require :cl-glut) (require :cffi)) (defpackage #:mk (:use #:cl #:gl #:cffi)) (in-package #:mk) (defcallback draw :void () (clear :color-buffer) (with-primitives :lines (vertex 1 0) (vertex 0 1)) (glut:swap-buffers)) (defcallback key :void ((key :uchar) (x :int) (y :int)) (declare (ignore x y)) (case (code-char key) (#\Esc (glut:leave-main-loop)))) (defun run () (glut:init) (glut:init-display-mode :double :rgb) (glut:create-window "test") (glut:display-func (callback draw)) (glut:keyboard-func (callback key)) (glut:main-loop)) (defun reinit () (with-foreign-objects ((argcp :int) (argv :pointer)) (setf (mem-ref argcp :int) 1) (with-foreign-string (str "test") (setf (mem-ref argv :pointer) str) (glut::%glutInit argcp argv)))) -- Martin Kielhorn Randall Division of Cell & Molecular Biophysics King's College London, New Hunt's House Guy's Campus, London SE1 1UL, U.K. tel: +44 (0) 207 848 6519, fax: +44 (0) 207 848 6435

2 1

[cl-opengl-devel] sdl:set-gl-attribute
by Luke J Crook 09 Oct '09

09 Oct '09

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

1 1

[cl-opengl-devel] Some issues porting an example from nehe.gamedev.net
by Malcolm Reynolds 05 Oct '09

05 Oct '09

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

2 3

[cl-opengl-devel] uniformf problem (and patch)
by Billy 02 Oct '09

02 Oct '09

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))

2 1

[cl-opengl-devel] Incorrect re-initialization of cl-glut on image loading
by Kalyanov Dmitry 02 Oct '09

02 Oct '09

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. I propose to clear the cl-glut::*glut-initialized-p* when the image is saved. The source code change (for SBCL) might look like this: (defun clear-initialized-p () (setf *glut-initialized-p* nil)) #+sbcl (pushnew 'clear-initialized-p sb-ext:*save-hooks*)

2 1

[cl-opengl-devel] gl 3.2
by Bart Botta 18 Sep '09

18 Sep '09

I've updated my fork to gl 3.2 and latest extensions as of 2009-09-11 (GL_EXT_VERSION 55), and merged it with the current darcs tree : http://github.com/3b/cl-opengl In addition to updating to current GL version, this tree has automatic GL error checking, which can be disabled at by pushing :cl-opengl-no-check-error onto *features* before compiling cl-opengl (calling code must be recompiled too, since the functions are declaimed inline.) Due to duplicated names in %gl:enum, gl:get-error, gl:check-framebuffer-status, and gl:check-framebuffer-status-ext (and a few other functions that i don't think existed in the main tree anyway) return :unsigned-int instead of %gl:enum now, so some existing code might break with this tree. There is currently gl::enum= for comparing %gl:enum values to the numerical values, and to each other by value. Not sure if that is the final API or not yet, so feedback on whether that is enough for actual usage or not would be good. other features/changes: gl:get* - for known queries, determines number and type of value(s) to return automatically. Should know about everything through gl 3.0 or so, but may not be completely current. Needs a better name, so that might change... uses cffi:bitfields for various arguments, so the short names (without the -bit suffix) don't conflict with other enums, probably not visible to most user code that wasn't running into the conflicts, but anything dealing with the values directly might need modified. various bugfixes, export more %gl: functions from gl:, etc. Unlike my previous gl3 fork, this one doesn't try to split out the core/non-deprecated parts of the GL spec, so it should be easier to keep up to date with newer GL versions/extensions. It also doesn't close glut windows on errors, since that broke the glut:*run-main-loop-after-display* feature used by cl-glut-examples:run-examples, not sure what the correct way to handle that is. This tree hasn't been tested much beyond sbcl/linux/x86_64, so more testing would be welcome. -b-

1 0

[cl-opengl-devel] GLenum return values
by Bart Botta 12 Sep '09

12 Sep '09

Currently a number of functions in cl-opengl return %gl:enum, but cffi:defcenum only remembers 1 keyword for a particular enum value, so we can't reliably compare the return values with keywords. (see for example http://paste.lisp.org/display/86945 where one of the examples broke when I updated to the newest gl .spec version, which changed what symbol the enum mapped to). Does anyone have objections (or better alternatives) to changing the return values to integers, and either adding a function to compare them (gl:enum= maybe?) to keywords, or adding a shortcut to look up an enum (probably gl:enum)? so the code from the paste would look like (let ((framebuffer-status (gl:check-framebuffer-status-ext :framebuffer-ext))) (unless (gl:enum= framebuffer-status :framebuffer-complete-ext) (error "Framebuffer not complete: ~A." framebuffer-status))) or (let ((framebuffer-status (gl:check-framebuffer-status-ext :framebuffer-ext))) (unless (= framebuffer-status (gl:enum :framebuffer-complete-ext)) (error "Framebuffer not complete: ~A." framebuffer-status))) Alternately, cffi could be modified as suggested in the comment for cffi::make-foreign-enum to return a list of keywords when there are duplicates, but then we would have do modify the calling code anyway to use MEMBER or something, and that would be slower as well as less intuitive. -b-

2 2

[cl-opengl-devel] freeglut windows
by Seth Burleigh 12 Sep '09

12 Sep '09

I'm trying to install cl-glut. However, I keep getting an error which says undefined alien. Since I'm sure it has something to do with the binary I downloaded, Can anyone point out a windows binary that they have successfully used? I got mine from http://www.mediafire.com/?ij1m9em7xdy. The funny thing is that when I look at the functions exported in it I can find the following entry in the import table _glutSetOption@8 (Ordinal: 86, Entry Point RVA: d0c0h (53,440)) , yet it says it is an undefined alien. I know I have loaded the library correctly, so I don't know what's happening. Thanks!

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cl-opengl-devel