roadroller

> Do you write minified javascript? Yes [1] [2] [3]? [1] https://js1024.fun/demos/2020/46/readme [2] https://js1024.fun/demos/2022/18/readme [3] https://github.com/lifthrasiir/roadroller/blob/442caa4/index... Jokes aside, human doesn't read each (uncompressed) byte anyway. The number of tokens would have been much better than the number of bytes, but even this is unclear because a single token can have multiple perceived words (e.g. someLongEnoughIdentifier) and multiple tokens can even be perceived as a single word for some cases (e.g. C/C++ `#define` is technically two tokens long, but no human would perceive it as such). I would welcome a more realistic estimate than the gzipped size, but I'm confident that it won't be the number of uncompressed bytes.

As part of the annual JS13K games challenge, I've put together a pretty large (but small-in-code) Metroidvania game that fits in just 13KB of compressed Javascript. The source is available here: https://github.com/arikwex/infernal-sigil NOTE: the current head of the main branch is at 13.6KB due to quality of life patches. The legit 13KB version is tagged in github. Useful hacks: - Using Roadroller (https://github.com/lifthrasiir/roadroller) for compression - Compressing the map data as grayscale PNG paired with some code generation. - Using procedural animation for all characters. - Replacing string enum with numeric enums for compression. - Built a small game engine for object lifecycle and rendering. - Single function to generate unique procedural songs for different regions.

I'm honored that Q1K3, among many other entries to js13kGames 2021, is compressed with Roadroller [1], which is the reason that its (compressed) source code is basically a random-looking string plus some bit of JS code. [1] https://github.com/lifthrasiir/roadroller/

Good page. If I can I would also add a filtered image (or a set of them, if interlaced) to illustrate how PNG filters work. > The main reason to have multiple IDATs is if the encoder software wants to keep memory usage low and not need to buffer the entire IDAT, which is required just to know the final length of the chunk before starting to write the chunk. It should be noted that this is only true for streaming applications where they have no chance to fix the length field already written. > For example, outputting every DEFLATE symbol, every pixel value, or even every palette value, would be very verbose and probably not helpful. I have some idea for the visualization, but one possibility is to show a list of DEFLATE blocks. zlib tries to break blocks when applicable as a sort of adaptive compression so it might be interesting to see ov