6 ms·

What I'm most excited about is the potential for WebAssembly (along with WebGPU) to pave the way for a whole new era of browser games and provide an alternative

What I'm most excited about is the potential for WebAssembly (along with WebGPU) to pave the way for a whole new era of browser games and provide an alternative to developers who don't want to fork over 30% to walled gardens. My team has built out WASM/WebGPU support for Unreal Engine 4 and is in progress for Unreal Engine 5 (and other engines) with a suite of optimization tools like asset streaming (so you don't have to download a whole game at once) and advanced texture compression (necessary for low powered devices like mobile/Chromebooks). More info on us in this Venturebeat article we were featured in: https://venturebeat.com/2022/05/12/wonder-interactives-the-immersive-web-will-play-unreal-4-games-on-the-web/ https://venturebeat.com/2022/05/12/wonder-interactives-the-i...

Etherlord87 4y ago
What is the minimum weight of an UE4 project compiled to WASM? The article says something about a menu being 10 MB, but is that a menu done in UE4 or just something else and somehow connected with an actual game? To my knowledge an unreal executable weight at minimum around 80 MB? That would compare poorly to Godot which is very light in comparison...
slimsag 4y ago
Was watching your update in the Khronos Group meetup a few days ago, very impressive work. I'm excited for what this will mean for the web overall, it might finally reach that tipping point where more than .io games become standard to play in the web. That's huge, and will drive demand for more powerful web APIs too. WebGPU in general is very nice. We're building a game engine[0] that uses Zig to build Dawn (Google Chrome WebGPU implementation) from source for running on desktop / Steamdeck, and working on browser support via WASM now. The future is bright here. [0] https://machengine.org https://machengine.org
Animats 4y ago
What do you do about WebAssembly's lack of real threads?
- cylon13 4y ago
  With shared array buffers it’s not actually a big problem. We’re building a multithreaded game that targets wasm and we just spin up workers up front which all use the same shared memory, and then just use standard concurrency primitives to schedule work on them. Just have to be careful not to block on the main thread, and you have to serve all your assets from the same domain for browsers to allow you to make shared array buffers.
  - Animats 4y ago
    That's very helpful. Thanks.
- modeless 4y ago
  It has real threads now, doesn't it? SharedArrayBuffer was reenabled in all browsers.
  - Animats 4y ago
    Sort of. It's more like processes with shared memory.
    - modeless 4y ago
      Emscripten has pthreads support. Maybe it's not perfect but it seems like a lot more than processes with shared memory to me.
atwood22 4y ago
Most game engine's don't require you to download the entire game at once. Loading assets dynamically is always an option. However, it's pretty nice to be able to do something like `engine.getAsset("blah")` and have it immediately return you something.
redox99 4y ago
What is currently the FPS hit of running the UE4 game on a web browser vs natively? And is the stutter issue that plagues anything 3d in the browser, solved?
pjmlp 4y ago
Those 30% walled gardens enjoy 2022 3D APIs for 2022 hardware, with great development experience, while WebGPU if it still comes out this year, will be MVP 1.0 after several years trying to make everyone agree into something, and still doesn't have a debugging story.
- slimsag 4y ago
  What would you like to see instead, everyone stick with WebGL? Expose Vulkan directly to the web with a "this is dangerous" prompt? Go with WebGPU+SPIRV, but have no Apple support?
  - pjmlp 4y ago
    It is already dangerous anyway, as you have no control over driver bugs handling shader code. As for blaming Apple, the reason why WebGL 2.0 lost compute shaders, a GL ES feature from 2014 (!), was because Google dropped it from Chrome after two failed attempts from Intel to bring it, as WebGPU was just around the corner, two years ago! This is what happens with committee APIs, everyone messes up and we end up stuck with MVPs forever. As for what we are getting instead, it is quite clear from console vendors, server side rendering with pixel streaming.
    - slimsag 4y ago
      It sounds to me like you're saying: (a) WebGPU could be dangerous anyway, so why not just expose Vulkan entirely with no safety? (b) Committee-designed APIs are always doomed to fail, equally Google/Apple/Intel's fault, they won't ever ship a non-MVP anyway, 'so why bother' I presume? (c) Console vendors are pushing server-side rendering pixel streaming too, so we won't have any control over our devices ultimately in the future anyway - so none of this matters. If those are the arguments, I'd rather have WebGPU than not have it, personally.
      - pjmlp 4y ago
        You misread (C), server side rendering is the only way we will ever have modern 3D APIs on the Web. Looking forward to WebGPU support on ShaderToy, pity we will have to rewrite all shaders to Rust flavoured WGSL.
viktorcode 4y ago
Does WASM support SIMD?
- jsheard 4y ago
  Yes, in a limited form since it sticks to the lowest common denominator that can be implemented across most popular CPUs with decent performance and while producing consistent results. There's a follow-up proposal in progress to relax the "consistent results" part and allow for some slight precision wiggle room with instructions that couldn't be implemented otherwise (e.g. they could add an FMA instruction that compiles to native FMA where available or separate MUL-ADD otherwise, even though they won't produce exactly the same results).

Etherlord87 4y ago

What is the minimum weight of an UE4 project compiled to WASM? The article says something about a menu being 10 MB, but is that a menu done in UE4 or just something else and somehow connected with an actual game? To my knowledge an unreal executable weight at minimum around 80 MB? That would compare poorly to Godot which is very light in comparison...

slimsag 4y ago

Was watching your update in the Khronos Group meetup a few days ago, very impressive work. I'm excited for what this will mean for the web overall, it might finally reach that tipping point where more than .io games become standard to play in the web. That's huge, and will drive demand for more powerful web APIs too. WebGPU in general is very nice. We're building a game engine[0] that uses Zig to build Dawn (Google Chrome WebGPU implementation) from source for running on desktop / Steamdeck, and working on browser support via WASM now. The future is bright here. [0] https://machengine.org https://machengine.org

Animats 4y ago

What do you do about WebAssembly's lack of real threads?

cylon13 4y ago
With shared array buffers it’s not actually a big problem. We’re building a multithreaded game that targets wasm and we just spin up workers up front which all use the same shared memory, and then just use standard concurrency primitives to schedule work on them. Just have to be careful not to block on the main thread, and you have to serve all your assets from the same domain for browsers to allow you to make shared array buffers.
- Animats 4y ago
  That's very helpful. Thanks.
modeless 4y ago
It has real threads now, doesn't it? SharedArrayBuffer was reenabled in all browsers.
- Animats 4y ago
  Sort of. It's more like processes with shared memory.
  - modeless 4y ago
    Emscripten has pthreads support. Maybe it's not perfect but it seems like a lot more than processes with shared memory to me.

atwood22 4y ago

Most game engine's don't require you to download the entire game at once. Loading assets dynamically is always an option. However, it's pretty nice to be able to do something like `engine.getAsset("blah")` and have it immediately return you something.

redox99 4y ago

What is currently the FPS hit of running the UE4 game on a web browser vs natively? And is the stutter issue that plagues anything 3d in the browser, solved?

pjmlp 4y ago

Those 30% walled gardens enjoy 2022 3D APIs for 2022 hardware, with great development experience, while WebGPU if it still comes out this year, will be MVP 1.0 after several years trying to make everyone agree into something, and still doesn't have a debugging story.

slimsag 4y ago
What would you like to see instead, everyone stick with WebGL? Expose Vulkan directly to the web with a "this is dangerous" prompt? Go with WebGPU+SPIRV, but have no Apple support?
- pjmlp 4y ago
  It is already dangerous anyway, as you have no control over driver bugs handling shader code. As for blaming Apple, the reason why WebGL 2.0 lost compute shaders, a GL ES feature from 2014 (!), was because Google dropped it from Chrome after two failed attempts from Intel to bring it, as WebGPU was just around the corner, two years ago! This is what happens with committee APIs, everyone messes up and we end up stuck with MVPs forever. As for what we are getting instead, it is quite clear from console vendors, server side rendering with pixel streaming.
  - slimsag 4y ago
    It sounds to me like you're saying: (a) WebGPU could be dangerous anyway, so why not just expose Vulkan entirely with no safety? (b) Committee-designed APIs are always doomed to fail, equally Google/Apple/Intel's fault, they won't ever ship a non-MVP anyway, 'so why bother' I presume? (c) Console vendors are pushing server-side rendering pixel streaming too, so we won't have any control over our devices ultimately in the future anyway - so none of this matters. If those are the arguments, I'd rather have WebGPU than not have it, personally.
    - pjmlp 4y ago
      You misread (C), server side rendering is the only way we will ever have modern 3D APIs on the Web. Looking forward to WebGPU support on ShaderToy, pity we will have to rewrite all shaders to Rust flavoured WGSL.

viktorcode 4y ago

Does WASM support SIMD?

jsheard 4y ago
Yes, in a limited form since it sticks to the lowest common denominator that can be implemented across most popular CPUs with decent performance and while producing consistent results. There's a follow-up proposal in progress to relax the "consistent results" part and allow for some slight precision wiggle room with instructions that couldn't be implemented otherwise (e.g. they could add an FMA instruction that compiles to native FMA where available or separate MUL-ADD otherwise, even though they won't produce exactly the same results).