Show HN: Unity like game editor running in pure WASM

I like the concept. My GPU and browser weep with lag. Its a very impressive slideshow.

I finally managed to highlight the starting sphere after several tries. At first I wasn't sure if it was loaded.

Of course, I'm only using a 1.8 GHz Celeron with onboard GPU and 8GB Ram in Firefox, so... not exactly high-end stuff.

I'd be curious if it runs any better under Chrome. Seems a lot of people are hitting Firefox issues. I'll be sure to test Firefox regularly though.

araes · 2 years ago

Because of these questions, I have now downloaded and tried:

Firefox Developer (119.0b1), Chrome (117.0.5938.92), Opera (102.0.4880.56), Edge (117.0.2045.43).

Turning off all other programs (without crashing Windows), ranking for trying to drag the selection square ~2 inches x 2 inches (on a 1920 x 1080 laptop with the above noted characteristics) without doing anything else. Did the drag back and forth TL-BR, BL-TR 5-6 times to get a feel for general timing (cannot claim I used a stopwatch):

Edge: ~1 sec response before square changes

Chrome: ~1.5 sec response before square changes

Opera: ~1.5 sec response before square changes

Firefox: ~2 sec response before square changes

From my super low-end perspective, Edge is surprisingly responsive (maybe optimized for Windows?)

Edit: From another perspective, looking at the Dev Tools (what I actually care about), Edge is pretty hilarious, it has 72 errors on its default landing page (including this is not a "TrustedScriptURL"). Opera only has 2 "Uncaught (in promise)" and both Google and Firefox have 0.

There's something comforting about the idea that Microsoft still does not trust Microsoft. ("Left hand meet right hand. Begone fool, we have no hands!") The more things change...

esrauch · 2 years ago

It was completely unusable on my M1 MacBook on Chrome, I suspect it's hitting some degenerate webgl/driver edge case.

dartos · 2 years ago

AFAIK, Firefox has all around awful webgl and webgpu performance.

I know personally, anything 3d in Firefox is a slideshow, even with a 4090

Deleted Comment

TrevorSundberg · 2 years ago

Hey all, if you’re willing to try again we just put out a fix that dramatically helps performance on some machines. Since this was a port to WASM from a native game engine, it turns out the issue was in our frame rate limiting code which wasn’t playing well with browser timing APIs:

https://raverie-us.github.io/raverie-engine/

Sophistifunk · 2 years ago

I'm on an m2 pro and had the exact same experience, also Firefox.

bullen · 2 years ago

So M2 = Celeron?

cchance · 2 years ago

jesus they still make celerons?

Do you know anything about any WASM developments that will enable pure WASM interaction with the browser's Web-APIs at no or at a low cost without the JS layer? Sometimes I look at https://github.com/WebAssembly/proposals and it's very confusing. There are the type imports proposal(years away), the almost complete GC proposal(which is apparently only for GCd languages, but not for anything browser<->wasm), the component model(which looks and sounds as something not for the browser use case), JS String Builtins (which will provide faster JS strings, but not DOM) and ECMAScript module integration (which will turn WASM modules into ES modules, but Web-APIs aren't ES modules so no luck). Sometimes I read contributor interactions and it looks as if providing such functionality isn't their priority or even in their plans, and for the majority the WASI + component model for the cloud, crypto and similar use cases are more important.

TrevorSundberg · 2 years ago

I really yearn for this myself. I would love to see a “pure wasm” browser where the pages are just wasm and the “browser” just provides a bunch of platform imports like WASI. I agree with you though, seems like it’s not a priority for them. One of these days…

CryZe · 2 years ago

Reference types technically already allow for calling directly into the browser APIs as reference types allow wasm to pass JavaScript objects around. So if you import all the relevant web apis, you don't really need any (almost any?) intermediate JS anymore, because you can just forward the JS objects between the individual API calls.

The only real need for JS would be to initialize the wasm module in the first place.

nullifidian · 2 years ago

>you don't really need any (almost any?) intermediate JS anymore

I don't think that's true. You still need JS glue code that would return these externrefs. A WebAssembly module loaded through ESM integration can't as far as the current proposals access Web-APIs on its own. As far as I understand there is also a number performance issues related to the wasm spec itself that limit possible optimizations, making wasm second class to JS in terms of performance of WebAPI access.

a1o · 2 years ago

The problem of pure wasm is we get a closed source web with unblockable ads.

nullifidian · 2 years ago

that ship has sailed. Minified and optionally obfuscated js is already highly annoying to decipher. The wasm spec is surprisingly high level for what should be a low level VM, and is planned to get much more high level approaching near jvm levels, and isn't any less readable than C++ compiled to asm.js.

csjh · 2 years ago

I believe that's at least part of what the GC proposal is moving towards.

sakras · 2 years ago

Wow you guys wrote Zero Engine? I used it in summer camps at DigiPen a long time ago, I really enjoyed using it and programming in Zilch (I wrote an AI that played a galaga clone!). This Unity fiasco had me wondering how Zero was doing. Seems like it's going to have a resurgence! Super exciting!

That's so cool! Zilch was my baby, that makes me so happy :D

adamrezich · 2 years ago

Zero/Zilch was great, and I wish DigiPen would've stuck with it! I heard that these days, they don't even have students make games from scratch anymore, and everyone just uses Unity or Unreal instead—any idea if that's true? it would be a bummer if it were, because striving to make a cool engine (especially once Zero was there as something to aspire to!) was like the best and most useful part of my time at DigiPen.

glad to see the spirit of Zero still going strong through Raverie, though!

wahnfrieden · 2 years ago

do you know what engine was in use or development during around 2002-2003? the engine was somewhat baked but flexible and had entry points where you drop c++ snippets in, I believe with a GUI

exikyut · 2 years ago

Just to contribute: yet another instance of "cool slideshow" on my (most definitely low end) laptop with integrated graphics.

Then tried it on my aging Mate 20 Pro (not too new, not tooo old), and it just seemed to get stuck at "Downloading runtime". Got a funny feeling my flaky 4G wasn't actually to blame, inspected the tab from my laptop (chrome://inspect) via USB, and was greeted with

  Uncaught (in promise) Error: Needs OES_texture_float_linear to function
      at M (worker-3ec07b2e.js:1:3338)
      at J (worker-3ec07b2e.js:1:3403)

It is what it is. It's a good philosophical question about whether it's worth coding up an error screen, since it's all just to tell people they can't play with the toy. Hehe.

murkle · 2 years ago

https://github.com/evanw/OES_texture_float_linear-polyfill

Hmm, I think that polyfill might only be for WebGL1 (we use WebGL2). When I go to the WebGL1 report I see that my card supports both:

OES_texture_float OES_texture_float_linear

But on WebGL2, it only shows OES_texture_float_linear. I think OES_texture_float doesn't exist on WebGL2 I'm guessing.

xeonmc · 2 years ago

How low end is it? I'm using my 8-year-old Surface Pro 4 on Starbucks wifi and it's blazing fast.

lionkor · 2 years ago

> Our engine had a unique feature called Spaces: separate worlds/levels that you can instantiate

This is, as far as I can tell, exactly what the Godot engine does[1]. That engine also has a browser (wasm) target.

[1]: https://godotengine.org/

_flux · 2 years ago

Not only does it have a wasm target, it also has a web version: https://editor.godotengine.org/

I suppose it's not any kind of priority to the project. Tested it a bit and it does seem to work :), but it's slower than running it natively.

Thats because the editor is built in godot as well, as far as i recall

BoorishBears · 2 years ago

I don't see how it's different than scenes in Unity either

lewispollard · 2 years ago

Worlds/Spaces in Godot at least are more to do with physics/lighting than scenes/levels. So two objects in the same scene can occupy different "spaces" (for physics), "scenarios" (for rendering), or "worlds" (which encapsulate a space and scenario, for both physics and rendering). Objects in these different contexts will appear in the same scene but will be separated in terms of those contexts and won't e.g. collide with each other or be affected by forces from one space if in a different space, or be lit by lights from a different scenario.

Everything in Godot is a scene, from actual scenes to groups of objects, etc.

It makes composing and managing objects and compositions much easier than just with the tree view.

Like a Unity prefab, but much better

WatchDog · 2 years ago

Cool project.

Is there any way to scale the UI for high dpi displays?

On a 2:1 display, the fonts look aliased, if I set the browser zoom to 50%, the UI looks crisp, but everything is a bit small to be useful.

Matheus28 · 2 years ago

To OP:

The fix is setting canvas width to window.innerWidth * window.devicePixelRatio, and height to window.innerHeight * window.devicePixelRatio. Then use CSS to maximize the canvas on the screen.

Thanks, I’ll make the fix!

Fixed: https://github.com/raverie-us/raverie-engine/commit/aa7e1b6c...

Had to take into account the mouse coordinates too since they were not scaled.

iddan · 2 years ago

I fail to understand why not use the native browser rendering engine, or at least SVG for the UI. It must be cheaper in resources (memory, network, cpu), easier to make accessible and easier to render

jjcm · 2 years ago

Anecdotally, in the very early days Figma rendered its UI entirely in canvas, but we eventually switched over to React for the UI. It ended up being far easier for development cycles and for accessibility/integration with existing browser features.

The main reason was just because this engine was entirely built for native platforms originally in C++ (not for the Web). This is a port, hence why the UI is running in WASM/WebGL.

darknavi · 2 years ago

Trevor! I loved your CS elective at DigiPen on designing programming languages with grammars.

Many of the students you taught are working on Minecraft now. I'm using so many fundamentals taught by you and my time at DigiPen when designing the Minecraft scripting API today.

Glad to see you're still rocking it.

Awwww I'm so glad it's been helpful! One of these days I'll get back into teaching ;) I'd love to see the scripting interface you're working on too, I spent so much time making Minecraft mods back in the day and I always wanted some kind of dynamic scripting.

meheleventyone · 2 years ago

This is super cool, it's great to see a pure WASM offering in this space. It does chug quite a bit on my M1 Mac Pro though!