Somewhat related. Your QOI lossless file format coupled with 7Zip outperfoms lossless PNG. Amazing work!
BMP coupled with 7Zip would outperform too (probably by a bigger margin). It just boils down to gzip vs gzip-replacement compressor.
Porting my JavaScript game engine to C for no reason
11–20 of 139 posts
Re: Porting my JavaScript game engine to C for no reason
#12now rewrite it back to JS with https://github.com/KilledByAPixel/LittleJS j/k :D
[deleted]
Re: Porting my JavaScript game engine to C for no reason
#13With WASM it might actually run faster in the browser as well.
Re: Porting my JavaScript game engine to C for no reason
#14now rewrite it back to JS with https://github.com/KilledByAPixel/LittleJS j/k :D
Why, from C to Zig, from Zig to Rust. Compile the Rust version to WASM to finally make it runnable in the browser.
Re: Porting my JavaScript game engine to C for no reason
#15Re: Porting my JavaScript game engine to C for no reason
#16now rewrite it back to JS with https://github.com/KilledByAPixel/LittleJS j/k :D
Why, from C to Zig, from Zig to Rust. Compile the Rust version to WASM to finally make it runnable in the browser.
i'm actually quite curious how it would perform relative to the C version. the article shows 1000x particles, but LittleJS has demos with a couple orders of magnitude more than that at 60fps.
e.g. https://killedbyapixel.github.io/LittleJS/examples/stress/
Re: Porting my JavaScript game engine to C for no reason
#17With WASM it might actually run faster in the browser as well.
WASM still needs better multi-threaded support. We built a game in Bevy and it took minutes to sequentially load in all of the assets.
Re: Porting my JavaScript game engine to C for no reason
#18Earlier quoted context omitted.
Why, from C to Zig, from Zig to Rust. Compile the Rust version to WASM to finally make it runnable in the browser.
Doesn't Zig compile to WASM too?
Yes, for instance this is mixed Zig/C project (the C part are the sokol headers for the platform-glue code):
https://floooh.github.io/pacman.zig/pacman.html
The Git repo is here:
https://github.com/floooh/pacman.zig
...in this specific project, the Emscripten SDK is used for the link step (while compilation to WASM is handled by the Zig compiler, both for the Zig and C sources).
The Emscripten linker enables the 'embedded Javascript' EM_JS magic used by the C headers, and it also does additional WASM optimizations via Binaryen, and creating the .html and .js shim file needed for running WASM in browsers.
It's also possible to create WASM apps running in browsers using only the Zig toolchain, but this requires solving those same problems in a different way.
Re: Porting my JavaScript game engine to C for no reason
#19With WASM it might actually run faster in the browser as well.
It does, but the main speedup comes from using WebGL instead of Canvas2D. Sadly, Canvas2D is still as slow as it ever was and I really wonder why.
Years back I wrote a standalone Canvas2D implementation[1] that outperforms browsers by a lot. Sure, it's missing some features (e.g. text shadows), but I can't think of any reason for browser implementations needing to be _that_ slow.
Re: Porting my JavaScript game engine to C for no reason
#20With WASM it might actually run faster in the browser as well.
WASM still needs better multi-threaded support. We built a game in Bevy and it took minutes to sequentially load in all of the assets.
You don't need multithreading to get concurrent asset streaming, a completion callback or async-await-style code will work too (after all, that's how most Javascript web games load their assets "in the background"). Also, browsers typically restrict concurrent download streams to about 6 (the exact number is entirely up to the browser though) - so you can have at most 6 asset files 'in flight'. In the end you are still limited by the user's internet bandwidth of course.