Running WASI binaries from your HTML using Web Components

Post by tarasglek » Mon, Aug 28, 2023, 12:59 PM UTC

benno128 wrote: post #2

G’day, if anyone has any questions about this I’m happy to answer them here.

Post by ImHereToVote » Mon, Aug 28, 2023, 1:41 PM UTC

mrob wrote: post #58

parasti wrote: post #29

Earlier quoted context omitted.

That expectation is off by nearly a decade. WASM games in terms of performance are closer to 2000 than 2010. Here's an open source indie game from 2003 that I ported to WASM [1]. It struggles to hit 60 FPS on devices that were released a good 15 years after the game itself. Browsers sometimes struggle to animate simple lines at 60 FPS still to this day, because they're just hugely massive platforms with thousands of…

There's definitely something strange going on here. I'm getting about 3x as much CPU load on the WASM version as compared to native. Still low enough for a solid 144fps on my machine, but there shouldn't be this much overhead.

Post by benno128 » Tue, Aug 29, 2023, 3:03 AM UTC

tarasglek wrote: post #61

benno128 wrote: post #2

G’day, if anyone has any questions about this I’m happy to answer them here.

Hi, I already support typescript execution in http://chatcraft.org/ via wasm esbuild. Runno is really cool as it will also lets me support intepreted languages like Python and maybe even golang(assuming i can have a wasi binary produce another wasi binary). From docs: Currently @runno/wasi supports running only unstable and snapshot-preview1 WASI binaries. The snapshot-preview1 standard is more recent, and preferred.…

Post by flohofwoe » Tue, Aug 29, 2023, 6:56 AM UTC

parasti wrote: post #62

flohofwoe wrote: post #50

Earlier quoted context omitted.

Glancing at the project, one area where things could go terribly wrong is the translation layer from GL 1.x to WebGL. For instance 'tricks' that are common on native GL implementations like buffer orphaning are actually harmful on WebGL and may cause lock stalls which would cause exactly the issues you describe (e.g. struggling to hit a consistent frame rate despite extremely low CPU and GPU load). Even though WebGL…

A couple of years back I also wrote a pure WebGL renderer for Neverball levels [1]. No physics, no translation to WebGL, just the 3D renderer part in direct WebGL. It also has a surprisingly low performance ceiling. I'd say I managed even worse than what the gl4es translation layer does for Neverball. By far the biggest performance boosts were instanced arrays and vertex array objects - basically just reducing the nu…

Post by flohofwoe » Tue, Aug 29, 2023, 7:09 AM UTC

pjmlp wrote: post #59

flohofwoe wrote: post #52

Earlier quoted context omitted.

These are mostly business issues. If the business problems would be solved, the games would be built, despite any technical limitations of the web platform (which are not much different than limitations on low-end Android mobile devices). Nobody has figured out so far how to make money with high quality games on the "open web" to get the same return on investment like simple ad-driven 2D games running on closed platf…

No they aren't, at least low end Android devices support GL ES 3.2 and have proper debugging tools. After a decade Web 3D keeps having spectorJS as the only alternative. Naturally there are also some masochists that enjoy debugging the browser 3D stack on RenderDoc, while trying to figure out what belongs to their application.