TrevorSundberg

Hmm, it looks like our call to `gl.createTexture()` returned null. I'm actually not sure what we'd do in that case other than fail with an error dialog.

One day I'd love to compile part of Chromium's rendering into a WASM module. In my imaginary world, people just make html+js+css pages using the "firefox.wasm", "chromium.wasm", whatever rendering engine of their preference, and browsers just become wasm players. They can even expose APIs to support local fonts and whatever else browsers need today. I realize that's far-fetched given the sheer amount of rendering optimization Chromium has done just to work on all the hardware, graphics APIs, and platforms they support. But this is honestly one of the reasons I wanted to port our engine to pure WASM. I wanted to see what a minimal API would look like for a full game editor (not just engine!) that a browser would have to expose with basic graphics and audio. It's a lot smaller than I expected, and side note... Emscripten did a great job of hiding all those details! WASI has made huge strides in getting OS level APIs exposed to WASM, but it's mostly headless stuff, not really a focus on GUIs or audio yet. I'm sure proposals exist, but the speed of getting these mainstream is slow because I'm sure they want to get it right. I'm hoping this engine can serve as an example for what we need from WASI to start making this possible.

And if you're curious, this is why I linked this header in the post; it has the minimal surface of functions we needed: https://github.com/raverie-us/raverie-engine/blob/main/Code/...

And I'm sure this fictional browser could find a way to make ad-blocking plugins that analyze network traffic and decompile wasms to scan for whatever using the latest AI magic :P

Just letting you know we put in a fix for DPI!

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

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.

YES! Absolutely yes to this. Right now the built in language was made well before WASM was even a thing, but at some point in the future I'd like to make it target WASM directly or even potentially use AssemblyScript or something like it. I certainly also want to have the engine support importing WASM modules as plugins, for when you need serious near-native performance rather than a scripting language.

Tiny modules also sound awesome. I'll give the article a read, thanks for this!

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/

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/

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/

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/

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/

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

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

I second that!

Why does a WASM > NES translator actually sound fun to write...

Also hopefully these docs can be of use. They're a bit of a mess as they were never properly ported to GitHub wiki: https://github.com/zeroengineteam/ZeroDocs/blob/master/getti...

I'll for sure list issues there. I also need to move the docs from here:

https://github.com/zeroengineteam/ZeroDocs/blob/master/getti...

That's something you'll have to code up yourself, however to get you started this script checks for pressing the W key and moves forward:

https://pastebin.com/8kMTCu3Y

The transfer of image data only happens when we yield inside the engine which only occurs when you hit a breakpoint in script. Otherwise we're just rendering to the OffscreenCanvas and letting the normal flow blit it to the screen (not doing any copying).

I just did some profiling on Firefox and I feel like the profiling result doesn't quite make sense but it's saying that the majority of time is spent calling Performance.now() from the clock calls in C++. I'm wondering if that's because we're calling it too many times and maybe we should just call it once per frame.

I heard the same thing and I really hope what they're doing is for the best. It would have fundamentally changed my path if I didn't get that core low level experience of building game engines.

Really want this to be a great learning tool!

To be honest I haven't spent much time in Unity. Back in the day you either had to parent objects to the camera to make UI, or use a completely different UI system. It sounds like now Unity scenes can be overlaid on top of each other, is that correct?

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.

If you hit space bar to bring up the command selector and hit Edit In Game, you should get a view that shows you all the debug draw, gizmos, etc. Hopefully this answers what you're referring to.

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…

I’m fairly certain the native version of Scratch is just a browser with Scratch running in a web view. I’d also mention that WASM isn’t tied to a browser either (despite being called WebAssembly, it’s now widely used outside of browsers). You can in fact make native executables now from a WASM binary.

Still a lot of hold overs from being a native app :P

Good find though!

I haven’t tried PlayCanvas yet, but it looks great. I think the primary difference is that this engine is a learning tool primarily, and doesn’t have any intention to compete with bigger name engines.

This project was made in 2012 when there weren’t that many languages, especially not ones that bind to C/C++ (and we’re type safe). LUA was the primary embeddable language back then, and C# wasn’t even open source yet :)

Thanks, I’ll make the fix!

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.

I always thought it was so cool Figma just rendered to a canvas! Oddly enough I ran into this at my previous job doing browser isolation when we got a bug report that Figma wasn’t displaying properly in our browser.

Makes sense to switch the rest of the UI to react though, just for how many people know it.