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

Bert Freudenberg bert at freudenbergs.de
Thu Mar 12 20:22:00 UTC 2020


Let's not derail this.

If the point is to get Croquet working on a 64 bit VM, then none of this is
relevant.

The only thing that needs to happen is making the old, but still very
functional and efficient enough OpenGL bindings work.

- Bert -


On Thu, Mar 12, 2020 at 6:28 AM Eric Gade <eric.gade at gmail.com> wrote:

> 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 <pbpublist at gmail.com> wrote:
>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Eric
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200312/30a1a7fc/attachment.html>


More information about the Squeak-dev mailing list