cl-opengl-devel November 2006

cl-opengl-devel@common-lisp.net

4 participants
5 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] cl-opengl on Windows
by Gilbert Wong 18 Dec '06

18 Dec '06

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? -- gilbert

4 5

[cl-opengl-devel] extension loading + wrapper generation
by Bart Botta 17 Nov '06

17 Nov '06

OK, first draft of the wrapper generation/extension loading code is available at http://www.3bb.cc/tmp/cl-opengl-3b.tar.bz2 Let me know if you have any problems/suggestions... main changes: *generates gl/funcs.lisp from gl.spec *uses gl extension support for extensions and functions from versions >= 1.2 - works on win32 (tested with sbcl 0.9.18) - can save cores (tested on sbcl 0.9.18 amd64 linux and x86 win32, and cmucl 19dpre2 x86 linux) *rearranged low level bits into a separate package - cl-opengl-bindings, nickname %gl - basic types, constants, function wrappers *binding names are lisp style - %gl:vertex-3f instead of %glVertex3f *Makefile downloads current .spec files from opengl.org if needed (with wget), then builds gl/constants.lisp, gl/bindings-package.lisp and gl/funcs.lisp *rename calls to %gl* as applicable in gl/*lisp *glut/init.lisp: need to tell extension loader how to get extension pointers from glut (possibly should be some somewhere other than glut:init though?) *misc patches (see end of message) I noticed some of the cl-opengl code uses things like (:pointer gl:double) instead of :pointer for defcfun parameter types, is this something the generated bindings should do also? (and if so, is (:pointer (:pointer foo)) correct syntax for foo**?) Wrapper generator handles either option, just wasn't sure what benefits it had, and if it was worth dropping cffi 0.9.1 support for. Misc patches mentioned above, not part of the extension/wrapper stuff, but needed for testing on my systems: -nvidia 96.29 amd64 linux drivers are returning FRAMEBUFFER_UNSUPPORTED_EXT from the completeness check in misc/render-to-texture.lisp if the texture doesn't have mipmaps - windows GLU doesn't seem to have gluCheckExtension or gluUnProject4 diff -rN -u old-cl-opengl/examples/misc/render-to-texture.lisp new-cl-opengl/examples/misc/render-to-texture.lisp --- old-cl-opengl/examples/misc/render-to-texture.lisp 2006-11-13 04:30:03.000000000 -0600 +++ new-cl-opengl/examples/misc/render-to-texture.lisp 2006-11-13 04:30:03.000000000 -0600 @@ -28,6 +28,8 @@ (gl:tex-parameter :texture-2d :texture-min-filter :linear-mipmap-linear) (gl:tex-parameter :texture-2d :texture-mag-filter :linear) (gl:tex-image-2d :texture-2d 0 :rgba 512 512 0 :rgba :unsigned-byte (cffi:null-pointer)) + (gl:generate-mipmap-ext :texture-2d) + (gl:bind-texture :texture-2d 0) (gl:framebuffer-texture-2d-ext :framebuffer-ext :color-attachment0-ext :texture-2d diff -rN -u old-cl-opengl/glu/glu.lisp new-cl-opengl/glu/glu.lisp --- old-cl-opengl/glu/glu.lisp 2006-11-13 04:30:03.000000000 -0600 +++ new-cl-opengl/glu/glu.lisp 2006-11-13 04:30:03.000000000 -0600 @@ -55,6 +55,7 @@ (defcfun ("gluGetString" get-string) :string (name-keyword string-name)) +#-win32 (defcfun ("gluCheckExtension" check-extension) (:boolean gl:boolean) (extension-name :string) (extension-string :string)) @@ -151,6 +152,7 @@ (obj-y (:pointer gl:double)) (obj-z (:pointer gl:double))) +#-win32 (defcfun ("gluUnProject4" %gluUnProject4) glu-result (win-x gl:ensure-double) (win-y gl:ensure-double)

3 2

Re: [cl-opengl-devel] generating function bindings, extension loading
by Oliver Markovic 12 Nov '06

12 Nov '06

(gah, I always forget to hit "Reply All") On 12.11.2006, at 14:51, Bart Botta wrote: > I'm not arguing that the behavior of the hand written API should > change*, just the shape of the parameters. gl:clear still handles > combining the arguments, it just uses logior instead of make-bitfield. > > *(well, actually, I might argue that the API should change, but if I > did, the argument would be that cl-opengl is too low level, not that > it should be closer to the C API :) Well, I don't see any significant advantage in doing so. > Or my bindings if I release them, I was just hoping to have that > behavior as a subset of cl-opengl to avoid pointless forks :) It's not pointless fork if it wants to do things differently. This project was originally made to collaborate with Luis Oliveira on writing Lispy OpenGL bindings that suit our personal needs. Nothing more. As I said, writing bindings is not rocket science and one could generate a simple set in an afternoon if desired, so I do not see any harm in having more than one. > I was thinking more of workstation level cards, 3dlabs realizm, etc. > http://www.delphi3d.net/hardware/viewreport.php?report=1503 > > Easy enough to just add more enums to cover the extra if you stay with > cffi enums, so it isn't too much of a problem. Well yeah, it wasn't meant to be dismissive, just that I don't see it as a big problem that would justify switching to defconstants. It's easy to switch those few functions to accept integers instead of enums and have a function like this: (defun enum-value (base value &key (min 0) (max most-positive-fixnum)) (assert (or (keywordp value) (<= min value max))) (if (keywordp value) (foreign-enum-value 'enum value) (+ (foreign-enum-value 'enum base) value))) and change gl:light to use it: (defun light (light pname value) (let ((light-name (enum-value :light0 value :max 4096))) (%glLightfv light-name ...))) There, problem solved. You can now call it like (gl:light :light7 ...) or (gl:light 7 ...) and it should work. We don't even need to define new enums. > Sorry, I meant CLX, not GLX : > http://common-lisp.net/~crhodes/clx/gl.lisp > and CL-SDL is a set of lisp bindings for SDL and OpenGL. > > The 2 libraries you linked both used GL_FOO style > constants/defparameters though, so not sure how much it matters. I didn't even look closely at them to be honest. It's just that I never see any juggling of +constants+ in native Lisp code and think that it's a C-ism that I want to avoid. > Might be, I'll have to see if I can think of any concrete tests and > try it... Sure, it'd be nice to know for certain, but I can't imagine any situation where looking up a few keywords at runtime would be a bottleneck in any shape, way or form unless you construct such a case. You're supposed to minimize the number of OpenGL calls anyway and I expect the cost of doing such a lookup is absolutely dwarfed by the cost of doing the call itself and possibly introducing pipeline bubbles. -- Oliver Markovic

1 0

[cl-opengl-devel] Patch to add support for VBOs, PBOs and FBOs + example
by Oliver Markovic 11 Nov '06

11 Nov '06

Hi, I've pushed a patch that adds support for vertex, pixel and framebuffer objects. The latter is not part of core OpenGL yet, so I've added a new file extensions.lisp to the GL bindings. I've also added a new example to misc/ which uses FBOs to render into a texture and display it on a rotating quad; there's a screenshot and link to the code on the front-page of cl- opengl now. I tried to imitate the new iTunes 3D cover style :) Sorry for the long hiatus, but I haven't been able to do any Lisp (e.g. non-paid) programming lately. Question: now that there aren't separate enums anymore, couldn't gl/funcs.lisp be autogenerated too? The reason for it being written by hand was to be able to have distinct enum types as parameters and if we don't do them anymore, there's no point in having to write it manually. -- Oliver Markovic

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cl-opengl-devel November 2006