Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Unity like game editor running in pure WASM

raverie-us.github.io

Post reply on HN
Print view View original

151–160 of 166 posts

Re: Show HN: Unity like game editor running in pure WASM

#151

Post by TrevorSundberg »

sansseriff wrote: post #35

This is hitting my gpu super hard (Radeon Pro 560X, near-4k) with just the default ball scene. Frame rates are dipping very low just orbiting around. Does anyone know if there could be a WebGL optimization issue?

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/

Re: Show HN: Unity like game editor running in pure WASM

#152

Post by TrevorSundberg »

3836293648 wrote: post #47

Yet another reminder that WebGL is terrible in Firefox. Looking forward to webgpu being standardised and widely used instead.

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/

Re: Show HN: Unity like game editor running in pure WASM

#153

Post by TrevorSundberg »

dom96 wrote: post #140

Performance is definitely an issue here, this is on an M1 MacBook with Chrome and it's quite choppy.

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/

Re: Show HN: Unity like game editor running in pure WASM

#154

Post by TrevorSundberg »

icemelt8 wrote: post #63

It lags very slow on macbook m1 pro 14 inch chrome

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/

Re: Show HN: Unity like game editor running in pure WASM

#155

Post by TrevorSundberg »

DonHopkins wrote: post #125

Check out what I wrote earlier about how WAForth dynamically generates and links WASM code! By just reading the WASM documentation I didn't realize it was possible to call back into JavaScript to dynamically create and link in WASM code on the fly, but WAForth opened my eyes to that, by compiling each FORTH word definition into a tiny little module and linking them all together. No (practical) limit on the number of…

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!

Re: Show HN: Unity like game editor running in pure WASM

#156

Post by TrevorSundberg »

murkle wrote: post #131
exikyut wrote: post #123

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:…

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.

Re: Show HN: Unity like game editor running in pure WASM

#158

Post by TrevorSundberg »

nullifidian wrote: post #144
wewxjfq wrote: post #119

Earlier quoted context omitted.

Still infinitely better than WASM blobs where everything is painted on a canvas, which is un-adblockable. The experience will also be hellish, because every website will ship a 10 MB blob of half-baked things that your browser already does a million-times better out of the box. And for what? Because people think it will be faster (it won't).

The experience will probably be hellish anyway because of the Web integrity API. Javascript compiled to asm.js could produce painted-to-canvas websites too, and it won't be any less viable especially considering the growth of the CPU scores. Webassembly is prevalent in the canvas use cases because DOM manipulation with it is slower, clunky(due to the poor browser integration) and because people want to reuse native-l…

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

Re: Show HN: Unity like game editor running in pure WASM

#159

Post by johnnyanmac »

adamrezich wrote: post #146
johnnyanmac wrote: post #145

Earlier quoted context omitted.

>if students stop learning about how video games work at any lower level than "just use an off-the-shelf general-purpose game engine", then who's going to make game engines going forward? could this be a specialization or "minor", perhaps? IDK, it's tough. I want more students to be learning this stuff while in a proper environment, but the reality is that so much of the real tricks and sauce are either a) buried dee…

> Maybe Digipen is different as a gaming focused school, but I never learned about ECS or object pooling or profiler usage or especially cache coherency in college. I could write maybe a short pamphlet's worth of information that I wish I was taught by professors while I was at DigiPen that would've made all the difference in the world to me at least. the existence of cache coherency is definitely one of these topics…

>the ECS I wrote in C was terrible in part because I only understood the high-level ideas at the time—the whole thing was (hysterically, when looking back now) implemented with linked lists, as I was approaching systems design in terms of API, instead of actual functionality.

well that sounds awful. I wasn't making too deep a thought on which topics I'd throw onto a curriculum, but I'd hope that they wouldn't treat ECS like some pattern to memorize like some design patterns in my SWE course (literally called "software engineering". Quite confusing in retrospect). It should be treated as a way to apply and understand some data oriented design so you can make informed decisions on how to implement things.

I'm especially a fan of always identifying any and all shortcomings of an approach too. Because there's no better way to understand an approach than to reason about with its weaknesses. ECS is nice but you shouldn't try to shove it in stuff that requires tight complex coupling (e.g. a playercontroller), nor for random, infrequent events (UI input). And of course, if you are making a small game that can almost entirely fit in RAM anyways (well, in theory. Desktop OS's wouldn't allow this, obviosuly) these patterns are overkill and a half

>of course, the resulting student games whose screenshots and video clips you gather to use for promotional material for your school wouldn't be as flashy

well that is reflective of the modern game industry, haha. I imagine even in a place like digipen where you are working with motivated game artists that there's still technical constraints to consider with the art team (especially students). And building tools to help with that would take as long as the small game.

I did ponder if it'd be a good idea to have a CS game dev course each some basic 2d/3d art, and vice versa for an artist learning some CS101 style stuff. But the CS curriculum was already jam packed as is, at least at my alma mater. I believe the average course work required 170 units and CS (like other engineering degrees) was topping out at 190.

Re: Show HN: Unity like game editor running in pure WASM

#160

Post by TrevorSundberg »

webprofusion wrote: post #124

It errored on first go with a blank screen: Error: Failed to allocate type at x.allocate (worker-3ec07b2e.js:1:3516) at ImportGlGenTexture (worker-3ec07b2e.js:1:7645) at RaverieEditor-60af6467.wasm:0x1d459ee at RaverieEditor-60af6467.wasm:0xedf9e7 at RaverieEditor-60af6467.wasm:0xedf56b at RaverieEditor-60af6467.wasm:0xdffefa at RaverieEditor-60af6467.wasm:0xf213e3 Reloading fixed it, maybe a race condition between s…

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.
Post reply on HN