- cl-opengl-devel - mailman3.common-lisp.net

[cl-opengl-devel] lispbuilder-sdl
by Luke Crook 30 Jan '07

30 Jan '07

FYI group. Here is CL-OPENGL running from lispbuilder-sdl http://article.gmane.org/gmane.lisp.cl-lispbuilder.general/648 - Luke

1 0

[cl-opengl-devel] Vertex Arrays
by Charlie McMackin 26 Dec '06

26 Dec '06

Hello, To begin, as it's my first post, I'd like to thank all the developers who started and maintain this project. As a hobbiest beginner, this package allows me to play with the two things that I'm interested in most these days, Lisp and OpenGL. With that said, I was working my way through OpenGL Distilled by Paul Martz, I noticed that section 2.8 on Vertex Arrays of the OpenGL spec was missing. I wasn't quite sure if this was on purpose or not, in favor of a more "Lispy" way but since I couldn't find any equivalent functionality I decided it was a big TODO. So I've after researching and playing with the system, I believe I've made a mostly function patch to add Vertex Arrays to cl-opengl. Of course this has caveats. The biggest caveat is I am still new to OpenGL and Lisp however my patch does produce nearly accurate results of rb-varray in the cl-glut-examples and I have hope that many of the other Vertex Array functions that aren't tested in the rb-varray example work as well. The "nearly accurate" results is why I've decided to mail in my patch. For the there is something odd about how OpenGL is getting one vertex and I can't for the life of me pinpoint it (hopefully due to my green-thumbedness). I /think/ it's either with CFFI itself or the 'with-opengl-array' / 'with-opengl-sequence' macros or maybe even my ATI mobitlity chip :( I'd be interested to hear if rb-varray works for anyone else. Sorry for the long explanation. Here's a short change summary followed by the patch attachment generated by 'darcs whatsnew' gl/package.lisp, funcs.lisp, opengl.lisp added the code for Vertex Arrays through CFFI and the export symbols necessary gl/util.lisp probably my more "dangerous" code as I modified slightly with-opengl-sequence to get rid of the eval quick hack and modified with-opengl-array to look like with-opengl-sequence with out the extra gynsym for array. I hope I did it right and didn't shoot myself in the foot... examples/rb-varray.lisp adjusted until if gave me output using rb-cube.lisp as a reference Thanks again and I hope this code is useful. Charlie Mac

2 2

[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

[cl-opengl-devel] Depth issues with the darcs version
by Charlie Burrows 20 Oct '06

20 Oct '06

Hi, As I said I've just upgraded to the latest version of cl-opengl and now I'm having some issues. I'm upgrading from Frank Buss' April snapshot. The latest version seems to have some depth issues (or maybe it's just me!); when I draw a smooth shaded rotating cube (nehe6) the sides overlap the center and sometimes the backface is at the front. There is another demo that is a triangle and a square that rotate, I modified them so that they were overlapping but the one that's drawn last is always completely in front of the others. It's like I'm using the painters' algorithm. These demos looked fine before and I can't see anything that I'm doing that the gears demo isn't doing or visa-versa (except for display lists). Any suggestions? Cheers, Charlie

2 5

[cl-opengl-devel] New Unpaid Item Message from tany70 : #294653688662
by eBay＠common-lisp.net 14 Oct '06

14 Oct '06

1 0

[cl-opengl-devel] Re: Nehe Tutorials 1-6 are done.
by Charlie Burrows 29 Sep '06

29 Sep '06

On 9/28/06, Luís Oliveira <luismbo(a)gmail.com> wrote: > On 9/28/06, Charlie Burrows <charlie.burrows(a)gmail.com> wrote: > > p.s. sorry for double sending Luís; I just can trust gmail to dwim. > > Heh. No problem. Btw, I have my hands very full atm so it'll take a > while before I can look at your examples properly and integrate them. > So, my apologies in advance. > > -- > Luís Oliveira > http://student.dei.uc.pt/~lmoliv/ > Actually that's a good thing since they don't work against the latest cl-opengl version anyway. Originaly I had some trouble getting cl-opengl to compile so I got an older tar referenced in the archives of this list and I've been using that one. I just remembered and thought I'd check the latest again and it works (with a couple of changes) but my stuff doesn't. There's only a couple of issues with cl-opengl (under clisp 2.38 win32): #\Esc is not a valid key under clisp apparently and you can't compare characters to keys directly so (eql key #\Esc) must become (eql key (char-code #\Escape)). That's how it worked for me anyway. So you can hold off on looking at the nehes until I've had a chance to update them. Cheers, Charlie.

1 0

[cl-opengl-devel] Re: Nehe Tutorials 1-6 are done.
by Charlie Burrows 29 Sep '06

29 Sep '06

On 9/28/06, Luís Oliveira <luismbo(a)gmail.com> wrote: > Send us a link. I'll put them in the cl-opengl tree. > Here they are, the website isn't yet but the link should still work. I still have some work to do, like putting back the comments for each line etc. Will I be able to use darcs to submit patches once it's up there? Also I sidestepped the whole image loading issue by putting all the image data (64x64x24 bits) into a lisp file. I'm open to suggestions. http://charlie.burrows.googlepages.com/nehe.tar.gz Enjoy! Charlie p.s. sorry for double sending Luís; I just can trust gmail to dwim.

2 2