Hipreme Engine is fully ported to WebAssembly

[Hipreme]

On Saturday, 4 February 2023 at 22:27:31 UTC, Johan wrote:
> On Saturday, 4 February 2023 at 20:03:04 UTC, Hipreme wrote:
>> On Saturday, 4 February 2023 at 19:04:19 UTC, ryuukk_ wrote:
>>> On Saturday, 4 February 2023 at 12:47:30 UTC, Guillaume 
>>> Piolat wrote:
>>>> On Friday, 3 February 2023 at 13:41:35 UTC, Hipreme wrote:
>>>>> ![Hipreme Engine Match3 sample game on 
>>>>> web](https://user-images.githubusercontent.com/10136262/216611608-aebcb31b-a5f3-4153-ac41-44777f19896a.png)
>>>>
>>>> This custom runtime is a most welcome development.
>>>
>>> I agree, but this is also unfortunate, one shouldn't have to 
>>> do that to target WASM, the druntime needs to be shrinked asap
>
> Can't you just `version`/`static if` out all the things in 
> druntime that WASM does not need? It is one of the strengths of 
> D to be able to do that quite easily; shrinking the druntime is 
> just a matter of writing `version() {}`. It'd be nice if you 
> can spend some time in making standard druntime more compatible 
> with WASM. Sebastian has worked on it, but it was never 
> upstreamed. Just disable most/all, and only enable things that 
> do work. We can always enable more / fix more later.
>
> -Johan

Exactly because Sebastian did that and that never got upstreamed 
that I didn't work on it. It would be pretty much plenty of time 
lost for nothing. I wasn't able to test his druntime, never 
worked on my PC. Working with a custom runtime is a lot easier to 
setup, build and run and that is what's important for me. You had 
to setup plenty of other things by using the standard runtime 
such as having cmake, make (which almost never works on windows), 
you need to know the correct build command, guarantee the version 
needed, then you needed to try and build WASI (which I always 
failed at that part) to be linked with the runtime. The custom 
runtime is just include and go.

The custom runtime was literally taking of code from upstream 
druntime and removing parts that were related to GC.
I have tried doing on the runtime a port from Newlib. But it is 
so much work and reading that kind of code is so hard (I'm 
talking about the C headers for that [I have already ported 
several other C code, the C std is complex to read]). I always 
prefer easy setup and integration over anything because I just 
want to get things finished. "But what about your code having 
collections" well duh, when someone does that, I'll just update 
my patch and get that performance upgrade for free because I 
already have a real product out. I have tried so many times to 
help out on the runtime thing, but there was just so much 
friction that I wasn't able to do so.

After Dkorpel documenting the runtime, I was finally able to 
understand what the heck was going on so I started to use that to 
incrementally build a product which I could see working. 
Unfortunately you can't do that with the runtime we have today 
(in my experience), it is 8 or 80.

Maybe the custom runtime I extended with Adam could even be a 
beginner's gateway to understand the druntime, as most of the 
code used to implement class allocation and dynamic arrays 
becomes a lot easier to understand (specially as it doesn't have 
those bizarre named variables from upstream) and that it uses 
familiar concepts such as malloc/free/realloc instead of a lot of 
the runtime specific nomenclature.