Running a D game in the browser

#1

Post by Halienja » Thu, Aug 04, 2016, 12:28 PM UTC

Running a D game in the browser
code.alaiwan.org

Re: Running a D game in the browser

#2

Post by [deleted] » Thu, Aug 04, 2016, 6:26 PM UTC

[deleted]

Re: Running a D game in the browser

#3

Post by themihai » Thu, Aug 04, 2016, 6:28 PM UTC

>An obvious enhancement would be to use the WebAssembly backend of the upstream LLVM, and then using Emscripten+Binaryen to convert the generated WebAssembly to asm.js.

why would you convert WebAssembly to asm.js?

Re: Running a D game in the browser

#4

Post by jeremiep » Thu, Aug 04, 2016, 6:52 PM UTC

themihai wrote: post #3

>An obvious enhancement would be to use the WebAssembly backend of the upstream LLVM, and then using Emscripten+Binaryen to convert the generated WebAssembly to asm.js. why would you convert WebAssembly to asm.js?

For browsers not yet supporting WebAssembly?

Re: Running a D game in the browser

#5

Post by techgineer » Thu, Aug 04, 2016, 7:24 PM UTC

Great work. 3D with WebGL is necessary for this, and I don't think you'll run into any issue.

Re: Running a D game in the browser

#6

Post by Natsu » Thu, Aug 04, 2016, 8:15 PM UTC

I must read too much manga, I was expecting this to be about Darwin's Game, rather than a game translated from D to LLVM to C to ASMJS.

Re: Running a D game in the browser

#7

Post by p0nce » Thu, Aug 04, 2016, 8:15 PM UTC

Awesome!

Re: Running a D game in the browser

#8

Post by rubber_duck » Thu, Aug 04, 2016, 8:24 PM UTC

>At the moment, I’m only targetting a tiny subset of the D programming language. The language comes with a runtime, featuring a garbage collector. It’s my first journey to the land of D-asm.js, and there’s no way I’m bringing the D runtime with me – especially if I need to port it to Javascript first.

This is basically why D is not a good systems programming language. Theoretical GC performance aside, barring a miracle, they will never have the resources to develop a high quality GC and even less chance to maintain high quality ports across relevant platforms (heck they couldn't even compile on mobile platforms until recently).

Re: Running a D game in the browser

#9

Post by themihai » Thu, Aug 04, 2016, 8:56 PM UTC

jeremiep wrote: post #4

themihai wrote: post #3

>An obvious enhancement would be to use the WebAssembly backend of the upstream LLVM, and then using Emscripten+Binaryen to convert the generated WebAssembly to asm.js. why would you convert WebAssembly to asm.js?

For browsers not yet supporting WebAssembly?

All the browsers supporting WebAssembly are evergreen browsers. I don't think asm.js is worth supporting once WebAssembly format stabilises(i.e. by the end of this year).

Re: Running a D game in the browser

#10

Post by duaneb » Thu, Aug 04, 2016, 9:12 PM UTC

rubber_duck wrote: post #8

>At the moment, I’m only targetting a tiny subset of the D programming language. The language comes with a runtime, featuring a garbage collector. It’s my first journey to the land of D-asm.js, and there’s no way I’m bringing the D runtime with me – especially if I need to port it to Javascript first. This is basically why D is not a good systems programming language. Theoretical GC performance aside, barring a mirac…

It's really hard to make a case for GC and systems (constrained latency, memory, embedded, realtime) being compatible at all. I've had some success using my own allocation pools just to avoid latency slowdowns in critical loops—functionally disabling GC for that call tree.

And I know that you can disable the GC in D, but it's hard coming up with a good use case for the language that wouldn't be fit better with another smaller, tailored language.