From luismbo at gmail.com Wed Feb 1 05:05:57 2006 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 1 Feb 2006 05:05:57 +0000 Subject: [cl-opengl-devel] Exporting GL types. Message-ID: <1BDB8701-7508-4D1E-A41D-4FBF21131102@gmail.com> Hello Oliver, I need to use the GL types from both cl-glu and cl-glut so I suppose it'd be nice to export them from the cl-opengl package. Also, I propose to strip the GL their names (as done everywhere else). I realize that this involves a fair bit of renaming throughout the source code so I volunteer to do that. :-) Ie: gl:float, gl:double, gl:enum, etc... BTW, the defenums are being canonicalized to int when they should be canonicalized to GLenum (well, unsigned long). I'll fix that tomorrow too. Let me know if you have any objections. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From luismbo at gmail.com Wed Feb 1 03:54:26 2006 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 1 Feb 2006 03:54:26 +0000 Subject: [cl-opengl-devel] Re: Darcs tree permitions and first changes In-Reply-To: References: <5BC9CEE1-154B-4F90-B9CF-728A414BF257@gmail.com> Message-ID: On 2006-jan-31, at 21:42, Oliver Markovic wrote: > I'm a little busy until Friday, so I won't be able to do a lot of work > till then unfortunately. Ok I fixed a few trivial bugs that were preventing cl-opengl from compiling and I should have a working example soon. I really like the way you're making the bindings lispy, btw. First question (possibly a silly question, I know very little about OpenGL): Why plural WITH-PRIMITIVES when it takes only on argument? Wouldn't WITH-PRIMITIVE make more sense? Sorry if this is a silly question. :-) If WITH-PRIMITIVE makes more sense, I'll push a patch renaming it, fixing the bugs, etc... -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From entrox at entrox.org Wed Feb 1 10:40:29 2006 From: entrox at entrox.org (Oliver Markovic) Date: Wed, 1 Feb 2006 11:40:29 +0100 Subject: [cl-opengl-devel] Exporting GL types. In-Reply-To: <1BDB8701-7508-4D1E-A41D-4FBF21131102@gmail.com> References: <1BDB8701-7508-4D1E-A41D-4FBF21131102@gmail.com> Message-ID: <1C40F493-E3BD-4AB9-8C61-22ACC3AF0E54@entrox.org> On 01.02.2006, at 06:05, Lu?s Oliveira wrote: > I need to use the GL types from both cl-glu and cl-glut so I > suppose it'd be nice to export them from the cl-opengl package. > Also, I propose to strip the GL their names (as done everywhere > else). I realize that this involves a fair bit of renaming > throughout the source code so I volunteer to do that. :-) > > Ie: gl:float, gl:double, gl:enum, etc... Making those available to the other packages seems like a good idea. They're probably also shared in the C headers anyways. The reason that I called the type GLfloat and not gl:float is because I didn't want to think about any name collisions with already existing types, but if you want to volunteer.. :) -- Oliver Markovic From keriax at gmail.com Thu Feb 2 03:32:05 2006 From: keriax at gmail.com (Alexey Dvoychenkov) Date: Thu, 02 Feb 2006 13:32:05 +1000 Subject: [cl-opengl-devel] darcs patch: Add glutSetOption. Message-ID: Thu Feb 2 13:19:04 VLAT 2006 Alexey Dvoychenkov * Add glutSetOption. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 3884 bytes Desc: A darcs patch for your repository! URL: From keriax at gmail.com Thu Feb 2 03:23:04 2006 From: keriax at gmail.com (Alexey Dvoychenkov) Date: Thu, 02 Feb 2006 13:23:04 +1000 Subject: [cl-opengl-devel] darcs patch: Add glutSetOption. Message-ID: Thu Feb 2 13:19:04 VLAT 2006 Alexey Dvoychenkov * Add glutSetOption. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 3884 bytes Desc: A darcs patch for your repository! URL: From luismbo at gmail.com Tue Feb 7 01:25:04 2006 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 7 Feb 2006 01:25:04 +0000 Subject: [cl-opengl-devel] Minor style questions Message-ID: <75833DA1-EC89-4DE1-BC4F-CD46AB33E6F5@gmail.com> Hello, I have two small questions: - I pushed a patch that implements a trivial WITH-PUSHED-MATRIX macro. Would WITH-MATRIX be a better name though? - Shouldn't the arguments to gl:clear have the "-bit" end stripped out? Since we're hiding the fact that they are bitmasks anyway... -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From entrox at entrox.org Wed Feb 8 11:54:29 2006 From: entrox at entrox.org (Oliver Markovic) Date: Wed, 8 Feb 2006 12:54:29 +0100 Subject: [cl-opengl-devel] Minor style questions In-Reply-To: <75833DA1-EC89-4DE1-BC4F-CD46AB33E6F5@gmail.com> References: <75833DA1-EC89-4DE1-BC4F-CD46AB33E6F5@gmail.com> Message-ID: <84D3205C-4A4E-4CFF-AC95-A926AC237000@entrox.org> On 07.02.2006, at 02:25, Lu?s Oliveira wrote: > - I pushed a patch that implements a trivial WITH-PUSHED-MATRIX > macro. Would WITH-MATRIX be a better name though? No, I think WITH-PUSHED-MATRIX is fine as is. > - Shouldn't the arguments to gl:clear have the "-bit" end stripped > out? Since we're hiding the fact that they are bitmasks anyway... I have also thought about that one, but decided against it because I didn't want to deviate too much from the specification. Introducing semi-arbitrary naming changes looked like too much of a headache to me: if we strip off the -bit, should we also strip off the -hint in HINT-TARGET? Should the redundant light-model- or pixel-map- prefix go? If not, why snip off -bit? If yes, it needs to be written down somewhere. It's hard to stay consistent and obvious to the user. Personally, I wouldn't like to have to look into the documentation to see how some names get translated from the spec/C-side to Lisp. YMMV. -- Oliver Markovic From luismbo at gmail.com Wed Feb 8 16:51:27 2006 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 8 Feb 2006 16:51:27 +0000 Subject: [cl-opengl-devel] Minor style questions In-Reply-To: <84D3205C-4A4E-4CFF-AC95-A926AC237000@entrox.org> References: <75833DA1-EC89-4DE1-BC4F-CD46AB33E6F5@gmail.com> <84D3205C-4A4E-4CFF-AC95-A926AC237000@entrox.org> Message-ID: <2EF3E96C-4923-4E56-A87E-226174B023AF@gmail.com> On 2006-feb-08, at 11:54, Oliver Markovic wrote: > It's hard to stay consistent and obvious to the user. Personally, I > wouldn't > like to have to look into the documentation to see how some names > get translated from the spec/C-side to Lisp. YMMV. Yes, of course. I completely agree with you. What about having the enum provide both :color-buffer and :color-buffer-bit? BTW, more minor style stuff. I think maybe we should have both with- primitives and with-primitive as synonyms. While (with- primitives :lines ...) makes total sense, (with- primitives :polygon ...) looks very weird to me. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From luismbo at gmail.com Wed Feb 15 15:10:00 2006 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 15 Feb 2006 15:10:00 +0000 Subject: [cl-opengl-devel] New CFFI features relevant to cl-opengl Message-ID: <7A0E49B7-E450-48A4-8E39-0EE5CD943D78@gmail.com> Hello, I have added macroexpansion-time translators to CFFI and this is quite relevant to cl-opengl. Here's an example: CFFI> (defctype ensure-float :float) ENSURE-FLOAT CFFI> (defmethod expand-to-foreign (value (type (eql 'ensure-float))) (if (constantp value) (float (eval value)) `(float ,value))) ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. VALUE TYPE): ; Compiling Top-Level Form: # CFFI> (macroexpand-1 '(defcfun "sqrtf" :float (x ensure-float))) (PROGN NIL (DEFUN SQRTF (X) (LET ((#:G2792 (FLOAT X))) (VALUES (%FOREIGN-FUNCALL "sqrtf" :FLOAT #:G2792 :FLOAT))))) T CFFI> I propose that we use this in cl-opengl and volunteer to do that. :-) That would mean passing some of the DEFCFUNs in funcs.lisp over to the respective .lisp right? Though I see some functions that are just (defun foo (...) (%foo ...)) what's up with that? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From entrox at entrox.org Mon Feb 20 19:41:28 2006 From: entrox at entrox.org (Oliver Markovic) Date: Mon, 20 Feb 2006 20:41:28 +0100 Subject: [cl-opengl-devel] Minor style questions In-Reply-To: <2EF3E96C-4923-4E56-A87E-226174B023AF@gmail.com> References: <75833DA1-EC89-4DE1-BC4F-CD46AB33E6F5@gmail.com> <84D3205C-4A4E-4CFF-AC95-A926AC237000@entrox.org> <2EF3E96C-4923-4E56-A87E-226174B023AF@gmail.com> Message-ID: Sorry for the long delay in answering; I was on vacation over the past few days. On 08.02.2006, at 17:51, Lu?s Oliveira wrote: > Yes, of course. I completely agree with you. What about having the > enum provide both :color-buffer and :color-buffer-bit? I think this would be a good compromise. > BTW, more minor style stuff. I think maybe we should have both > with-primitives and with-primitive as synonyms. While (with- > primitives :lines ...) > makes total sense, (with-primitives :polygon ...) looks very weird > to me. This is true, and it makes me doubt that WITH-PRIMITIVE(S) is such a good name after all. It's always called "glBegin/glEnd" in OpenGL literature, but WITH-BEGIN-END-BLOCK sounds weird to me. -- Oliver Markovic From entrox at entrox.org Mon Feb 20 20:05:34 2006 From: entrox at entrox.org (Oliver Markovic) Date: Mon, 20 Feb 2006 21:05:34 +0100 Subject: [cl-opengl-devel] New CFFI features relevant to cl-opengl In-Reply-To: <7A0E49B7-E450-48A4-8E39-0EE5CD943D78@gmail.com> References: <7A0E49B7-E450-48A4-8E39-0EE5CD943D78@gmail.com> Message-ID: On 15.02.2006, at 16:10, Lu?s Oliveira wrote: > I have added macroexpansion-time translators to CFFI and this is > quite relevant to cl-opengl. Here's an example: > [...] > I propose that we use this in cl-opengl and volunteer to do that. :-) Neat! This would cut out a lot of the annoying (float ...) throughout the wrappers. It seems to me like a lot of things that I used to do by hand are made obsolete by CFFI advancements. Maybe we won't need any wrappers at all soon? :) BTW, can I request a FOREIGN-ENUM-P? I have been working on the state queries lately (so much typing.. argh), and this would come in handy. My current definition looks like this: (defun foreign-enum-p (enum) (typep (cffi::find-type enum) 'cffi::foreign-enum)) (foreign-enum-p 'begin-mode) => t (foreign-enum-p 'float) => nil > That would mean passing some of the DEFCFUNs in funcs.lisp > over to the respective .lisp right? Though I see some > functions that are just (defun foo (...) (%foo ...)) what's up with > that? The reason for keeping the wrapper functions separate from the FFI definitions is that I thought it might be possible to also support FFI-less GLX without having to change any of the wrappers. Suppose there are two backends, one for the C-based library and one for GLX through CLX, then a call to %glFoo could be either a foreign call or some Lisp function which sends out the appropriate GLX request to the server, depending on which backend is loaded. Note that I never intended to write a GLX backend, but I wanted to keep the possibility open and tried not to conflate the wrappers with the FFI definitions to make it easier if somebody wants to work on such a thing. The functions you mention are just there for consistency with this separation. I'm not sure if anybody actually needs such a thing and if there's any real value in keeping the definitions separate though. -- Oliver Markovic From rogersm at rogersm.net Mon Feb 20 22:04:28 2006 From: rogersm at rogersm.net (Roger Sen Montero) Date: Mon, 20 Feb 2006 21:04:28 -0100 Subject: [cl-opengl-devel] Minor style questions In-Reply-To: References: <75833DA1-EC89-4DE1-BC4F-CD46AB33E6F5@gmail.com> <84D3205C-4A4E-4CFF-AC95-A926AC237000@entrox.org> <2EF3E96C-4923-4E56-A87E-226174B023AF@gmail.com> Message-ID: <43FA3CEC.5040502@rogersm.net> Hi all, Oliver Markovic wrote: [..] > On 08.02.2006, at 17:51, Lu?s Oliveira wrote: > >> BTW, more minor style stuff. I think maybe we should have both >> with-primitives and with-primitive as synonyms. While (with-primitives >> :lines ...) >> makes total sense, (with-primitives :polygon ...) looks very weird to me. > > This is true, and it makes me doubt that WITH-PRIMITIVE(S) is such > a good name after all. It's always called "glBegin/glEnd" in OpenGL > literature, but WITH-BEGIN-END-BLOCK sounds weird to me. It's always the same trade off: try to create a closer to lisp API vs. not getting to far away from the original one so the new API is easy to understand. The guys at pyopengl did a mirror of OpenGL. I don't know what should you do in lisp-gl, but for my graphical library I decided to diverge from the SDL lib. I'm sure someone will do an exact translation from SDL*.h with SWIG (or even manually) My idea is a library that can be used the following way: (init :init-video) (with-open-window (s "Hi, my window name is this" '(640 480) :doublebuf) (loop for i from 1 to 480 do (draw-point s i i (random (expt 2 24)))) (update s) (event-loop SDL_WaitEvent event (SDL_QUIT (quit)))) I'm not interested in mimicking how the API works in C. If someone plans to work in lisp in a C way he can do it with the SWIG generated file. Some time in the future, when the low level SDL-cffi lisp file is stable I will base my library on top of it. Regards, rogersm. From entrox at entrox.org Mon Feb 20 20:25:27 2006 From: entrox at entrox.org (Oliver Markovic) Date: Mon, 20 Feb 2006 21:25:27 +0100 Subject: [cl-opengl-devel] Minor style questions In-Reply-To: <43FA3CEC.5040502@rogersm.net> References: <75833DA1-EC89-4DE1-BC4F-CD46AB33E6F5@gmail.com> <84D3205C-4A4E-4CFF-AC95-A926AC237000@entrox.org> <2EF3E96C-4923-4E56-A87E-226174B023AF@gmail.com> <43FA3CEC.5040502@rogersm.net> Message-ID: <8E518984-81F8-40A6-B0F5-3C6D2521C379@entrox.org> On 20.02.2006, at 23:04, Roger Sen Montero wrote: > It's always the same trade off: try to create a closer to lisp API > vs. not > getting to far away from the original one so the new API is easy to > understand. The goal is having an OpenGL binding in Lisp, which doesn't require people to think about C-ish things like having to pass pointers to arrays in order to get the current color. > The guys at pyopengl did a mirror of OpenGL. I don't know what > should you do in lisp-gl, but for my graphical library I decided to > diverge from the SDL lib. We don't really diverge and try to keep the mapping between the C and Lisp names obvious. The macro in question is pure sugar and doesn't have a C equivalent. (defun draw-foo () (gl:with-primitives :quads (gl:color 1 0 0) (gl:vertex -1 -1 ) ... (gl:vertex 1 1))) instead of (defun draw-foo () (gl:begin :quads) (gl:color 1 0 0) (gl:vertex -1 -1) ... (gl:vertex 1 1) (gl:end)) -- Oliver Markovic From lvecsey at nyc.rr.com Tue Feb 21 18:14:57 2006 From: lvecsey at nyc.rr.com (Lester Vecsey) Date: Tue, 21 Feb 2006 13:14:57 -0500 Subject: [cl-opengl-devel] freeglut.dll + scope of cl-opengl Message-ID: <000c01c63712$b979bce0$6ee36c42@simulation> It took me some time to find a copy of freeglut.dll to place into my system folder, eventually retrieving it from http://www.turtle.dds.nl/gl4newlisp/index.html On windows the freeglut source is currently only meant to be built with MSVC, as opposed to mingw/msys, and it may be some time until thats resolved. So it might be a good idea to make a copy of the above mentioned freeglut.dll available at the common-lisp.net/project/cl-opengl page. A couple other minor notes with the redbook examples so far. With CLISP, the character #\Esc is mentioned in rb3-lines.lisp and rb4-poly.lisp, and above, and had to be changed to #\Escape As I understand it cl-opengl is currently dependent on freeglut to open a GL canvas. Is there any interest in having a few C functions to call in to, or perhaps written entirely in Lisp as CFFI to each of the required underlying functions, to generate the Windows HWND and XWindows surfaces? On windows, the WndProc functions which takes care of mouse and keyboard events would be handled with a separate package, and similarly for XWindows with its Xevents. The benefit here is that for many applications you may not need the extensive menu system of freeglut and thus can eliminate the dependency on that library. The other question I have is about the scope of cl-opengl, in terms of handling applications meant to run at 60hz frame rate in the following sense; it would seem that cl-opengl would be the place to have a compiler of sorts, to handle a common situation where conditionals are placed in the main rendering loop to draw sets of Gl primitives. Suppose in my application I toggle one of these such that now the rendering loop makes an additional call into a function that has a glDrawArrays call for some set of polygons, along with other conditionals in the function that branches for choosing between other GL primitives. An extra set of polygons may be drawn with a bright color to draw attention to some part of the visual model, and so on. This is where cl-opengl functions or macros would step in because my Lisp code thus wrapped with some opengl-with statements would effectively have these gl primatives bundled into consecutive display lists where applicable such that in the final analysis there are just a minimal set of glCallList statements being made to the hardware. Those very same calls to glCallList would persist for many frames until the application toggles additional code so that only the affected and adjacent display lists get rebuilt. The programmer would use these wrappers only around code that would benefit from having these display lists built to persist over more than a few frames. As I understand it that was one of the stated goals of the cells opengl framework though having looked through the current cl-opengl code the closest thing I can come to this is found in util.lisp, and no examples as of yet to do the above. If this can be cleanly addressed conceptually by adopting some layout when implementing applications I'd like to hear about that too. Currently for my OpenGL programs I've amassed a set of lower level C functions that take variables representing states, i.e. packed into an unsigned 32 bit value, and use display lists and just recompute the important ones where appropriate. A set of Lisp wrappers would probably dramatically change the way such code would look and is approached, making it much more compact in terms of number of lines and perhaps even packed maximally linearly efficient, so to speak, for eliminating unnecessary gl statements in the main loop, all with little effort from the programmer. As a specific example, a call to reset the glColor to white at the beginning of a functions processing that may have much more work to do, depending on its current toggles, could actually be tossed into a preexisting display list from the previous function that had its trailing end of work to do. However doing that manually is out of the question since it would involve much more code, either a dedicated display list for that one area or even more time consuming if statements in other functions so it can be tacked on. Overall, once packed into the list it would be a very minor performance win by reducing just that one call for a gl primitive, for sure, however it could add up when you consider the overlap of various functions in the main loop each of which are doing some subwork. In a C language perhaps the framework would look something like having function pointers to a heading and trailing set of gl primitive code which would be considered static for each of the subwork functions, perhaps labeled header and footer, and the actual dynamic code that the subwork function implements itself. Assuming the guts of the subwork function becomes ``static'' for at least a few frames, then all of it can be absorbed into a display list and in fact the entire function with all its conditionals effectively disappears, from a gl runtime perspective. Later that portion of the display list can be regenerated to that depth when requested by a mouse or key toggle, i.e., an outside function, and be called again down to that depth so it is fully rebuilt with current values, and re-absorbed into the current master chain or set of the minimal amount of display lists. Imagine a scenario where hundreds of frames have gone by with no changes from network, mouse, or keyboard events. Then its possible that all the gl calls can be placed into a single display list and at some point the list will have to be split so that different code can be inserted. So if the main list was previously in two sublists before, and some feature was just toggled back on then it might be a good idea to have kept those sublists around for a while so now three lists are ready to be called; the outer two sublists, and the newly recomputed feature. After many frames pass, sublists that have gone unchanged can be merged together. And again, code that is likely to change every frame would simply never be wrapped with these lisp macros to begin with. From luismbo at gmail.com Tue Feb 21 22:37:17 2006 From: luismbo at gmail.com (=?utf-8?Q?Lu=C3=ADs?= Oliveira) Date: Tue, 21 Feb 2006 22:37:17 +0000 Subject: [cl-opengl-devel] Re: freeglut.dll + scope of cl-opengl References: <000c01c63712$b979bce0$6ee36c42@simulation> Message-ID: "Lester Vecsey" writes: > On windows the freeglut source is currently only meant to be built with > MSVC, as opposed to mingw/msys, and it may be some time until thats > resolved. So it might be a good idea to make a copy of the above mentioned > freeglut.dll available at the common-lisp.net/project/cl-opengl page. I don't have convenient access to Windows. When I have the chance I will compile freeglut and upload it to c-l.net. cl-opengl is still in its infancy, anyway. > A couple other minor notes with the redbook examples so far. With CLISP, the > character #\Esc is mentioned in rb3-lines.lisp and rb4-poly.lisp, and above, > and had to be changed to #\Escape #\Esc works for me in CLISP. What version are you using? > As I understand it cl-opengl is currently dependent on freeglut to open a GL > canvas. Not really. You can use whatever toolkit you prefer. > Is there any interest in having a few C functions to call in to, or > perhaps written entirely in Lisp as CFFI to each of the required underlying > functions, to generate the Windows HWND and XWindows surfaces? On windows, > the WndProc functions which takes care of mouse and keyboard events would be > handled with a separate package, and similarly for XWindows with its > Xevents. The benefit here is that for many applications you may not need the > extensive menu system of freeglut and thus can eliminate the dependency on > that library. See above. Rolling our own GLUT-like thing in Lisp might have various advantages. Namely, we wouldn't have to worry about the C library rudely calling exit(), sigh. Anyone is free to start such a project, I'd certainly use that! CL-GLUT is just a convenient way of *playing* with cl-opengl and OpenGL in general. That was my goal while writing those bindings anyway. [...] > The programmer would use these wrappers only around code that would benefit > from having these display lists built to persist over more than a few > frames. One of cl-opengl's goal is to be Lispy so it only makes sense that a convenient way to use display lists will be designed even if not as fancy as what you suggest. Sounds interesting though. I've never seen the cells opengl stuff but surely cells-opengl can be implemented using the cl-opengl bindings. -- Lu?s Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From luismbo at gmail.com Tue Feb 21 23:06:49 2006 From: luismbo at gmail.com (=?utf-8?Q?Lu=C3=ADs?= Oliveira) Date: Tue, 21 Feb 2006 23:06:49 +0000 Subject: [cl-opengl-devel] Re: New CFFI features relevant to cl-opengl References: <7A0E49B7-E450-48A4-8E39-0EE5CD943D78@gmail.com> Message-ID: Oliver Markovic writes: > Neat! This would cut out a lot of the annoying (float ...) throughout > the wrappers. It seems to me like a lot of things that I used to do by > hand are made obsolete by CFFI advancements. Maybe we won't > need any wrappers at all soon? :) The less wrappers the better. :-) > BTW, can I request a FOREIGN-ENUM-P? Sure. That sounds useful. I'll try to come up with some sort of more generic foreign-typep first and if I fail, I'll add foreign-enum-p. > The reason for keeping the wrapper functions separate from the FFI > definitions is that I thought it might be possible to also support > FFI-less > GLX without having to change any of the wrappers. Suppose there are > two backends, one for the C-based library and one for GLX through CLX, > then a call to %glFoo could be either a foreign call or some Lisp > function > which sends out the appropriate GLX request to the server, depending > on which backend is loaded. What about something like this: (defmacro defglfun (name rettype &body args) `(defcfun ,name ,rettype , at args)) Then a CLX backend would implement this macro (which would probably be slightly more complicated, I'm sure). I have no idea if this makes sense as I've never touched CLX. Again, if it does make sense, I volunteer to do the gruntwork. :-) -- Lu?s Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From entrox at entrox.org Wed Feb 22 20:13:32 2006 From: entrox at entrox.org (Oliver Markovic) Date: Wed, 22 Feb 2006 21:13:32 +0100 Subject: [cl-opengl-devel] Re: New CFFI features relevant to cl-opengl In-Reply-To: References: <7A0E49B7-E450-48A4-8E39-0EE5CD943D78@gmail.com> Message-ID: <31A2BCEC-8DEB-4088-888C-1919621F49A5@entrox.org> On 22.02.2006, at 00:06, Lu?s Oliveira wrote: > What about something like this: > > (defmacro defglfun (name rettype &body args) > `(defcfun ,name ,rettype , at args)) > > Then a CLX backend would implement this macro (which would probably be > slightly more complicated, I'm sure). I have no idea if this makes > sense > as I've never touched CLX. > > Again, if it does make sense, I volunteer to do the gruntwork. :-) Yes, this is pretty much what I had in mind, but I'm not sure if this is so important to change right now. I'd try to focus on getting a releasable binding for OpenGL and GLU(T) with sane semantics for CFFI first before making too many accommodations for hypothetical features which may never get implemented anyway. But feel free to do it if you're bored. :) -- Oliver Markovic From lvecsey at nyc.rr.com Thu Feb 23 04:53:22 2006 From: lvecsey at nyc.rr.com (Lester Vecsey) Date: Wed, 22 Feb 2006 23:53:22 -0500 Subject: [cl-opengl-devel] Re: freeglut.dll + scope of cl-opengl References: <000c01c63712$b979bce0$6ee36c42@simulation> Message-ID: <004201c63835$13c15fa0$6ee36c42@simulation> ----- Original Message ----- From: "Lu?s Oliveira" > > I don't have convenient access to Windows. When I have the chance I will > compile freeglut and upload it to c-l.net. cl-opengl is still in its > infancy, anyway. > The 249,344 byte freeglut.dll from http://www.turtle.dds.nl/gl4newlisp/freeglut.dll worked just fine for me on WinXP SP2, so you could just mirror that to the common-lisp.net site for now. All the redbook examples and the mesa gear demo ran just fine with this. > >> A couple other minor notes with the redbook examples so far. With CLISP, >> the >> character #\Esc is mentioned in rb3-lines.lisp and rb4-poly.lisp, and >> above, >> and had to be changed to #\Escape > > #\Esc works for me in CLISP. What version are you using? > Its CLISP 2.38 compiled with mingw/msys on windows, > See above. Rolling our own GLUT-like thing in Lisp might have various > advantages. Namely, we wouldn't have to worry about the C library > rudely calling exit(), sigh. > > Anyone is free to start such a project, I'd certainly use that! > > CL-GLUT is just a convenient way of *playing* with cl-opengl and OpenGL > in general. That was my goal while writing those bindings anyway. > I can probably contribute some code for this at some point, which on windows creates a window and sets up a GL canvas, as well as registering a Common Lisp ``WndProc'' callback function which gets called by the Microsoft OS whenever a message is sent to the created window, i.e. a keyboard or mouse event. I'm currently developing an app using cl-opengl so I'll see about merging some of that in, and if it gets to a point where I can contribute it back I'll let you know. > [...] >> The programmer would use these wrappers only around code that would >> benefit >> from having these display lists built to persist over more than a few >> frames. > > One of cl-opengl's goal is to be Lispy so it only makes sense that > a convenient way to use display lists will be designed even if not as > fancy as what you suggest. > > Sounds interesting though. I've never seen the cells opengl stuff but > surely cells-opengl can be implemented using the cl-opengl bindings. > cells opengl was initially meant for the hello-c FFI interface though they may have moved to CFFI now. It always seemed like a moving target and so the examples, such as a light and texturing application, never ran for me. Anyhow its worth looking into to see where they are going with it, if it is still being developed at all. The cells project itself revolves around the concept of having a spreadsheet so to speak, where when certain cells are modified then only the related ones get recomputed. So there may be a way to use that approach to deal with some of the display list issues.