scratch VS libgamearchive

pbmview, an image viewer (windows subsystem).

For comparison (for those following along): https://github.com/skeeto/scratch/blob/master/parsers/qoi.c https://github.com/skeeto/scratch/blob/master/parsers/ini.c

Another option I learned a couple years ago is embedding a UTF-8 manifest ([details])[https://github.com/skeeto/scratch/tree/master/libwinsane]. Also put the console in UTF-8 mode (SetConsoleOutputCP(CP_UTF8)), and you're done. Works on Windows 10 and later. This covers everything: argv is UTF-8 and fopen accepts UTF-8 paths. (This is exactly how CRTs should have worked all along.)

I was thinking more about this and I realized it's quite easy to do it in arbitrary precision, so here's my take: https://github.com/skeeto/scratch/blob/master/misc/bswap.c

As was linked from my QOI article, here's my full decoder with comments: qoi.c. Each pixel decodes to a 32-bit integer, ABGR. That corresponds to SDL's SDL_PIXELFORMAT_ABGR8888. SDL_UpdateTexture copies that data into the texture's internal storage, and font is no longer needed. (In a real program I'd allocate it in a scratch arena, reset after initialization.)

A recent, interesting experience with function+context allocation: For more than a decade, Windows accidentally exposed part of zlib in a public DLL, and (overly-)clever applications can exploit this as a "system zlib." Though it doesn't export the "end" functions, so cleanup seems impossible. However, custom allocation works, so doesn't matter. I plugged it into an arena.

A rewrite was also sorely needed, even without changing the language. One of the "mistakes" I made with the C++ architecture of libgamearchive for example, was to try to modify archive files in-place, as opposed to writing a new archive file out from scratch and then moving it over the top of the original file. While it can be significantly quicker editing in-place, it introduces a huge amount of complexity and to be honest, the amount of time spent debugging problems caused by this is just not worth it. The compression and encryption algorithms as well, they are streaming so work whether you write one byte at a time or one megabyte at a time (and will process terabytes of data without issue), but having them track what point they are up to across multiple calls like that adds a huge amount of complexity (just look at all the case statements in the Monster Bash RLE encoder so the function can resume at the correct point in subsequent calls). So regardless of language, it was due for a major refactor anyway as continuing with this amount of complexity was just not worth the headaches it brings. Especially on today's hardware, writing out a 40 MB .GRP file from scratch will take well under a second, so spending hours, sometimes days, debugging write-in-place problems just isn't worth the benefit.