5 ms·

Very nice. I like these tutorials showing the nuts and bolts of wasm and C without just throwing it at emscripten toolchain. I'm curious if there's perf diffe

Very nice. I like these tutorials showing the nuts and bolts of wasm and C without just throwing it at emscripten toolchain. I'm curious if there's perf differences between canvas and webgl canvas. This project uses just canvas, but iirc passing frames to be rendered by webgl is faster. Perhaps I'm wrong in this context. I also don't see threading in here. Makes sense for a demo, but if this were to be used performantly you'd have to throw it all in a webworker so it doesn't block the main thread. This is one point of contention with wasm because it's not straightforward to render to a canvas/webgl on the main thread from a worker thread. OffscreenCanvas is one workaround but not supported by FF or safari.

djhworld 5y ago
There's also the problem of getting keyboard input in and out of the web worker in a performant manner. I tried this a few years ago with a Gameboy emulator I had ported from Go to webassembly and used web workers to run the emulator in. Getting the keyboard input in, in a performant way was a real struggle using postMessage, although I'll admit I'm not the best at web programming so someone more skilled might have been able to do it better
- asiachick 5y ago
  You could pass it via a SharedArrayBuffer
  - plopz 5y ago
    From what I found on MDN "a side effect to the block in one agent will eventually become visible in the other agent", what does the word eventually mean there, what's going on under the hood?
    - Dylan16807 5y ago
      Should just be nanoseconds. I think they're mostly making considerations for unfortunate thread scheduling where one gets stuck for a while.
- deleted 5y ago
  [deleted]
- sitkack 5y ago
  Why this arch over having the UI run in the main thread and sending events into the wasm worker?
  - devwastaken 5y ago
    The web worker where wasm is running in would be the one that handles the whole game, and the game has to be told the inputs. Inputs are only grab able on the main thread, and rendering is only done on the main thread. If you run the game in the main thread too you can end up with your browser tab becoming unresponsive, or have delays in the input and rendering that affect the games performance. It's the same as when you make a python UI all in one thread, you can't receive user input and also do some long task at the same time.
  - djhworld 5y ago
    I'd ported the emulator to WASM from one I'd half written a few years previously, and engineered myself into a corner (+ like I said, not a web programmer) The emulator ran in the worker, and the inputs were handled on the main thread. The output (i.e. display) was pushed from the worker -> main thread I think if I was to do it from scratch I'd do something similar to the DooM approach here and use renderAnimationFrame etc If you're interested I wrote about it a few years ago but haven't touch it since https://djharper.dev/post/2018/09/21/i-ported-my-gameboy-color-emulator-to-webassembly/ https://djharper.dev/post/2018/09/21/i-ported-my-gameboy-col...
- musicale 5y ago
  Do you mean that keyboard input into a web worker is too slow, or it uses too much memory or cpu or power or ??? How is keyboard input different from any other sort of data round trip to/from a web worker?
pjmlp 5y ago
Pity that WebAssembly Studio development seems to have stalled. https://webassembly.studio/ https://webassembly.studio/ It is the easiest way to get into WASM. Threading requires sending custom headers by the way.
- dQw4w9WgXcQ 5y ago
  Any thoughts on how you could revive it?
  - pjmlp 5y ago
    By having someone to pay me a proper salary. I don't do charity.
throw_m239339 5y ago
Seems to me the original rendering pipeline wasn't GPU based. The author is just dumping whatever the game renders in a canvas element, there is no need for webgl for that. Also Canvas is getting some GPU acceleration in some browsers: https://developers.google.com/web/updates/2012/07/Taking-advantage-of-GPU-acceleration-in-the-2D-canvas https://developers.google.com/web/updates/2012/07/Taking-adv...
- westoncb 5y ago
  GP was asking whether it would be more performant to do via webgl though. (It's already known that canvas is currently used) My bet is that webgl probably would be, but I'd also be curious to hear from someone with more info. Seems to basically come down to whether canvas of webgl does a more efficient version of some kind of memory copy onto the GPU side.
- pjmlp 5y ago
  Usually canvas hardware acceleration is not taken advantage of unless you do CSS tricks like setting an element with another depth order. https://www.programmersought.com/article/58016098343/ https://www.programmersought.com/article/58016098343/ In any case, given how browsers black list drivers and GPU models, even WebGL isn't guaranteed to be accelerated. With these constrains the Web will never be as fast as native for graphics programming. They took us Flash away, but forgot to ensure the same capabilities were kept.
  - deleted 5y ago
    [deleted]
pjc50 5y ago
Given that > Doom has a global variable screens[0] which is a byte array of SCREENWIDTH*SCREENHEIGHT, i.e. 320x200 with the current screen contents. It would seem to me that the right approach would be to hoist out Doom's main loop so you just have a renderFrame() function, then put something on the main browser thread to "blit" the image into the canvas itself.
- dividuum 5y ago
  As you wrote "the right approach would be", I'll add: That's exactly what the code does.

djhworld 5y ago

There's also the problem of getting keyboard input in and out of the web worker in a performant manner. I tried this a few years ago with a Gameboy emulator I had ported from Go to webassembly and used web workers to run the emulator in. Getting the keyboard input in, in a performant way was a real struggle using postMessage, although I'll admit I'm not the best at web programming so someone more skilled might have been able to do it better

asiachick 5y ago
You could pass it via a SharedArrayBuffer
- plopz 5y ago
  From what I found on MDN "a side effect to the block in one agent will eventually become visible in the other agent", what does the word eventually mean there, what's going on under the hood?
  - Dylan16807 5y ago
    Should just be nanoseconds. I think they're mostly making considerations for unfortunate thread scheduling where one gets stuck for a while.
deleted 5y ago
[deleted]
sitkack 5y ago
Why this arch over having the UI run in the main thread and sending events into the wasm worker?
- devwastaken 5y ago
  The web worker where wasm is running in would be the one that handles the whole game, and the game has to be told the inputs. Inputs are only grab able on the main thread, and rendering is only done on the main thread. If you run the game in the main thread too you can end up with your browser tab becoming unresponsive, or have delays in the input and rendering that affect the games performance. It's the same as when you make a python UI all in one thread, you can't receive user input and also do some long task at the same time.
- djhworld 5y ago
  I'd ported the emulator to WASM from one I'd half written a few years previously, and engineered myself into a corner (+ like I said, not a web programmer) The emulator ran in the worker, and the inputs were handled on the main thread. The output (i.e. display) was pushed from the worker -> main thread I think if I was to do it from scratch I'd do something similar to the DooM approach here and use renderAnimationFrame etc If you're interested I wrote about it a few years ago but haven't touch it since https://djharper.dev/post/2018/09/21/i-ported-my-gameboy-color-emulator-to-webassembly/ https://djharper.dev/post/2018/09/21/i-ported-my-gameboy-col...
musicale 5y ago
Do you mean that keyboard input into a web worker is too slow, or it uses too much memory or cpu or power or ??? How is keyboard input different from any other sort of data round trip to/from a web worker?

pjmlp 5y ago

Pity that WebAssembly Studio development seems to have stalled. https://webassembly.studio/ https://webassembly.studio/ It is the easiest way to get into WASM. Threading requires sending custom headers by the way.

dQw4w9WgXcQ 5y ago
Any thoughts on how you could revive it?
- pjmlp 5y ago
  By having someone to pay me a proper salary. I don't do charity.

throw_m239339 5y ago

Seems to me the original rendering pipeline wasn't GPU based. The author is just dumping whatever the game renders in a canvas element, there is no need for webgl for that. Also Canvas is getting some GPU acceleration in some browsers: https://developers.google.com/web/updates/2012/07/Taking-advantage-of-GPU-acceleration-in-the-2D-canvas https://developers.google.com/web/updates/2012/07/Taking-adv...

westoncb 5y ago
GP was asking whether it would be more performant to do via webgl though. (It's already known that canvas is currently used) My bet is that webgl probably would be, but I'd also be curious to hear from someone with more info. Seems to basically come down to whether canvas of webgl does a more efficient version of some kind of memory copy onto the GPU side.
pjmlp 5y ago
Usually canvas hardware acceleration is not taken advantage of unless you do CSS tricks like setting an element with another depth order. https://www.programmersought.com/article/58016098343/ https://www.programmersought.com/article/58016098343/ In any case, given how browsers black list drivers and GPU models, even WebGL isn't guaranteed to be accelerated. With these constrains the Web will never be as fast as native for graphics programming. They took us Flash away, but forgot to ensure the same capabilities were kept.
- deleted 5y ago
  [deleted]

pjc50 5y ago

Given that > Doom has a global variable screens[0] which is a byte array of SCREENWIDTH*SCREENHEIGHT, i.e. 320x200 with the current screen contents. It would seem to me that the right approach would be to hoist out Doom's main loop so you just have a renderFrame() function, then put something on the main browser thread to "blit" the image into the canvas itself.

dividuum 5y ago
As you wrote "the right approach would be", I'll add: That's exactly what the code does.