Mostly because I want insight and control at a lower level, which breaks down into two different use-cases:
1. Debugging. The nature of bugs in this space is a lot more of "it doesn't look right on the screen" as opposed to "it breaks compilation", so I want to easily do things like peek into my buffers, use native js logging, etc. It's just a lot easier for me to reason about when I have more manual control.
2. Leaky abstractions. wgpu is a pretty low-level but it can't avoid the pain that comes with different backends, async where it should it shouldn't be, features that aren't available everywhere, etc.
That said, it would probably be pretty straightforward to convert the renderer into wgpu, most of the data structures and concepts should map cleanly
Yeah, I split the crates so `renderer-core` deals with the web-sys part, `renderer` is pretty much plain Rust (and wgsl with Askama templates)
I prefer this for 100% browser-only, but that's a niche. I do think wgpu makes more sense when you like the WebGPU headspace but want to target other backends (native, mobile, VR, etc.)
The quality of games on Google Play is much worse than what is available on Steam and the variety of titles are much greater on Valve's platform too, with far less in the way of microtransactions and other exploitative behaviours (though Steam isn't free of this) and a back catalogue stretching as far back to the mid 2000s.
Both Microsoft and Sony AAA titles, most third parties publish there and most indie games release there first. Steam's library is unparalleled in the industry, the only thing it's truly missing is Nintendo's games.
Ok, but the market is absolutely flooded with exploitative stuff, laden with micro transactions and a trickle of miniscule rewards, in attempt to addict the user, rather than genuinely provide enjoyment.
How do you even discover the good games that are worth being played on Android?
Kind of a dumb question, but how does it work if you have a 10 year non-compete in FL but move to another state after 5 years, is the non-compete valid in the other state?
Generally yes, unless you move to California (which expressly bans noncompetes regardless of where they were signed or where the work was done), in which case it's a "consult a lawyer, but you're probably fine" situation.
You could make it even smaller by removing all the element names, and just have it be passed in as an argument.
Would also reduce the amount of functions you need to declare, though function count is likely not a problem for modern JS engines.
Are you involved at all with the Bytecode Alliance or the decisions around the WASI proposals/standards? It feels like your take on these things would be super valuable given all the work you've done. They're a very open minded group.
Also, with the solid foundation and simple API footprint you've built for APIs like sokol_audio, would be interesting to see if they could be expressed in WIT and used as a basis for something like a wasi-audio.
+1 for Audio and lots of other APIs necessary to make WASI more like a true OS. With Preview 2 / Component model, hoping the pace of contributions rapidly increases.
Yes! It's kind of a pain to build now, so will probably shift to shipping as a .so/dll with a raw C api in a future version. With that, should be easy to generate bindings for any language - the host API footprint is minimal.
The primary issue with things that include their own Wasm env, that then moving that system to the web doesn't work because you can't run wasm in wasm.
Yes! Not in the open-source repo yet (because it's currently broken :) ) but you can see it in the video, and will have it working again soon.
That's exactly the goal - one wasm binary with defined input/outputs that can be loaded either in a browser or running in any app outside of a browser.
reply