From 00003b at gmail.com Fri Sep 11 19:27:48 2009 From: 00003b at gmail.com (Bart Botta) Date: Fri, 11 Sep 2009 14:27:48 -0500 Subject: [cl-opengl-devel] GLenum return values Message-ID: <77cb99c00909111227x348f254aw20a2679cd962b9f3@mail.gmail.com> 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- From seth at tewebs.com Sat Sep 12 19:51:13 2009 From: seth at tewebs.com (Seth Burleigh) Date: Sat, 12 Sep 2009 14:51:13 -0500 Subject: [cl-opengl-devel] freeglut windows Message-ID: <000001ca33e2$62dac390$28904ab0$@com> 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 at 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! -------------- next part -------------- An HTML attachment was scrubbed... URL: From luismbo at gmail.com Sat Sep 12 21:27:17 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Sat, 12 Sep 2009 23:27:17 +0200 Subject: [cl-opengl-devel] freeglut windows In-Reply-To: <000001ca33e2$62dac390$28904ab0$@com> References: <000001ca33e2$62dac390$28904ab0$@com> Message-ID: <391f79580909121427y27905c72gd2eab8251a83ef48@mail.gmail.com> On Sat, Sep 12, 2009 at 9:51 PM, Seth Burleigh wrote: > 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 Does this one work for you? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From luismbo at gmail.com Sat Sep 12 21:46:05 2009 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Sat, 12 Sep 2009 23:46:05 +0200 Subject: [cl-opengl-devel] GLenum return values In-Reply-To: <77cb99c00909111227x348f254aw20a2679cd962b9f3@mail.gmail.com> References: <77cb99c00909111227x348f254aw20a2679cd962b9f3@mail.gmail.com> Message-ID: <391f79580909121446x4387e981wbb4245fcec543d56@mail.gmail.com> On Fri, Sep 11, 2009 at 9:27 PM, Bart Botta <00003b at gmail.com> wrote: > 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)? What about splitting gl:enum back into multiple ones like it used to be? Perhaps keeping the big enum, since it makes sense for some of the functions, I suppose. Could we generate this automatically from the spec? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From 00003b at gmail.com Sat Sep 12 21:56:11 2009 From: 00003b at gmail.com (Bart Botta) Date: Sat, 12 Sep 2009 16:56:11 -0500 Subject: [cl-opengl-devel] GLenum return values In-Reply-To: <391f79580909121446x4387e981wbb4245fcec543d56@mail.gmail.com> References: <77cb99c00909111227x348f254aw20a2679cd962b9f3@mail.gmail.com> <391f79580909121446x4387e981wbb4245fcec543d56@mail.gmail.com> Message-ID: <77cb99c00909121456g25bf20c2va49b03dba2d8da0c@mail.gmail.com> On Sat, Sep 12, 2009 at 4:46 PM, Lu?s Oliveira wrote: > What about splitting gl:enum back into multiple ones like it used to > be? Perhaps keeping the big enum, since it makes sense for some of the > functions, I suppose. Could we generate this automatically from the > spec? Doesn't help, since there are cases where a particular value has multiple names, even when returned by the same function. For example when an extension adds a value, with -foo on the name, then it gets added to the core without the -foo, but the same value. So code using the extension should check for the -foo name, while code using the newer GL version should check for the name without -foo, even though both are actually looking for the same numerical value. (and it would probably be hard to generate automatically from what I remember of trying to do so last time) -b- From kalyanov.dmitry at gmail.com Sat Sep 12 23:59:20 2009 From: kalyanov.dmitry at gmail.com (Kalyanov Dmitry) Date: Sun, 13 Sep 2009 03:59:20 +0400 Subject: [cl-opengl-devel] Incorrect re-initialization of cl-glut on image loading Message-ID: <200909130359.25919.Kalyanov.Dmitry@gmail.com> 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 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*) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From 00003b at gmail.com Fri Sep 18 15:56:07 2009 From: 00003b at gmail.com (Bart Botta) Date: Fri, 18 Sep 2009 10:56:07 -0500 Subject: [cl-opengl-devel] gl 3.2 Message-ID: <77cb99c00909180856w54ee14b8pe7df193b69882e33@mail.gmail.com> 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-