| |
| Posted by Hipreme in reply to H. S. Teoh | PermalinkReply |
|
Hipreme
Posted in reply to H. S. Teoh
| On Monday, 23 January 2023 at 21:26:56 UTC, H. S. Teoh wrote:
> On Mon, Jan 23, 2023 at 08:43:03PM +0000, Adam D Ruppe via Digitalmars-d-announce wrote:
>> On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
>> > There should be a tool for auto-generating JS wrappers, perhaps even HTML snippets, so that a user literally can just write:
>> >
>> > import std; // OK, maybe import std.wasm or something
>> > void main() { writeln("Hello, world!");
>> > and get a webpage that prints that message in a browser window
>> > without writing a single line of JS or HTML.
>>
>> http://webassembly.arsdnet.net/
>>
>> Paste in
>> import std.stdio;
>> void main() { writeln("hello world"); }
>>
>> to the box on that page
>>
>> and get
>> http://webassembly.arsdnet.net/usertemp
>
> Ahahahaha... just like Adam to have already dunnit while I'm still twiddling my fingers wondering how to go about doing it. :-D Now all we need is to package your little page up into a dub package or something (personally I prefer just a tarball) and we're good to go. :-D
>
>
>> Webassembly is a trash target but like been there done that.
>
> Yeah TBH after dabbling with it a little I realized just how much it was still dependent on JS to do the heavy lifting. You can't even pass strings across the JS/WASM boundary without truckloads of JS boilerplate. The C-like API isn't officially part of the WASM standard yet, and they're still trying to figure out how GC might work. As far as I'm concerned, it's still early adopter tech, not yet stable enough for me to invest in.
>
>
>> Of course there are some caveats in what works, there have been come contributions coming in from hipreme recently to extend it a lil.
>
> Nice. Can it handle WebGL yet? I betcha that'd be the second question a newbie to D would ask after asking about WASM. :-P
>
>
> T
I was going to wait a little bit on that announcement. But yes, Hipreme Engine has already been completely ported to WASM. File loading, rendering with my abstraction, audio playing, image/audio decoding, input system, I've got pretty much everything working. WASM only changed in my engine how the file loading is handled internally. An example, It sends D delegates to JS execute when things are complete, so, there isn't anymore a sync API for loading files.
I have used arsd.cgi for making it easy to any D programmer host it with dub. I have posted on Learn like yesterday how to integrate the custom runtime with any dub project too, which is how I'm using to build for my engine.
The list of features being supported are:
- new
- string switch
- classes (inheritance and abstract included)
- interfaces
- every array operation
- every associative array operation
- RAII
- delegates and function pointers
- assertion
- throw should work. Catching don't
- RTTI (typeid and other things that depends on it)
- All the compile time features seems to be working finely
- main() and it will run as expected.
- string utf decoding
Unsupported features:
- static this/~this (should be easy to implement though, my engine has no need to do that, specially since it uses a lot of DLL for Android and Xbox and static this is quite buggy for it anyway)
- try/catch
- fibers
The problem on try/catch/fiber are the same. They need stack unwinding and from what I've looked, this implementation needs compiler developers to write a little of assembly to get this working, as I have no idea on how that works, I can't implement that.
I believe this covers like 90% the usage of one using the druntime.
I honestly don't care about throw/catch. Specially for gamedev which is my aim, the code doesn't need to "protect" from itself.
That being said, if one is not using Hipreme Engine and is using a lot of standard library, this one would need to implement a lot of it. Hipreme Engine implements a minimal phobos (as I don't implement the entire libc) for being used. Needless to say, some modules from phobos didn't need to adapt to WASM, so, `std.algorithm` and `std.traits` are being used from upstream.
std.math was possible to copy/paste without too much work to do (A matter of 5 lines I think).
I'm also using arsd.ttf to runtime create text textures, a library which does not uses any of my modules, no bug was found on it, so, this is mostly a matter of giving a little of effort and everything can be done.
|