[ANN] Woden 2 first release for OS X and Linux
Hello, Finally I am glad to announce a first release of Woden 2. I made a hopefully simplified process for loading Woden 2 out of the box. For loading and testing Woden 2, follow the instructions at: https://github.com/ronsaldo/woden2 In this release, I am not loading the level editor by default because it depends on an outdated version of Bloc. Until I fix the dependency problem of the Level editor, it will remain unusable. Because Woden 2 requires Metal on OS X, it requires 64 bits on OS X, which can be unstable. This is tested on OS X El Capitan. I do not know whether it will work or not on OS X Sierra. Best regards, Ronie [image: Imágenes integradas 1]
Wonderful ! I will try it soon. Thanks ! Nolwenn -- View this message in context: http://forum.world.st/ANN-Woden-2-first-release-for-OS-X-and-Linux-tp4935693... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hello, I fixed several bugs with Vulkan, so now it is not crashing anymore when using the Linux NVIDIA Vulkan driver. I still have to fix the stuttering problem with Vulkam. Best regards, Ronie 2017-02-24 6:38 GMT-03:00 nolwenn <nolwenn.fournier@fr.thalesgroup.com>:
Wonderful ! I will try it soon.
Thanks !
Nolwenn
-- View this message in context: http://forum.world.st/ANN- Woden-2-first-release-for-OS-X-and-Linux-tp4935693p4935742.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Cool news. I'll try it out soon. I found this paper on Lowcode to share with other curious people... http://www.esug.org/data/ESUG2016/IWST/Papers/IWST_2016_paper_16.pdf A few questions from that...
our extended instructions do not perform run time type checking on their inputs, so they do not have the overhead associated to dynamic message lookup."
What happens if the wrong type object is passed to a lowcode method?
Unfortunately, when we did this work the 64 bits version of Spur was incomplete and in an experimental state [and we were] not able to compare the performance difference for floating point arithmetics against a Smalltalk with support for immediate floating point objects
Have you been able to do this performance comparison since the paper was written? cheers -ben On Fri, Feb 24, 2017 at 9:02 AM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
Finally I am glad to announce a first release of Woden 2. I made a hopefully simplified process for loading Woden 2 out of the box.
For loading and testing Woden 2, follow the instructions at:
https://github.com/ronsaldo/woden2
In this release, I am not loading the level editor by default because it depends on an outdated version of Bloc. Until I fix the dependency problem of the Level editor, it will remain unusable.
Because Woden 2 requires Metal on OS X, it requires 64 bits on OS X, which can be unstable. This is tested on OS X El Capitan. I do not know whether it will work or not on OS X Sierra.
Best regards, Ronie
2017-02-25 2:08 GMT-03:00 Ben Coman <btc@openinworld.com>:
What happens if the wrong type object is passed to a lowcode method?
You should get an error. A Lowcode method checks the type of its argument when called from a normal Pharo method. When calling a Lowcode method from another Lowcode method, the type check happens in compilation time. The type check of the arguments is only removed when a Lowcode method is inlined. By default, each variable has the object type, which corresponds with any normal Pharo Object.
Unfortunately, when we did this work the 64 bits version of Spur was incomplete and in an experimental state [and we were] not able to compare the performance difference for floating point arithmetics against a Smalltalk with support for immediate floating point objects
Have you been able to do this performance comparison since the paper was written?
I have not tried it. But, we now have the 64 bits Lowcode VM, which is used by Woden 2 by default on OS X. Currently I am just too lazy for doing this comparison, because there lot of more interesting things that can be done with Lowcode. Anyway, in theory most of the performance gain could be obtained from loops that need to manipulate memory pointers without bounds checks, instead of the small linear algebra that I am testing in that. I have not finished the support for the pointers in the Lowcode Opal Compiler, so I am quite sure we still are not getting all of the performance improvement that can be obtained with Lowcode. I am seriously thinking on remaking the Lowcode Opal Compiler, but using Slovim for generating more optimized code, and doing more aggressive inlining. Slovim is a LLVM style SSA intermediate representation that I am currently using for generating all of the shaders used by Woden 2. In Slovim I already have backends for SpirV, GLSL, the Metal Shader language, a x86 (and x86_64) machine code generator that I am refactoring. Now, I am only missing Lowcode backend, and we could be compiling actual C code alongside Pharo code in the near future. The only bad think about integrating C is its syntax. Because in C not everything is a expression, I do not believe it would be behave well in playground. Best regards, Ronie
This is great Ronie! I tried and it works like a charm. Impressive work! This will revive the Roassal3D project! Alexandre
On Feb 23, 2017, at 10:02 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
Finally I am glad to announce a first release of Woden 2. I made a hopefully simplified process for loading Woden 2 out of the box.
For loading and testing Woden 2, follow the instructions at:
https://github.com/ronsaldo/woden2
In this release, I am not loading the level editor by default because it depends on an outdated version of Bloc. Until I fix the dependency problem of the Level editor, it will remain unusable.
Because Woden 2 requires Metal on OS X, it requires 64 bits on OS X, which can be unstable. This is tested on OS X El Capitan. I do not know whether it will work or not on OS X Sierra.
Best regards, Ronie <Captura de pantalla 2017-02-23 a las 10.00.45 p.m..png>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello, I updated the BaselineOf, so now Woden 2 is loading the game system by default. I still have to restore the level editor and the Roassal 3D. With this update it is now possible to do the following (It requires OpenAL for the sound): map := WTGSMap loadJsonFromFileNamed: 'core-assets/maps/demos/esug-2016.json'. WTGSLevelPlayer new map: map; spawn; openInOSWindow. Best regards, Ronie [image: Imágenes integradas 1] 2017-02-26 10:10 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
This is great Ronie! I tried and it works like a charm. Impressive work!
This will revive the Roassal3D project!
Alexandre
On Feb 23, 2017, at 10:02 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
Finally I am glad to announce a first release of Woden 2. I made a hopefully simplified process for loading Woden 2 out of the box.
For loading and testing Woden 2, follow the instructions at:
https://github.com/ronsaldo/woden2
In this release, I am not loading the level editor by default because it depends on an outdated version of Bloc. Until I fix the dependency problem of the Level editor, it will remain unusable.
Because Woden 2 requires Metal on OS X, it requires 64 bits on OS X, which can be unstable. This is tested on OS X El Capitan. I do not know whether it will work or not on OS X Sierra.
Best regards, Ronie <Captura de pantalla 2017-02-23 a las 10.00.45 p.m..png>
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (4)
-
Alexandre Bergel -
Ben Coman -
nolwenn -
Ronie Salgado