How do I do that? Is there a documented configuration of musl's allocator?
Isn't that nolibc.h?
The way I understand it, we've got the YCbCr that is being converted to an RGB value which directly corresponds to how bright we drive the R, G, and B subpixels. So wouldn't the entire range already be available? As in, post-conversion to RGB you've got 256 levels for each channel which can be anywhere from 0 to 255 or 0% to 100%? We could go to 10-bit color which would then give you finer control with 1024 levels per channel instead of 256, but you still have the same range of 0% to 100%. Does the YCbCr -> RGB conversion not use the full 0-255 range in RGB?
Naturally, we can stick brighter backlights in our monitors to make the difference between light and dark more significant, but that wouldn't change the on-disk or on-the-wire formats. Those formats have changed (video files are specifically HDR or SDR and operating systems need to support HDR to drive HDR monitors), so clearly I am missing something but all of my searches only find people comparing the final image without digging into the technical details behind the shift. Anyone care to explain or have links to a good source of information on the topic?
It is part of Simon Tatham's puzzle collection, it also has an app on F-Droid:
https://f-droid.org/en/packages/name.boyle.chris.sgtpuzzles/
And the sgt-puzzles package on Debian/Ubuntu, possibly other distros package it too.
We simply don't have the same luxury with new games, they can be hit and miss, and reviews are untrustworthy.