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
Hello,
On Sat, Jun 25, 2011 at 10:55 AM, Simon Ortiz o.simon@gmail.com 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,
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 luismbo@gmail.com wrote:
Hello,
On Sat, Jun 25, 2011 at 10:55 AM, Simon Ortiz o.simon@gmail.com 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/
On Mon, Jun 27, 2011 at 2:46 PM, Simon Ortiz o.simon@gmail.com 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?
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 luismbo@gmail.com wrote:
On Mon, Jun 27, 2011 at 2:46 PM, Simon Ortiz o.simon@gmail.com 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/
On Mon, Jun 27, 2011 at 3:04 PM, Simon Ortiz o.simon@gmail.com 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.
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 luismbo@gmail.com wrote:
On Mon, Jun 27, 2011 at 3:04 PM, Simon Ortiz o.simon@gmail.com 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-
On Tue, Jun 28, 2011 at 3:35 AM, Bart Botta 00003b@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, 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 luismbo@gmail.com wrote:
On Tue, Jun 28, 2011 at 3:35 AM, Bart Botta 00003b@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/
On Tue, Jun 28, 2011 at 4:03 PM, Simon Ortiz o.simon@gmail.com 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,
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 luismbo@gmail.com wrote:
On Tue, Jun 28, 2011 at 4:03 PM, Simon Ortiz o.simon@gmail.com 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/
On Wed, Jun 29, 2011 at 2:56 PM, Simon Ortiz o.simon@gmail.com 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,
On Wed, Jun 29, 2011 at 9:10 AM, Luís Oliveira luismbo@gmail.com wrote:
On Wed, Jun 29, 2011 at 2:56 PM, Simon Ortiz o.simon@gmail.com 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-
hello,
I'm here reporting on my advance on cl-opengl-es-1.1.
I need a system with OpenGL ES 1.1 for testing. I decided to use Android. The only CL implementation I know that runs on Android is ECL.
Before jumping into cl-opengl I decided testing a simple library with CFFI. It so happens that I stumbled upon a bug with ECL+CFFI that prevents compiling libraries.
The bug has been acknowledged by the maintainer. As soon as he kindly fixes the bug, I'll continue with the project.
Cheers,
-- Simón Ortiz B., M.Sc., Ing. en Computación Linux Registered User #388735
On Wed, Jun 29, 2011 at 23:31, Bart Botta 00003b@gmail.com wrote:
On Wed, Jun 29, 2011 at 9:10 AM, Luís Oliveira luismbo@gmail.com wrote:
On Wed, Jun 29, 2011 at 2:56 PM, Simon Ortiz o.simon@gmail.com 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-
On Tue, Jul 19, 2011 at 1:14 PM, Simon Ortiz o.simon@gmail.com wrote:
I need a system with OpenGL ES 1.1 for testing. I decided to use Android. The only CL implementation I know that runs on Android is ECL.
I think Clozure CL might run there as well. Their SVN repo contains some Android references.
Before jumping into cl-opengl I decided testing a simple library with CFFI. It so happens that I stumbled upon a bug with ECL+CFFI that prevents compiling libraries.
The bug has been acknowledged by the maintainer. As soon as he kindly fixes the bug, I'll continue with the project.
Cool. Thanks for your feedback.
Great! I'll try to go with Clozure CL while I wait for ECL.
Thanks for the tip!
-- Simón Ortiz B., M.Sc., Ing. en Computación Linux Registered User #388735
On Tue, Jul 19, 2011 at 22:03, Luís Oliveira luismbo@gmail.com wrote:
On Tue, Jul 19, 2011 at 1:14 PM, Simon Ortiz o.simon@gmail.com wrote:
I need a system with OpenGL ES 1.1 for testing. I decided to use Android. The only CL implementation I know that runs on Android is ECL.
I think Clozure CL might run there as well. Their SVN repo contains some Android references.
Before jumping into cl-opengl I decided testing a simple library with CFFI. It so happens that I stumbled upon a bug with ECL+CFFI that prevents compiling libraries.
The bug has been acknowledged by the maintainer. As soon as he kindly fixes the bug, I'll continue with the project.
Cool. Thanks for your feedback.
-- Luís Oliveira http://r42.eu/~luis/
cl-opengl-devel@common-lisp.net
-
Bart Botta -
Luís Oliveira -
Simon Ortiz