porting Croquet to Squeak6.0 alpha...

btw, the glMatrixMode:mode method tells us that it was automatically generated.

by what? When? against what?

glMatrixMode: mode

"This method was automatically generated."

"void glMatrixMode(GLenum mode);"

<apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'>

^self externalCallFailed

Is that "automatic generation"  an example of fundamental work that must be done to make Croquet rock-n-roll?

cheers,

tty

Hi Phil B

Thank you.

I believe the OpenGL API calls were generated by code written by Andreas Raab 15+ years ago against the OpenGL spec files (these are files from the Khronos Group which have not been maintained for modern OpenGL releases).  When I asked about this over a decade ago, he responded indicating what I just wrote and that he no longer had the code he used to generate them.

Interesting. My current project is on XTreams-Parsing and I wonder if the knowledge gained there can be leveraged here to replicate Raab's work.

This would not be a trivial task since you'd probably have to rewrite, or at least significantly restructure, most of Croquet to make it work.

Do we want Croquet to be stuck with 1.6 openGL?

Or are there design patterns to decouple/loosely bind the Croquet app from the api calls?

First-things-first...I need to get the existing app  working, understand what Bert is communicating and then revisit this.

Recreating Raab's work strikes me as fundamentally important to the project. 

thank you for your time.

t

---- On Wed, 11 Mar 2020 19:54:14 -0400 Phil B <[hidden email]> wrote ----

As Bert indicated, it's not really relevant but since you asked...

I believe the OpenGL API calls were generated by code written by Andreas Raab 15+ years ago against the OpenGL spec files (these are files from the Khronos Group which have not been maintained for modern OpenGL releases).  When I asked about this over a decade ago, he responded indicating what I just wrote and that he no longer had the code he used to generate them.

If you were to do it again today, you would want to use the OpenGL C header files instead.  But again this is somewhat moot regarding Croquet: it's written against an ancient version of OpenGL (I believe 1.6 + extensions that get it *roughly* to 2.0 feature-wise) which most desktop drivers are still backwards compatible with.  So you can just use the calls already there.  You'd really only need to worry about regenerating the API if you wanted to update Croquet to take advantage of the latest OpenGL/features and/or run it under OpenGL ES.  This would not be a trivial task since you'd probably have to rewrite, or at least significantly restructure, most of Croquet to make it work.

On Wed, Mar 11, 2020 at 5:58 PM gettimothy via Squeak-dev <[hidden email]> wrote:

btw, the glMatrixMode:mode method tells us that it was automatically generated.

by what? When? against what?

glMatrixMode: mode

"This method was automatically generated."

"void glMatrixMode(GLenum mode);"

<apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'>

^self externalCallFailed

Is that "automatic generation"  an example of fundamental work that must be done to make Croquet rock-n-roll?

cheers,

tty

Hi all,

Just want to chime in on this briefly. If you decide to go down the Vulkan route, I don't think you need to parse header files. Khronos has conveniently created an XML file describing the API, which it itself used to generate the library's main header file in the first place. You can read about it here:

https://github.com/KhronosGroup/Vulkan-Docs/blob/master/xml/README.adoc

 

On Wed, Mar 11, 2020 at 9:51 PM Phil B <[hidden email]> wrote:

On Wed, Mar 11, 2020 at 8:52 PM gettimothy <[hidden email]> wrote:

Hi Phil B

Thank you.

I believe the OpenGL API calls were generated by code written by Andreas Raab 15+ years ago against the OpenGL spec files (these are files from the Khronos Group which have not been maintained for modern OpenGL releases).  When I asked about this over a decade ago, he responded indicating what I just wrote and that he no longer had the code he used to generate them.

Interesting. My current project is on XTreams-Parsing and I wonder if the knowledge gained there can be leveraged here to replicate Raab's work.

It's not that hard to replicate the results: it's just a matter of parsing C header files which is pretty well understood.  Take a look at the squeak-dev mailing list archives and you'll find at least a couple of people who did just that in a couple of different ways.

 

This would not be a trivial task since you'd probably have to rewrite, or at least significantly restructure, most of Croquet to make it work.

Do we want Croquet to be stuck with 1.6 openGL?

No, ideally you'd want it updated to use the latest OpenGL (and eventually migrate to something like Vulkan)... but that's easier said than done.  (i.e. it's a fair amount of work)

 

Or are there design patterns to decouple/loosely bind the Croquet app from the api calls?

Others may have different ideas, but from my experience poking around with Etoys, Croquet and later the STEPS project I believe that a rewrite is likely easier.  While the designs are reasonably clean and well done, they are very tightly coupled and, while layered, are not very modular.  I suspect that at least part of the reason for this was to maximize the performance they could squeeze out of the systems they had access to/were targeting at the time.

The approach I've taken with these projects is to pull out the parts I'm interested in and use them as a starting point.  For example, ~12 years ago I was interested in OpenGL in Squeak so I pulled it out of Croquet and ported it back to Squeak and later Cuis.  However, it took a bit of work to *just* have the OpenGL API as it was originally written to support Croquet so there were bits and pieces of Croquet woven in the code.  Just accept that it's only a starting point rather than a be-all, end-all solution. (If your experience is anything like mine was, you *will* learn a lot about FFI going through this exercise)

 

First-things-first...I need to get the existing app  working, understand what Bert is communicating and then revisit this.

Yep, get what exists running and then see what you want to do re: modernizing it.

 

Recreating Raab's work strikes me as fundamentally important to the project. 

While it would have been interesting to see how Andreas approached generating the API calls (he often wrote some pretty clever code), exactly how it was done is likely lost.  I suspect we've got the most important parts of his work in the artifacts of the various projects, including Croquet, that he was part of.

thank you for your time.

t

---- On Wed, 11 Mar 2020 19:54:14 -0400 Phil B <[hidden email]> wrote ----

As Bert indicated, it's not really relevant but since you asked...

I believe the OpenGL API calls were generated by code written by Andreas Raab 15+ years ago against the OpenGL spec files (these are files from the Khronos Group which have not been maintained for modern OpenGL releases).  When I asked about this over a decade ago, he responded indicating what I just wrote and that he no longer had the code he used to generate them.

If you were to do it again today, you would want to use the OpenGL C header files instead.  But again this is somewhat moot regarding Croquet: it's written against an ancient version of OpenGL (I believe 1.6 + extensions that get it *roughly* to 2.0 feature-wise) which most desktop drivers are still backwards compatible with.  So you can just use the calls already there.  You'd really only need to worry about regenerating the API if you wanted to update Croquet to take advantage of the latest OpenGL/features and/or run it under OpenGL ES.  This would not be a trivial task since you'd probably have to rewrite, or at least significantly restructure, most of Croquet to make it work.

On Wed, Mar 11, 2020 at 5:58 PM gettimothy via Squeak-dev <[hidden email]> wrote:

btw, the glMatrixMode:mode method tells us that it was automatically generated.

by what? When? against what?

glMatrixMode: mode

"This method was automatically generated."

"void glMatrixMode(GLenum mode);"

<apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'>

^self externalCallFailed

Is that "automatic generation"  an example of fundamental work that must be done to make Croquet rock-n-roll?

cheers,

tty

--

Eric