Hacker News Reader

Comment by astlouis44 | Hacker News Reader

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-i...

View on HN

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

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.

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?

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.

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.

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.

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.

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

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.

That's very helpful. Thanks.

It has real threads now, doesn't it? SharedArrayBuffer was reenabled in all browsers.

Sort of. It's more like processes with shared memory.

Emscripten has pthreads support. Maybe it's not perfect but it seems like a lot more than processes with shared memory to me.

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...

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?

Does WASM support SIMD?

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).

Reply on news.ycombinator.com