5 ms·

Cool project, when you add multiplayer to a simple game without any game engine and want to actually do it right (CSP, interpolation, lag compensation) it gets

by iercan 3y ago

Cool project, when you add multiplayer to a simple game without any game engine and want to actually do it right (CSP, interpolation, lag compensation) it gets technical really fast I spent months trying to make a CS like in Three.js, then I was wondering myself if it was actually worth it I could just have used a random game engine that can export to WebGL with wasm even if the first loading was bigger, people wouldn't even notice nowadays WebGPU is coming out if I'm correct, I wonder how good will web games run now

ironbound 3y ago
Could check this out https://github.com/hexops/mach-gpu https://github.com/hexops/mach-gpu
- charcircuit 3y ago
  That's WASM based which puts it at a disadvantage to a javascript based renderer.
  - peterashford 3y ago
    Really? My understanding was that WASM support was good these days. And performance is a key issue with games
    - charcircuit 3y ago
      JavaScript will typically have better performance than WASM. WASM is good for porting existing software to the web. So if you have tens thousands of engineering hours dumped into some game engine that engine can be brought to the web instead of having to duplicate that work with a rewrite. Using javascript apis from WASM isn't possible and requires you to do extra copies. Yes, there are optimizations that browsers can do, but it's game of catch up with the performance of javascript. Or if you want to share code between a native version of the game and the web version WASM may be good. Performance should not be the reason you pick WASM.
      - peterashford 3y ago
        “Preliminary results show that WebAssembly, while still in its infancy, is starting to already outperform JavaScript, with much more room to grow,” https://thenewstack.io/javascript-vs-wasm-which-is-more-energy-efficient-and-faster/ https://thenewstack.io/javascript-vs-wasm-which-is-more-ener...
        charcircuit 3y ago
        I would like to see this done with JavaScript that is an actual game or application. A gameboy emulator is a virtual machine and is not heavy on IPC with the DOM. Measuring a C++ program compiled into JavaScript (C virtual machine) doesn't seem representative either. The paper more shows that if you are building a virtual machine in the browser you should use WASM. I agree that is a sensible choice.
        flohofwoe 3y ago
        The calling overhead from WASM into JS in order to talk to browser APIs is usually negligible compared to the actual cost of the called function. Also see this article from 2018: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a... Quote: "calls between JS and WebAssembly are faster than non-inlined JS to JS function calls"
        charcircuit 3y ago
        The problem is that these function only work with numbers. If you are trying to use functions that take or return objects or strings you start running into trouble. So either you end up making a JavaScript engine that does all of the heavy work in regards to interfacing with the browser (including APIs like webgpu) or you come up with some serialization scheme to allow for wasm to work with these functions. My point is that if you are making a big chunk of JavaScript already there is a benefit to just doing most of everything else with JavaScript if you can get away with it. I'm not trying to claim that in all circumstances WASM will be slower and I will encourage people to check for themselves, but I will stand behind the claim that performance should not be the reason you choose to make your web application with WASM.

by iercan 3y ago

ironbound 3y ago

Could check this out https://github.com/hexops/mach-gpu https://github.com/hexops/mach-gpu

charcircuit 3y ago
That's WASM based which puts it at a disadvantage to a javascript based renderer.
- peterashford 3y ago
  Really? My understanding was that WASM support was good these days. And performance is a key issue with games
  - charcircuit 3y ago
    JavaScript will typically have better performance than WASM. WASM is good for porting existing software to the web. So if you have tens thousands of engineering hours dumped into some game engine that engine can be brought to the web instead of having to duplicate that work with a rewrite. Using javascript apis from WASM isn't possible and requires you to do extra copies. Yes, there are optimizations that browsers can do, but it's game of catch up with the performance of javascript. Or if you want to share code between a native version of the game and the web version WASM may be good. Performance should not be the reason you pick WASM.
    - peterashford 3y ago
      “Preliminary results show that WebAssembly, while still in its infancy, is starting to already outperform JavaScript, with much more room to grow,” https://thenewstack.io/javascript-vs-wasm-which-is-more-energy-efficient-and-faster/ https://thenewstack.io/javascript-vs-wasm-which-is-more-ener...
      - charcircuit 3y ago
        I would like to see this done with JavaScript that is an actual game or application. A gameboy emulator is a virtual machine and is not heavy on IPC with the DOM. Measuring a C++ program compiled into JavaScript (C virtual machine) doesn't seem representative either. The paper more shows that if you are building a virtual machine in the browser you should use WASM. I agree that is a sensible choice.
        flohofwoe 3y ago
        The calling overhead from WASM into JS in order to talk to browser APIs is usually negligible compared to the actual cost of the called function. Also see this article from 2018: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a... Quote: "calls between JS and WebAssembly are faster than non-inlined JS to JS function calls"
        charcircuit 3y ago
        The problem is that these function only work with numbers. If you are trying to use functions that take or return objects or strings you start running into trouble. So either you end up making a JavaScript engine that does all of the heavy work in regards to interfacing with the browser (including APIs like webgpu) or you come up with some serialization scheme to allow for wasm to work with these functions. My point is that if you are making a big chunk of JavaScript already there is a benefit to just doing most of everything else with JavaScript if you can get away with it. I'm not trying to claim that in all circumstances WASM will be slower and I will encourage people to check for themselves, but I will stand behind the claim that performance should not be the reason you choose to make your web application with WASM.