3 ms·
Does this mean that it would have been better to base hello-rust-sdl2-wasm on wasm32-unknown-unknown target (assuming this is possible)? EDIT: trying to answer
by FullyFunctional 3y ago
Does this mean that it would have been better to base hello-rust-sdl2-wasm on wasm32-unknown-unknown target (assuming this is possible)?
EDIT: trying to answer this myself got me down this rathole:
https://users.rust-lang.org/t/fixing-rusts-webassembly-targets/88947/4 https://users.rust-lang.org/t/fixing-rusts-webassembly-targe... and https://github.com/rust-lang/rust/issues/83788 https://github.com/rust-lang/rust/issues/83788
I did find older alternative solutions that uses wasm32-unknown-emscripten, like https://github.com/tanis2000/rust-sdl2-wasm https://github.com/tanis2000/rust-sdl2-wasm but it's not obvious to me that this is a better solution.
TL;DR: it's currently a mess
- jsheard 3y agoIdeally you wouldn't use SDL at all, you would use equivalent native Rust libraries like winit for windowing and wgpu for graphics, which all work with wasm32-unknown-unknown.
- FullyFunctional 3y agoSure. Any suggestions? (I don’t need much, just kbd input and pixel graphics out)
- jsheard 3y agohttps://github.com/rust-windowing/softbuffer https://github.com/rust-windowing/softbuffer That gives you a simple software framebuffer, and it builds as a native app or for the web. You'd set up a window (or web canvas) using winit, then pass that to softbuffer so it can render to it. https://trunkrs.dev https://trunkrs.dev I think Trunk is the most streamlined way of building for the web at the moment, superseding wasm-pack.
- awwsmm 3y agoIt has been a huge pain trying to get SDL2 to play nicely with Android / iOS. Would winit / wgpu make this easier?