Hi all, I'm pleased to announce, that the experimental version of Open Croquet for Squeak (https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/) is now updated to the recent Squeak 5.2 (32bit). This update includes critical FIX for the Croquet's IslandReader, which is related to the new Squeak image segment loader code. The included Croquet demos have become usable in network scenarios, but with some requirements: For replication to work, a participant must run a Master of the selected demo at least once on its image (for example doing: CroquetMaster new openInWorld). Then that participant could connect to any running Master on a network (for example doing: CroquetParticipant new openInWorld). In the future updates this will be fixed. Preloaded images: - All-In-One Squeak 5.2 VM with preloaded Open Croquet image and content: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-All-in-One-Croquet.zip - Only Squeak 5.2 with image with preloaded Open Croquet: - Only content (Textures, Models, etc.): https://www.krestianstvo.org/sdk/croquet/Content.zip Loading manually: (Installer fromUrl: 'http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.3.mcm') install. Don't forget to download and extract 'Only content' package to /Contents/Resources/ folder. How to use it on the network: If Master wanted to be discoverable, it's network address must be specified here: CroquetHarness dispatcherAddress. Participant should specify a Master's network address here: CroquetHarness defaultBroadcaster. Here is the screenshot of one Master (on macOS) and two Participants (on Windows and macOS) collaborating together. Best reagards, Nikolai |
*** Great! ***
Thank you, Nikolai. :) Best, Robert > On 26. Oct 2018, at 04:47, Nikolay Suslov <[hidden email]> wrote: > > Hi all, > > I'm pleased to announce, that the experimental version of Open Croquet for Squeak (https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/) is now updated to the recent Squeak 5.2 (32bit). > This update includes critical FIX for the Croquet's IslandReader, which is related to the new Squeak image segment loader code. > The included Croquet demos have become usable in network scenarios, but with some requirements: For replication to work, a participant must run a Master of the selected demo at least once on its image (for example doing: CroquetMaster new openInWorld). Then that participant could connect to any running Master on a network (for example doing: CroquetParticipant new openInWorld). In the future updates this will be fixed. > > Preloaded images: > > - All-In-One Squeak 5.2 VM with preloaded Open Croquet image and content: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-All-in-One-Croquet.zip > > - Only Squeak 5.2 with image with preloaded Open Croquet: > https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-Croquet-Image.zip > > - Only content (Textures, Models, etc.): https://www.krestianstvo.org/sdk/croquet/Content.zip > > Loading manually: > > (Installer fromUrl: 'http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.3.mcm') install. > Don't forget to download and extract 'Only content' package to /Contents/Resources/ folder. > > How to use it on the network: > > If Master wanted to be discoverable, it's network address must be specified here: > CroquetHarness dispatcherAddress. > Participant should specify a Master's network address here: > CroquetHarness defaultBroadcaster. > > Here is the screenshot of one Master (on macOS) and two Participants (on Windows and macOS) collaborating together. > > <Screenshot-croquet.jpg> > > Best reagards, > Nikolai > |
In reply to this post by Nikolay Suslov
One of Squeak's coolest projects ever, thanks Nikolay! One question, sorry I didn't try but will it work in 64-bit Squeak and, if not, why not and when will it? Thanks! On Thu, Oct 25, 2018 at 9:47 PM Nikolay Suslov <[hidden email]> wrote:
|
In reply to this post by Nikolay Suslov
Hi Nikolay,
|
Hello Eliot, I am very inspired by the new Squeak 5.2 VM and its amazing speed! Just dreaming of having Open Croquet working on it. And now after first early steps of porting from Squeak 4.x, even without formal tests, it is seen how much faster Open Croquet demos are working. On Sat, Oct 27, 2018 at 7:48 PM Eliot Miranda <[hidden email]> wrote:
Actually, this fix is in adapting the IslandReader segment loading methods to the new behaviour of '#primitiveLoadSegmentFrom: segmentWordArray outPointers: outPointerArray': "Upon successful completion, the wordArray will have been becomed into anArray of the loaded objects." In original Open Croquet for Squeak 4.x, 'IslandReader>>#loadSegmentFromData: segmentWordArray outPointers: outPointerArray' traversing the loaded WordArrayForSegment with #nextObject for post-sending startUp message to objects ('#startUpInIslandReader: reader'). But, in Squeak 5.2 it should uses an array of the loaded objects, instead WordArrayForSegment object. That's it. Best regards, Nikolai
|
Trying this out on a Raspberry Pi (obviously).
First major problem is that OGLUnix>>openGLLibraryName ^Smalltalk osVersion = 'linux' ifTrue: ['libGL.so.1'] ifFalse: ['GL'] has a #'' (apparently a ByteSymbol with just char value 0 in it) at the end of the method ; which of course a BlockClosure does not understand. After 'fixing' that it goes on a little until we get to OpenGL>>#glMatrixMode: glMatrixMode: mode "This method was automatically generated." "void glMatrixMode(GLenum mode);" <apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'> ^self externalCallFailed The" module: '#openGLLibraryName'>" looks a bit odd to me... shouldn't that have been recompiled to use the real library name? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Trancelators interpret messages from the dead |
In reply to this post by Chris Muller-3
Hello Chris, On Fri, Oct 26, 2018 at 9:27 PM Chris Muller <[hidden email]> wrote:
Yes, actually it should. I just have updated Open Croquet integration with support of SmallFloat64 class, which is used by default on 64 bit Squeak. I have tested this on Windows'10 with http://files.squeak.org/5.2/Squeak5.2-18225-64bit/Squeak5.2-18225-64bit-201810190412-Windows.zip and Croquet works. Don't forget to enable B3DXUsesOpenGL=1 in Squeak.ini for OpenGL. Here is the preloaded 64 bit image: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-64bit-Croquet-Image.zip or do (Installer fromUrl: 'http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.4.mcm') install. As for macOS, there is seems to be a problem with the B3DAcceleratorPlugin for 64 bit, which constantly craches the VM. May be somebody had a success of running B3DAcceleratorPlugin with OpenGL on 64 bit Squeak for macOS? Best regards, Nikolai
|
In reply to this post by Nikolay Suslov
Hi Nikolay,
On Sat, Oct 27, 2018 at 3:42 PM Nikolay Suslov <[hidden email]> wrote:
Ah, that's *great* to hear! Any quantitive info appreciated when you have it. For example, knowing what's happened to frame rates would be good. But more interesting, and perhaps more difficult, is discovering precisely what activities in Open Croquet are affected and by how much.
Ah, good; that makes perfect sense. Thanks!
_,,,^..^,,,_ best, Eliot |
In reply to this post by timrowledge
On Sat, Oct 27, 2018 at 4:42 PM tim Rowledge <[hidden email]> wrote: Trying this out on a Raspberry Pi (obviously). Yes, but it doesn't change the source code. Follow the senders of openGLLibraryName to see the magic. - Bert - |
> On 2018-10-29, at 12:26 PM, Bert Freudenberg <[hidden email]> wrote: > > On Sat, Oct 27, 2018 at 4:42 PM tim Rowledge <[hidden email]> wrote: > Trying this out on a Raspberry Pi (obviously). > First major problem is that > > OGLUnix>>openGLLibraryName > ^Smalltalk osVersion = 'linux' > ifTrue: ['libGL.so.1'] > ifFalse: ['GL'] It's actually a bit worse - the osVersion returned by Raspbian is 'linux-gnu' - so I tried changing that to openGLLibraryName ^(Smalltalk osVersion beginsWith: 'linux') ifTrue: ['libGL.so.1'] ifFalse: ['GL'] which got a bit further. > has a #'' (apparently a ByteSymbol with just char value 0 in it) at the end of the method ; which of course a BlockClosure does not understand. > [snip] > > The" module: '#openGLLibraryName'>" looks a bit odd to me... shouldn't that have been recompiled to use the real library name? > > Yes, but it doesn't change the source code. Follow the senders of openGLLibraryName to see the magic. OK, so it's supposed to send #openGLLibraryName at some startup point. Very clever. Unfortunately it appears something else goes wrong pretty quickly and OGLExtManager>>#loadExtension: uses glExtGetProcAddress: which even decompiled says <cdecl: ulong 'glXGetProcAddressARB' (char*) module: 'GL'> Which doesn't seem right. Should it also use the #openGLLibraryName thing? I'd love to see this working on a Pi but I'm going to need help with anything to do with making the opengl trickery work. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: FD: Failsafe Disarmed |
On Mon, Oct 29, 2018 at 5:49 PM tim Rowledge <[hidden email]> wrote:
Yep, in OpenGL>>initialize it calls "self privateInstallLibrary: self openGLLibraryName." which patches the library name into all compiled FFI methods. Unfortunately it appears something else goes wrong pretty quickly and OGLExtManager>>#loadExtension: uses glExtGetProcAddress: which even decompiled says Ah, that seems to be an actual bug. #privateInstallLibrary: does not go into the subclasses. In OGLWin32, that method has the correct 'opengl32.dll' module. OGLMacOSX uses a different mechanism entirely. And OGLUnix relies on "GL" linking to the right thing. So I'd say in privateInstallLibrary: we need to patch both OpenGL and OGLUnix. - Bert - |
Free forum by Nabble | Edit this page |