[squeak-dev] porting Croquet to Squeak6.0 alpha...

Phil B pbpublist at gmail.com
Thu Mar 12 01:51:23 UTC 2020


On Wed, Mar 11, 2020 at 8:52 PM gettimothy <gettimothy at zoho.com> 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 <pbpublist at gmail.com
> <pbpublist at gmail.com>>* 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 <
> squeak-dev at lists.squeakfoundation.org> 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
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200311/85ef5118/attachment.html>


More information about the Squeak-dev mailing list