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.
reply