From turbo24prg at web.de Fri Aug 8 11:35:58 2008 From: turbo24prg at web.de (=?ISO-8859-1?Q?Bastian_M=FCller?=) Date: Fri, 08 Aug 2008 13:35:58 +0200 Subject: [cl-opengl-devel] working setup Message-ID: <489C2F9E.5040209@web.de> Hi, I'm currently trying to get a working setup up and running but have the following problems: No matter which combination of cffi (0.10.0 or darcs HEAD) and cl-opengl (darcs HEAD or darcs versions some months older) I use, some don't work at all, others for example just let me run the glut-teapot example one time and crash after a second run: CL-USER> (glut-teapot) ; No value CL-USER> (glut-teapot) Unhandled memory fault at #x7FA94AAD37F3. [Condition of type SB-SYS:MEMORY-FAULT-ERROR] Is there a working cffi + cl-opengl combination or do I have to use different branches like cffi-newtypes, cffi+lotsastuff or cl-opengl-thomas? I'm using SBCL btw. Thanks, Bastian From 00003b at gmail.com Tue Aug 12 01:55:42 2008 From: 00003b at gmail.com (Bart Botta) Date: Mon, 11 Aug 2008 20:55:42 -0500 Subject: [cl-opengl-devel] OpenGL 3.0 Message-ID: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> OpenGL 3 spec has been released: http://www.opengl.org/registry/doc/glspec30.20080811.pdf Instead of the originally planned rewrite, it ended up being just more stuff piled onto the old API, but they did add a mechanism for deprecating old features, and a way to create contexts which cannot use deprecated features. Any opinions on adding a cleaned up, gl3+ only version of cl-opengl which doesn't support the deprecated features or most of the older extensions, either as a fork, a separate mode for the main codebase (alternate .asd or with compile time checks), or some other way? --- -b- From luismbo at gmail.com Thu Aug 14 16:30:59 2008 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Thu, 14 Aug 2008 17:30:59 +0100 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> Message-ID: <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> On Tue, Aug 12, 2008 at 2:55 AM, Bart Botta <00003b at gmail.com> wrote: > Any opinions on adding a cleaned up, gl3+ only version of cl-opengl > which doesn't support the deprecated features or most of the older > extensions, either as a fork, a separate mode for the main codebase > (alternate .asd or with compile time checks), or some other way? Adding a cl-opengl3 system sounds like a good idea. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From 00003b at gmail.com Thu Aug 14 16:57:53 2008 From: 00003b at gmail.com (Bart Botta) Date: Thu, 14 Aug 2008 11:57:53 -0500 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> Message-ID: <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> On Thu, Aug 14, 2008 at 11:30 AM, Lu?s Oliveira wrote: > > Adding a cl-opengl3 system sounds like a good idea. > With completely separate code, or with it shared in some way? Keeping the ffi level stuff separate is probably easier than trying to split it into 3 parts (common, parts of 3+ not shared by older versions, and parts of older versions removed from new versions). For lisp level stuff, it might be worth factoring out common code, though differences in valid arguments might make that harder... By my count, full gl3 core has about 620 functions total. Without deprecated functions, there are 286 left. (for comparison, I count 336 in gl1.0 + 1.1, of which 78 remain after removing deprecated functions) -b- From luismbo at gmail.com Fri Aug 15 14:31:18 2008 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Fri, 15 Aug 2008 15:31:18 +0100 Subject: [cl-opengl-devel] working setup In-Reply-To: <489C2F9E.5040209@web.de> References: <489C2F9E.5040209@web.de> Message-ID: <391f79580808150731s595e22b4u1b77e8027dc8d7c6@mail.gmail.com> On Fri, Aug 8, 2008 at 12:35 PM, Bastian M?ller wrote: > I'm currently trying to get a working setup up and running What OS are you running on? You should be using FreeGLUT, btw. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From luismbo at gmail.com Mon Aug 18 01:30:49 2008 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Mon, 18 Aug 2008 02:30:49 +0100 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> Message-ID: <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> On Thu, Aug 14, 2008 at 5:57 PM, Bart Botta <00003b at gmail.com> wrote: > On Thu, Aug 14, 2008 at 11:30 AM, Lu?s Oliveira wrote: >> >> Adding a cl-opengl3 system sounds like a good idea. >> > With completely separate code, or with it shared in some way? I clearly don't understand the difficulties involved. :-) But what about this: cl-opengl3.asd would load whatever is needed by the non-deprecated parts of GL 3.0. cl-opengl.asd would load everything. (including cl-opengl3.asd, on which it would depend.) Would that work? -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From 00003b at gmail.com Mon Aug 18 13:49:48 2008 From: 00003b at gmail.com (Bart Botta) Date: Mon, 18 Aug 2008 08:49:48 -0500 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> Message-ID: <77cb99c00808180649p8b41406y272ff4b383c949fd@mail.gmail.com> On Sun, Aug 17, 2008 at 8:30 PM, Lu?s Oliveira wrote: > I clearly don't understand the difficulties involved. :-) But what > about this: cl-opengl3.asd would load whatever is needed by the > non-deprecated parts of GL 3.0. cl-opengl.asd would load everything. > (including cl-opengl3.asd, on which it would depend.) > > Would that work? I think so, main problem i can think of offhand is that there are probably places where some arguments are only valid for the full context. I guess we already have that situation with extensions though, so that is just a case of not cleaning up the gl3fc code quite as much as is theoretically possible. So add a gl3/ and then split the existing files in gl/ between the two? -b- From luismbo at gmail.com Mon Aug 18 15:08:15 2008 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Mon, 18 Aug 2008 16:08:15 +0100 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <77cb99c00808180649p8b41406y272ff4b383c949fd@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> <77cb99c00808180649p8b41406y272ff4b383c949fd@mail.gmail.com> Message-ID: <391f79580808180808x5094fa97r24bd0fce4ebe4250@mail.gmail.com> On Mon, Aug 18, 2008 at 2:49 PM, Bart Botta <00003b at gmail.com> wrote: > So add a gl3/ and then split the existing files in gl/ between the two? Sounds good. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From 00003b at gmail.com Mon Aug 18 15:16:46 2008 From: 00003b at gmail.com (Bart Botta) Date: Mon, 18 Aug 2008 10:16:46 -0500 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <391f79580808180808x5094fa97r24bd0fce4ebe4250@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> <77cb99c00808180649p8b41406y272ff4b383c949fd@mail.gmail.com> <391f79580808180808x5094fa97r24bd0fce4ebe4250@mail.gmail.com> Message-ID: <77cb99c00808180816p4885de0fq61e54af07736f267@mail.gmail.com> Another issue with GL3 that I forgot about: the enums for GL_DEPTH_BUFFER_BIT etc. accepted by glClear are abbreviated to :depth-buffer in current cl-opengl, but gl3 adds unrelated enums like GL_DEPTH_BUFFER that would conflict with some of those. Should we just remove the abbreviations (and update the samples that use them)? Possibly add a warning in glClear if the old names are used? -b- From 00003b at gmail.com Mon Aug 18 20:05:28 2008 From: 00003b at gmail.com (Bart Botta) Date: Mon, 18 Aug 2008 15:05:28 -0500 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <391f79580808181129j33882153wa1a9bccca47d9ad0@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> <77cb99c00808180649p8b41406y272ff4b383c949fd@mail.gmail.com> <391f79580808180808x5094fa97r24bd0fce4ebe4250@mail.gmail.com> <77cb99c00808180816p4885de0fq61e54af07736f267@mail.gmail.com> <391f79580808181129j33882153wa1a9bccca47d9ad0@mail.gmail.com> Message-ID: <77cb99c00808181305n469e8bf2p1e3d024044a04ff@mail.gmail.com> On Mon, Aug 18, 2008 at 1:29 PM, Lu?s Oliveira wrote: > > Actually, I wouldn't mind seeing the per-function enums come back. > Having compile-time warnings when we passed a bogus keyword was nice. > Can anyone remind me why were they collapsed into one enum? Sounds like a reasonable thing to have, if we can generate it easily (which we can't for GL3 at the moment, since there are not complete .spec files available yet). Only thing i could find in the list archives is that it is harder to deal with returning enums, though seems like at worst we could just have a combined set used for doing the reverse translations in that case. Also, looking at the glGet*, is there any reason we don't just map all of those to gl:get and add a compiler macro (or whatever) to pick the correct low level version? looks like the enum.spec files might even have enough info to map most of the enums to types, though probably have to pick out the ones that should be interpreted as enums by hand. -b- From deepankar.sharma at gmail.com Fri Aug 22 19:36:52 2008 From: deepankar.sharma at gmail.com (Deepankar Sharma) Date: Fri, 22 Aug 2008 15:36:52 -0400 Subject: [cl-opengl-devel] Issues on windows + ecl Message-ID: I have successfully used cl-opengl on linux+sbcl for some time. I am now trying to replicate this on windows since I am interested in creating executables for windows users. For this setup I am trying to use ecl. I am running into some issues with interface.lisp in cl-glut. For some reason even though there is a shadow statement for close and special , I get this when i try to load cl-glut-examples ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The symbol CLOSE is bound to an ordinary function and is not a valid name for a generic function Broken at SI:BYTECODES.Available restarts: 1. (TRY-RECOMPILING) Recompile interface and try loading it again 2. (RETRY) Retry performing # on #. 3. (ACCEPT) Continue, treating # on # as having been successful. Broken at SI:BYTECODES. CL-GLUT>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Any workarounds for this ? Has anyone used cl-opengl successfully with ecl ? Thanks, Deepankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From luismbo at gmail.com Fri Aug 22 22:07:08 2008 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Fri, 22 Aug 2008 23:07:08 +0100 Subject: [cl-opengl-devel] Issues on windows + ecl In-Reply-To: References: Message-ID: <391f79580808221507n2ce72a63kd02597ae2d63db08@mail.gmail.com> 2008/8/22 Deepankar Sharma : > Any workarounds for this ? Has anyone used cl-opengl successfully with ecl ? Having just tried to get things working with ECL and having failed miserably at compiling the dependencies and other stuff, all I can suggest is that you try to come up with a minimal test case and report it to ECL's mailing list. For this specific case, maybe moving the shadowing into the defpackage form helps? I have no idea, ECL breaks in very unexpected and original ways each time I give it a spin. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From charliemac+cl-opengl at gmail.com Thu Aug 28 02:05:12 2008 From: charliemac+cl-opengl at gmail.com (Charlie McMackin) Date: Thu, 28 Aug 2008 11:05:12 +0900 Subject: [cl-opengl-devel] OpenGL 3.0 .spec and .enum files released Message-ID: <6e831e4e0808271905w38f51e3bnf0b43b5a09bb5fc7@mail.gmail.com> Here's the relative thread from Jon Leech on the OpenGL forum: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=244945#Post244945 and of course the link to the registry : http://www.opengl.org/registry From 00003b at gmail.com Sat Aug 30 21:42:10 2008 From: 00003b at gmail.com (Bart Botta) Date: Sat, 30 Aug 2008 16:42:10 -0500 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <77cb99c00808181305n469e8bf2p1e3d024044a04ff@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> <77cb99c00808180649p8b41406y272ff4b383c949fd@mail.gmail.com> <391f79580808180808x5094fa97r24bd0fce4ebe4250@mail.gmail.com> <77cb99c00808180816p4885de0fq61e54af07736f267@mail.gmail.com> <391f79580808181129j33882153wa1a9bccca47d9ad0@mail.gmail.com> <77cb99c00808181305n469e8bf2p1e3d024044a04ff@mail.gmail.com> Message-ID: <77cb99c00808301442l1204d696x7f556b2369abbc3a@mail.gmail.com> On Mon, Aug 18, 2008 at 3:05 PM, Bart Botta <00003b at gmail.com> wrote: > On Mon, Aug 18, 2008 at 1:29 PM, Lu?s Oliveira wrote: >> Actually, I wouldn't mind seeing the per-function enums come back. >> Having compile-time warnings when we passed a bogus keyword was nice. > > Sounds like a reasonable thing to have, if we can generate it easily > (which we can't for GL3 at the moment, since there are not complete > .spec files available yet). > OK, after looking at the full gl3 .spec files, it looks like we can't generate all of the function specific enums automatically. It looks like it has some of the older enums split out, but not sure if they include all the newer extensions or not. Probably could build up a full set of enums, if we don't mind giving up on being able to completely regenerate the enums automatically. I've been thinking that might be a good idea in general though (the not fully automatic bindings part), since GL naming isn't consistent enough to rely on the automatic stuff for new function names anyway, so currently adding new extensions requires a few passes of proofreading the generated bindings and editing the generator. Does it sound reasonable to split the binding generation into 3 steps, only 2 automatic: First would parse the .spec files, tracking any enum groups defined in the file, approximately splitting up function names, etc. and write the results to some lispy format (reusing output of step 2 if available). Second step would be editing the generated data by hand, adding missing enum groups, fixing word breaks that the automatic code got wrong, etc. Third would be parsing the hand edited code to generate the actual bindings. -b- From luismbo at gmail.com Sat Aug 30 22:27:27 2008 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Sat, 30 Aug 2008 23:27:27 +0100 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <77cb99c00808301442l1204d696x7f556b2369abbc3a@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <391f79580808140930l4973d9b1g5bc4944f0c208912@mail.gmail.com> <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> <77cb99c00808180649p8b41406y272ff4b383c949fd@mail.gmail.com> <391f79580808180808x5094fa97r24bd0fce4ebe4250@mail.gmail.com> <77cb99c00808180816p4885de0fq61e54af07736f267@mail.gmail.com> <391f79580808181129j33882153wa1a9bccca47d9ad0@mail.gmail.com> <77cb99c00808181305n469e8bf2p1e3d024044a04ff@mail.gmail.com> <77cb99c00808301442l1204d696x7f556b2369abbc3a@mail.gmail.com> Message-ID: <391f79580808301527h14c04d77n313bdef936ed1558@mail.gmail.com> 2008/8/30 Bart Botta <00003b at gmail.com>: > Does it sound reasonable to split the binding generation into 3 steps, > only 2 automatic: > First would parse the .spec files, tracking any enum groups defined in > the file, approximately splitting up function names, etc. and write > the results to some lispy format (reusing output of step 2 if > available). > Second step would be editing the generated data by hand, adding > missing enum groups, fixing word breaks that the automatic code got > wrong, etc. > Third would be parsing the hand edited code to generate the actual bindings. Sounds good to me. It'd be great if this process could somehow highlight changes in the spec so that step 2 can be focused on what changed instead of having to review everything. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From 00003b at gmail.com Sat Aug 30 23:18:57 2008 From: 00003b at gmail.com (Bart Botta) Date: Sat, 30 Aug 2008 18:18:57 -0500 Subject: [cl-opengl-devel] OpenGL 3.0 In-Reply-To: <391f79580808301527h14c04d77n313bdef936ed1558@mail.gmail.com> References: <77cb99c00808111855pfe35caftd98c5356f1ba5e91@mail.gmail.com> <77cb99c00808140957i514b5f60g4c4d593ee78363ac@mail.gmail.com> <391f79580808171830q3821025ag9028cfb187ced1e4@mail.gmail.com> <77cb99c00808180649p8b41406y272ff4b383c949fd@mail.gmail.com> <391f79580808180808x5094fa97r24bd0fce4ebe4250@mail.gmail.com> <77cb99c00808180816p4885de0fq61e54af07736f267@mail.gmail.com> <391f79580808181129j33882153wa1a9bccca47d9ad0@mail.gmail.com> <77cb99c00808181305n469e8bf2p1e3d024044a04ff@mail.gmail.com> <77cb99c00808301442l1204d696x7f556b2369abbc3a@mail.gmail.com> <391f79580808301527h14c04d77n313bdef936ed1558@mail.gmail.com> Message-ID: <77cb99c00808301618s3921d47dp5a984a94eaba1fc5@mail.gmail.com> On Sat, Aug 30, 2008 at 5:27 PM, Lu?s Oliveira wrote: > > Sounds good to me. It'd be great if this process could somehow > highlight changes in the spec so that step 2 can be focused on what > changed instead of having to review everything. > Yeah, that was the idea, though I'm leaning towards just letting the version control deal with highlighting the changes. -b-