From luismbo at gmail.com Wed Jun 8 19:29:24 2011 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 8 Jun 2011 20:29:24 +0100 Subject: [cl-opengl-devel] Using idle events to drive Slime In-Reply-To: References: Message-ID: On Thu, Oct 28, 2010 at 12:58 PM, Nikodemus Siivola wrote: > I'm wondering if there should be a single global *IDLE-HOOK* (or maybe > REGISTER-IDLE-HOOK) in addition to the per-window method approach -- > something which causes windows to automatically subscribe to Idle > events without registering themselves in *WINDOWS-WITH-IDLE-EVENTS*. Sounds like a good straightforward idea. I've implemented that here: I'll send a pull request to Bart after testing it. -- Lu?s Oliveira http://r42.eu/~luis/ From o.simon at gmail.com Sat Jun 25 09:55:09 2011 From: o.simon at gmail.com (Simon Ortiz) Date: Sat, 25 Jun 2011 18:55:09 +0900 Subject: [cl-opengl-devel] CL-OpenGL ES? Message-ID: dear cl-opengl people, I'm working on a project to make games on Android and iPhone using Lisp. Thanks to the work of R. Krishnan and S. Ageneau ECL runs on these devices. I'm taking it from there and I'm trying to draw to the screen from Lisp. So far, I've achieved modest results using my own (very small and rudimentary) OpenGL ES 1.1 interface, which uses ECL's low-level FFI facility. But I think that it would be a waste to come up with another OpenGL interface. I'm thinking, why not better use cl-opengl? So, I would like to ask you some questions: - what versions of OpenGL does cl-opengl support? - say I want to contribute to the project and adapt cl-opengl into cl-opengl-es11 (and in the far future cl-opengl-es20), how should I do it? From where can I take it? Is there a similar project I can join? Is anyone interested in joining efforts? Thank you very much in advance for your advice. Sincerely, -- Sim?n Ortiz B., M.Sc., Ing. en Computaci?n Linux Registered User #388735 From luismbo at gmail.com Sun Jun 26 17:05:51 2011 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Sun, 26 Jun 2011 18:05:51 +0100 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: Hello, On Sat, Jun 25, 2011 at 10:55 AM, Simon Ortiz wrote: > But I think that it would be a waste to come up with another OpenGL > interface. I'm thinking, why not better use cl-opengl? I agree. It'd be nicer to contribute to cl-opengl than come up with yet another bindings package. :-) > So, I would like to ask you some questions: > > - what versions of OpenGL does cl-opengl support? cl-opengl generates low-level bindings by parsing the OpenGL spec. It's been recently updated for version OpenGL 4.1. We then have high-level Lispier bindings that are a work-in-progress. > - say I want to contribute to the project and adapt cl-opengl into > cl-opengl-es11 (and in the far future cl-opengl-es20), how should I do > it? From where can I take it? Is there a similar project I can join? > Is anyone interested in joining efforts? Bart had a branch of cl-opengl that generated separate systems for the modern and deprecated bits of OpengGL. IIUC, that'd get you most of the way towards a cl-opengl-es. I can't seem to find this branch. Perhaps Bart can chime in. Cheers, -- Lu?s Oliveira http://r42.eu/~luis/ From o.simon at gmail.com Mon Jun 27 13:46:50 2011 From: o.simon at gmail.com (Simon Ortiz) Date: Mon, 27 Jun 2011 22:46:50 +0900 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: Bart, please chime in! ;-) It'd be nice if the code for previous versions was available. Not just for ES 1.1, but in general. Sometimes you find platforms that only support a version of OpenGL which isn't the most recent one. Lu?s, thanks a lot! -- Sim?n Ortiz B., M.Sc., Ing. en Computaci?n Linux Registered User #388735 On Mon, Jun 27, 2011 at 02:05, Lu?s Oliveira wrote: > Hello, > > On Sat, Jun 25, 2011 at 10:55 AM, Simon Ortiz wrote: >> But I think that it would be a waste to come up with another OpenGL >> interface. I'm thinking, why not better use cl-opengl? > > I agree. It'd be nicer to contribute to cl-opengl than come up with > yet another bindings package. :-) > > >> So, I would like to ask you some questions: >> >> - what versions of OpenGL does cl-opengl support? > > cl-opengl generates low-level bindings by parsing the OpenGL spec. > It's been recently updated for version OpenGL 4.1. We then have > high-level Lispier bindings that are a work-in-progress. > > >> - say I want to contribute to the project and adapt cl-opengl into >> cl-opengl-es11 (and in the far future cl-opengl-es20), how should I do >> it? From where can I take it? Is there a similar project I can join? >> Is anyone interested in joining efforts? > > Bart had a branch of cl-opengl that generated separate systems for the > modern and deprecated bits of OpengGL. IIUC, that'd get you most of > the way towards a cl-opengl-es. I can't seem to find this branch. > Perhaps Bart can chime in. > > Cheers, > > -- > Lu?s Oliveira > http://r42.eu/~luis/ > From luismbo at gmail.com Mon Jun 27 13:58:53 2011 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Mon, 27 Jun 2011 14:58:53 +0100 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: On Mon, Jun 27, 2011 at 2:46 PM, Simon Ortiz wrote: > It'd be nice if the code for previous versions was available. Not just > for ES 1.1, but in general. Sometimes you find platforms that only > support a version of OpenGL which isn't the most recent one. Aren't the various GL versions backwards compatible? -- Lu?s Oliveira http://r42.eu/~luis/ From o.simon at gmail.com Mon Jun 27 14:04:20 2011 From: o.simon at gmail.com (Simon Ortiz) Date: Mon, 27 Jun 2011 23:04:20 +0900 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: yes, you're right. OpenGL is backwards compatible :D I got carried away with OpenGL ES, which lamentably isn't. Specifically, ES 2.0 is not compatible with ES 1.1 :( -- Sim?n Ortiz B., M.Sc., Ing. en Computaci?n Linux Registered User #388735 On Mon, Jun 27, 2011 at 22:58, Lu?s Oliveira wrote: > On Mon, Jun 27, 2011 at 2:46 PM, Simon Ortiz wrote: >> It'd be nice if the code for previous versions was available. Not just >> for ES 1.1, but in general. Sometimes you find platforms that only >> support a version of OpenGL which isn't the most recent one. > > Aren't the various GL versions backwards compatible? > > -- > Lu?s Oliveira > http://r42.eu/~luis/ > From luismbo at gmail.com Mon Jun 27 14:16:37 2011 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Mon, 27 Jun 2011 15:16:37 +0100 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: On Mon, Jun 27, 2011 at 3:04 PM, Simon Ortiz wrote: > I got carried away with OpenGL ES, which lamentably isn't. > Specifically, ES 2.0 is not compatible with ES 1.1 :( Interesting. Then we should have separate systems for each one and see which bits can be shared. My understanding is that, API-wise, OpenGL ES is a subset of GL plus set of egl* functions. Is that correct? The former can be carved out of the existing code. To generate bindings for egl* functions, the way to go would be to throw the OpenGL ES spec at the current spec-parsing code and see what happens. -- Lu?s Oliveira http://r42.eu/~luis/ From 00003b at gmail.com Tue Jun 28 02:35:58 2011 From: 00003b at gmail.com (Bart Botta) Date: Mon, 27 Jun 2011 21:35:58 -0500 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: I don't really know much about OpenGL ES, beyond what has been inherited by WebGL... On Mon, Jun 27, 2011 at 9:16 AM, Lu?s Oliveira wrote: > On Mon, Jun 27, 2011 at 3:04 PM, Simon Ortiz wrote: >> I got carried away with OpenGL ES, which lamentably isn't. >> Specifically, ES 2.0 is not compatible with ES 1.1 :( I think cl-opengl supports http://www.opengl.org/registry/specs/ARB/ES2_compatibility.txt, so it should at least be close to ES 2.0. Don't know if the functions are exact matches or just something similar though. > My understanding is that, API-wise, OpenGL ES is a subset of GL plus > set of egl* functions. Is that correct? The former can be carved out > of the existing code. To generate bindings for egl* functions, the way > to go would be to throw the OpenGL ES spec at the current spec-parsing > code and see what happens. The "spec" that cl-opengl parses is a more-or-less machine readable file available at http://www.opengl.org/registry/, not the actual specification. I'm not aware of anything similar for ES, so if the functions are not included in the main .spec files some other strategy would be required. I'd probably just parse the .h files to get a rough translation then edit it by hand from there, if the versions don't overlap as much as desktop GL. -b- From luismbo at gmail.com Tue Jun 28 11:15:57 2011 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 28 Jun 2011 12:15:57 +0100 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: On Tue, Jun 28, 2011 at 3:35 AM, Bart Botta <00003b at gmail.com> wrote: > The "spec" that cl-opengl parses is a more-or-less machine readable > file available at http://www.opengl.org/registry/, not the actual > specification. ?I'm not aware of anything similar for ES, so if the > functions are not included in the main .spec files some other strategy > would be required. Right, I was assuming that ES would also have a .spec file. That doesn't seem to be the case. >?I'd probably just parse the .h files to get a > rough translation then edit it by hand from there, if the versions > don't overlap as much as desktop GL. The set of egl* functions seems small enough to take this route. I'd probably even skip the .h parsing step. The remaining questions are: do we want a cl-opengl-es-1.1 system that only loads the relevant bits? (As opposed to defining the egl* bits then loading all of the remaining cl-opengl.) If so, what would be the best way to do it? One solution would be to list the ES's gl* functions somewhere in our spec directory and have the spec parser output those definitions to a separate directory/system, let's call it cl-opengl-base. Both cl-opengl and and cl-opengl-es-1.1 would then depend on cl-opengl-base. Simon, does this look like a sane approach? -- Lu?s Oliveira http://r42.eu/~luis/ From o.simon at gmail.com Tue Jun 28 15:03:05 2011 From: o.simon at gmail.com (Simon Ortiz) Date: Wed, 29 Jun 2011 00:03:05 +0900 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: Lu?s, you're right. OpenGL ES 1.1 is a subset of OpenGL 1.5 plus the egl* functions and a new data type: the fixed-point. Bart, I don't know much about WebGL other than it's based on OpenGL ES 2.0. I haven't had enough time to fiddle with cl-opengl nor with the parser. So I think my opinion might not be well informed enough. >From my ignorance, I would vote for loading only the relevant bits for ES. Given that it's going to run in a constrained environment, less loading is better (less memory consumption, faster loading time... although the difference in both could be dismissible). Plus, it might be safer. Would ugly things happen if you call a function defined in cl-opengl that isn't in OpenGL ES 1.1? I have some questions about the cl-opengl-base approach: would it require subtracting the common bits from the spec for cl-opengl? Or would the common bits be overwritten in cl-opengl? Would the cl-opengl-base approach scale nicely? Let's say we want to add ES 2.0, do we revise cl-opengl-base so that it is the intersection of functions in OpenGL 4.1, OpenGL ES 1.1 and OpenGL ES 2.0? Would this also be necessary if someone wanted to add WebGL, and when a new version of OpenGL is released? I guess the other approach would be to have independent systems. Yes, it's a shame ES doesn't have a spec file. If we take the independent system route, we could start from the spec of OpenGL 1.5 and remove the functions that aren't in ES 1.1. As Lu?s says, the egl* functions are few. Maybe we could also add them by hand to the ES 1.1 spec file. What do you guys think? -- Sim?n Ortiz B., M.Sc., Ing. en Computaci?n Linux Registered User #388735 On Tue, Jun 28, 2011 at 20:15, Lu?s Oliveira wrote: > On Tue, Jun 28, 2011 at 3:35 AM, Bart Botta <00003b at gmail.com> wrote: >> The "spec" that cl-opengl parses is a more-or-less machine readable >> file available at http://www.opengl.org/registry/, not the actual >> specification. ?I'm not aware of anything similar for ES, so if the >> functions are not included in the main .spec files some other strategy >> would be required. > > Right, I was assuming that ES would also have a .spec file. That > doesn't seem to be the case. > > >>?I'd probably just parse the .h files to get a >> rough translation then edit it by hand from there, if the versions >> don't overlap as much as desktop GL. > > The set of egl* functions seems small enough to take this route. I'd > probably even skip the .h parsing step. > > The remaining questions are: do we want a cl-opengl-es-1.1 system that > only loads the relevant bits? (As opposed to defining the egl* bits > then loading all of the remaining cl-opengl.) If so, what would be the > best way to do it? > > One solution would be to list the ES's gl* functions somewhere in our > spec directory and have the spec parser output those definitions to a > separate directory/system, let's call it cl-opengl-base. Both > cl-opengl and and cl-opengl-es-1.1 would then depend on > cl-opengl-base. > > Simon, does this look like a sane approach? > > -- > Lu?s Oliveira > http://r42.eu/~luis/ > From luismbo at gmail.com Tue Jun 28 15:57:24 2011 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Tue, 28 Jun 2011 16:57:24 +0100 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: On Tue, Jun 28, 2011 at 4:03 PM, Simon Ortiz wrote: > From my ignorance, I would vote for loading only the relevant bits for > ES. Given that it's going to run in a constrained environment, less > loading is better (less memory consumption, faster loading time... > although the difference in both could be dismissible). Plus, it might > be safer. Would ugly things happen if you call a function defined in > cl-opengl that isn't in OpenGL ES 1.1? I thing you'd simply get an undefined function error from CFFI. > I have some questions about the cl-opengl-base approach: would it > require subtracting the common bits from the spec for cl-opengl? Or > would the common bits be overwritten in cl-opengl? The former seems cleaner. > Would the cl-opengl-base approach scale nicely? Let's say we want to > add ES 2.0, do we revise cl-opengl-base so that it is the intersection > of functions in OpenGL 4.1, OpenGL ES 1.1 and OpenGL ES 2.0? Would > this also be necessary if someone wanted to add WebGL, and when a new > version of OpenGL is released? Not sure about nicely, but I suppose you could have a cl-opengl-base-1.1, cl-opengl-base-2.0, etc. If one's going to think about a layout like this in depth, it'd be interesting to take OpenGL profiles into account too. > I guess the other approach would be to have independent systems. However, we most certainly want to avoid duplication on the GL package since that package contains high-level abstractions that aren't automatically generated. > Yes, it's a shame ES doesn't have a spec file. If we take the > independent system route, we could start from the spec of OpenGL 1.5 > and remove the functions that aren't in ES 1.1. > > As Lu?s says, the egl* functions are few. Maybe we could also add them > by hand to the ES 1.1 spec file. I don't think adding them to the spec file is worth the trouble. Writing the CFFI definitions by hand is probably much simpler. I suggest you create a cl-opengl-es-1.1 system, make it depend on cl-opengl and add the egl functions to a new EGL package. We can then tackle the cl-opengl-base issue if it's worth the trouble. Cheers, -- Lu?s Oliveira http://r42.eu/~luis/ From o.simon at gmail.com Wed Jun 29 13:56:53 2011 From: o.simon at gmail.com (Simon Ortiz) Date: Wed, 29 Jun 2011 22:56:53 +0900 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: Alright! Let me see if I got it all straight: For our first approach, I'll do a cl-opengl-es-1.1 system which will depend on cl-opengl as is. I'll write the CFFI definitions for the egl* functions by hand. I guess I'll define the fixed-point data type by hand too. Then we see how to clean it up, if it's worth it. I'll start working this weekend. Since I still need to understand cl-opengl in more depth, this could take a while. I'll keep you posted with the progress (and troubles ;-) Thanks! -- Sim?n Ortiz B., M.Sc., Ing. en Computaci?n Linux Registered User #388735 On Wed, Jun 29, 2011 at 00:57, Lu?s Oliveira wrote: > On Tue, Jun 28, 2011 at 4:03 PM, Simon Ortiz wrote: >> From my ignorance, I would vote for loading only the relevant bits for >> ES. Given that it's going to run in a constrained environment, less >> loading is better (less memory consumption, faster loading time... >> although the difference in both could be dismissible). Plus, it might >> be safer. Would ugly things happen if you call a function defined in >> cl-opengl that isn't in OpenGL ES 1.1? > > I thing you'd simply get an undefined function error from CFFI. > > >> I have some questions about the cl-opengl-base approach: would it >> require subtracting the common bits from the spec for cl-opengl? Or >> would the common bits be overwritten in cl-opengl? > > The former seems cleaner. > > >> Would the cl-opengl-base approach scale nicely? Let's say we want to >> add ES 2.0, do we revise cl-opengl-base so that it is the intersection >> of functions in OpenGL 4.1, OpenGL ES 1.1 and OpenGL ES 2.0? Would >> this also be necessary if someone wanted to add WebGL, and when a new >> version of OpenGL is released? > > Not sure about nicely, but I suppose you could have a > cl-opengl-base-1.1, cl-opengl-base-2.0, etc. If one's going to think > about a layout like this in depth, it'd be interesting to take OpenGL > profiles into account too. > > >> I guess the other approach would be to have independent systems. > > However, we most certainly want to avoid duplication on the GL package > since that package contains high-level abstractions that aren't > automatically generated. > > >> Yes, it's a shame ES doesn't have a spec file. If we take the >> independent system route, we could start from the spec of OpenGL 1.5 >> and remove the functions that aren't in ES 1.1. >> >> As Lu?s says, the egl* functions are few. Maybe we could also add them >> by hand to the ES 1.1 spec file. > > I don't think adding them to the spec file is worth the trouble. > Writing the CFFI definitions by hand is probably much simpler. I > suggest you create a cl-opengl-es-1.1 system, make it depend on > cl-opengl and add the egl functions to a new EGL package. > > We can then tackle the cl-opengl-base issue if it's worth the trouble. > > Cheers, > > -- > Lu?s Oliveira > http://r42.eu/~luis/ > From luismbo at gmail.com Wed Jun 29 14:10:17 2011 From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=) Date: Wed, 29 Jun 2011 15:10:17 +0100 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: On Wed, Jun 29, 2011 at 2:56 PM, Simon Ortiz wrote: > For our first approach, I'll do a cl-opengl-es-1.1 system which will > depend on cl-opengl as is. I'll write the CFFI definitions for the > egl* functions by hand. I guess I'll define the fixed-point data type > by hand too. > > Then we see how to clean it up, if it's worth it. Yes, that's my suggestion. > I'll start working this weekend. Since I still need to understand > cl-opengl in more depth, this could take a while. > > I'll keep you posted with the progress (and troubles ;-) Cool, definitely keep us posted. Cheers, -- Lu?s Oliveira http://r42.eu/~luis/ From 00003b at gmail.com Wed Jun 29 14:31:43 2011 From: 00003b at gmail.com (Bart Botta) Date: Wed, 29 Jun 2011 09:31:43 -0500 Subject: [cl-opengl-devel] CL-OpenGL ES? In-Reply-To: References: Message-ID: On Wed, Jun 29, 2011 at 9:10 AM, Lu?s Oliveira wrote: > On Wed, Jun 29, 2011 at 2:56 PM, Simon Ortiz wrote: >> For our first approach, I'll do a cl-opengl-es-1.1 system which will >> depend on cl-opengl as is. I'll write the CFFI definitions for the >> egl* functions by hand. I guess I'll define the fixed-point data type >> by hand too. >> > Yes, that's my suggestion. If I understand correctly, EGL is something like glx/wgl/etc, and isn't actually part of OpenGL ES itself, so I'd probably lean towards a separate cl-egl system containing just the EGL parts. If ES 1.x only adds data types, I'd probably include them in the main cl-opengl for now. If there are conflicting function signatures or enums things would be more complicated... not sure what the best solution for that would be. -b-