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

Eric Gade eric.gade at gmail.com
Thu Mar 12 13:28:33 UTC 2020


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/d959ce6e/attachment.html>


More information about the Squeak-dev mailing list