cl-opengl-devel February 2007

cl-opengl-devel@common-lisp.net

4 participants
3 discussions

[cl-opengl-devel] generating function bindings, extension loading
by Bart Botta 11 Mar '07

11 Mar '07

I've been working on generating bindings from the .spec files on opengl.org, and it seems to be to the point where it could be turned into a patch... Before that though, I wanted to get some feedback about changing the naming for the bindings: First suggestion is moving the function bindings to a separate package, and giving them lisp style names, so people like me who want to use them directly have supported access to them. Second is changing the GLenums from cffi:defcenums to defconstants. Advantages I can think of from doing that: *Easier for users to add enums from a new extension without modifying library code (unless cffi allows adding to an enum after it is defined, not sure about that) *Easier to add offsets to them, for example a loop to disable all lights could use (+ index gl:+light0+) instead of having to convert from enum and back, or store a list of the light enums or whatever. *being able to add offsets also solves the problem of some values (light in particular) potentially having more valid values than are enums. (The .spec files name 8 lights, but leaves room for 4096, I'm pretty sure there has been hardware supporting at least 32.) *compatibility with other bindings (glx and cl-sdl both use +foo+ style for enums if I remember correctly) *possibly speed. If cffi can remap values at compile time it probably isn't too bad, but it probably wouldn't be too hard to find code with a lot of enums specified at runtime. (Alternately, is it possible to tell cffi to allow using either the constants or the keywords?) Also, a small patch: someone in #lisp was having problems with OpenMCL objecting to compute-applicable-methods being called with extra arguments in glut/interface.lisp, which was fixed by the following patch to define-glut-event: diff -rN old-pct/glut/interface.lisp new-pct/glut/interface.lisp 130c130 < :func ',event-func :arg-count ,(length args)) --- > :func ',event-func :arg-count ,(length arg-names))

4 4

[cl-opengl-devel] ATI + OpenGL 2.0
by Greg Smolyn 14 Feb '07

14 Feb '07

Hi again, I've been working with a number of OpenGL 2.0 concepts such as shader programs, and I've come across a bit of a snag with ATI's OpenGL 2.0support. The shader programs work fine with the libGL.so as supplied by nvidia (on my home machine), but when using libGL.so from ATI on my work machine, functions such as create-shader fail, as there is no such symbol in the library. Using glXGetProcAddress to get the function pointer for glCreateShader, however, is the required work around for the ATI library. I was tempted to create a cl-glew library binding, however this won't really work that well, as _that_ library also doesn't include all the symbols, and relies on C preprocessor macros heavily to do the right thing. Anyways, I was thinking instead of modifying cl-opengl instead to (perhaps dependant on some switch?) use glXGetProcAddress for those functions that aren't directly callable, memoized of course. Does this sort of thing make sense in this context? It's been a while since I've done a lot of lisp, and I'm also not super familiar with FFIs, so I want to make sure I do this the lispyiest way possible. -greg

3 2

[cl-opengl-devel] shader programming functions
by Greg Smolyn 06 Feb '07

06 Feb '07

Hi, I'm starting to do some shader programming and I see that such functions as glGetShaderiv and glGetShaderInfoLog (and the associated 'program' variants) are missing. Is there a reason for this or should I just go ahead and add them? -greg

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cl-opengl-devel February 2007