TrevorSundberg
Joined 7 years ago
Karma
378
Submissions
70
Member since
Dec 29
Recent submissions
Comment · 3 years ago
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.
Comment · 3 years ago
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
Comment · 3 years ago
Just letting you know we put in a fix for DPI!
Comment · 3 years ago
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.
Comment · 3 years ago
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!
Comment · 3 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/
Comment · 3 years ago
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/
Comment · 3 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/
Comment · 3 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/
Comment · 3 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:
Comment · 3 years ago
Fixed:
https://github.com/raverie-us/raverie-engine/commit/aa7e1b6c...
Had to take into account the mouse coordinates too since they were not scaled.
Comment · 3 years ago
I second that!
Comment · 3 years ago
Why does a WASM > NES translator actually sound fun to write...
Comment · 3 years ago
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...
Comment · 3 years ago
I'll for sure list issues there. I also need to move the docs from here:
https://github.com/zeroengineteam/ZeroDocs/blob/master/getti...