Hello, sorry if this isnt the right place for these issues since i'm fairly a novice to lisp. I am currently playing around with sbcl 9.17 on Windows and am having problems compiling cl-opengl. It seems that it has trouble finding all the gl functions, specifically anything above gl 1.1. Has this been adressed? Is there an easy way to utilize something like wglGetProc to address this problem?
On 10/23/06, Gilbert Wong djbuzzkill@gmail.com wrote:
Hello, sorry if this isnt the right place for these issues since i'm fairly a novice to lisp. I am currently playing around with sbcl 9.17 on Windows and am having problems compiling cl-opengl. It seems that it has trouble finding all the gl functions, specifically anything above gl 1.1. Has this been adressed?
What kind of problems are you having besides warnings about undefined alien functions?
Is there an easy way to utilize something like wglGetProc to address this problem?
ISTR this was discussed in this mailing list before. I don't remember what the conclusions were but you can probably find something in the archives.
"Luís Oliveira" luismbo@gmail.com writes:
On 10/23/06, Gilbert Wong djbuzzkill@gmail.com wrote:
Hello, sorry if this isnt the right place for these issues since i'm fairly a novice to lisp. I am currently playing around with sbcl 9.17 on Windows and am having problems compiling cl-opengl. It seems that it has trouble finding all the gl functions, specifically anything above gl 1.1. Has this been adressed?
Hi there -
I'm in a similar boat to Gilbert, and was wondering what the current state is with cl-opengl under win32. Does it currently work for anyone on win32?
My opengl32.dll doesn't have, for example, an entry point for glActiveTexture. Searching on the net suggests that the way to get hold of this function under windows is to do something like (in C):
glActiveTexture = (PFNGLCLIENTACTIVETEXTUREARBPROC) wglGetProcAddress("glActiveTextureARB");
Is there an easy way to utilize something like wglGetProc to address this problem?
ISTR this was discussed in this mailing list before. I don't remember what the conclusions were but you can probably find something in the archives.
I've had a look through the archives but couldn't find anything relevant. I found the messages about getting hold of freeglut.dll (which suggests to me that people are successfully running cl-opengl under windows), but didn't see anything else about getting hold of the extensions.
Is there something I need to install, or should I start trying to get these functions through wglGetProcAddress?
Regards,
Damyan.
On 12/17/06, Damyan Pepper damyanp@gmail.com wrote:
I'm in a similar boat to Gilbert, and was wondering what the current state is with cl-opengl under win32. Does it currently work for anyone on win32?
My opengl32.dll doesn't have, for example, an entry point for glActiveTexture. Searching on the net suggests that the way to get hold of this function under windows is to do something like (in C):
glActiveTexture = (PFNGLCLIENTACTIVETEXTUREARBPROC) wglGetProcAddress("glActiveTextureARB");
You could try my patched version of cl-opengl at http://www.3bb.cc/tmp/cl-opengl-3b.tar.bz2 It should work on Win32, and includes OpenGL >=1.2 functions and most of the GL extensions that are more than a month or 2 old. The examples will require GLUT, but the extension code should work with wglGetProcAddress, or SDL's version, or whatever. Just need to add the appropriate defcfun and (setf cl-opengl-bindings::*gl-get-proc-address* #'wglGetProcAddress) at some point before you try to call any GL>=1.2 or extension functions.
I've run some of the examples on win32 SBCL, but not really stressed it much. I assume it won't work on Corman, since it needs foreign-funcall, but should work on other CFFI supported lisps.
-- Bart
"Bart Botta" 00003b@gmail.com writes:
You could try my patched version of cl-opengl at http://www.3bb.cc/tmp/cl-opengl-3b.tar.bz2
I've run some of the examples on win32 SBCL, but not really stressed it much. I assume it won't work on Corman, since it needs foreign-funcall, but should work on other CFFI supported lisps.
Hi - thanks for this, it gets me a lot further. (I'm running SBCL 1.0 on Win32) Are there any plans to merge your patches into the main distribution?
I had to #-win32 gluProject and gluUnProject - I think because of the (:pointer gl:double).
Just in case anyone's interested, here's how the examples run on my machine:
rb-hello: ok rb-double: runs, but crashes when I click in the window (win32 exception of some kind) rb-lines: ok rb-polys: ok rb-cube: ok rb-model: ok rb-clip: ok rb-stroke: ok rb-list: ok rb-stroke: ok rb-smooth: ok rb-movelight: runs, but crashes on clicks (as for rb-double) gears: displays, but immediately crashes
For all the ones that are ok, the keyboard input doesn't seem to work. I guess that this is because glut:keyboard is getting called with the key codes as integers rather than as characters - so it gets 27 rather than #\Esc for example. I'll look into this - I want to make sure I'm running the latest CFFI and see if ascii-to-char works in other circumstances.
Regards,
Damyan.
On 12/18/06, Damyan Pepper damyanp@gmail.com wrote:
Hi - thanks for this, it gets me a lot further. (I'm running SBCL 1.0 on Win32) Are there any plans to merge your patches into the main distribution?
Yeah, I'm hoping to get it added at some point, but have been distracted by other projects recently so haven't finished it up yet.
I had to #-win32 gluProject and gluUnProject - I think because of the (:pointer gl:double).
That sounds like you might be using old cffi, the (:pointer gl:double) bit requires cffi 0.9.2
rb-double: runs, but crashes when I click in the window (win32 exception of some kind) rb-movelight: runs, but crashes on clicks (as for rb-double) gears: displays, but immediately crashes
You might try building SBCL from CVS, there were some bugs with callbacks on win32 fixed since 1.0 that sounded like they might be hit by the glut code.
For all the ones that are ok, the keyboard input doesn't seem to work. I guess that this is because glut:keyboard is getting called with the key codes as integers rather than as characters - so it gets 27 rather than #\Esc for example. I'll look into this - I want to make sure I'm running the latest CFFI and see if ascii-to-char works in other circumstances.
I've seen that also (with Linux SBCL), I assume they worked for whoever wrote them, so not sure if something has changed since then, or if it is due to different versions of glut, or lisp implementation or what...
-- Bart
cl-opengl-devel@common-lisp.net
-
Bart Botta -
Damyan Pepper -
Gilbert Wong -
Luís Oliveira