ME: Alright. By the end of yesterday I'd solved the blockers, so today I can make some good progress on my work project.

MY BRAIN: You should drop everything and design a set of hypothetical color palettes for a 16-bit-color version of https://wasm4.org/

ME: Oh snap that's a really good idea

SOME HOURS LATER:

(In order:

1 (top left): 5 bits red, 5 bits green, 5 bits blue, 1 bit alpha

2 (top right): 5 bits blue, 6 bits green, 5 bits blue

3 (bottom left): 4 bits red, 4 bits green, 4 bits blue, 4 bits alpha

4 (bottom right): 5 bits red, 5 bits blue, 4 bits green, 2 bits alpha

I'm doing something unusual with "0 alpha", since it seems wasteful to devote half the color space to an identical full-invisible color. There are many problems I haven't considered yet but the work so far was enlightening.)

Wait, sorry. There was a bug in the post before. But now I've fixed it.

Things I have not yet considered:

- Is a linear map of the color space the best possible approach for the WASM16 use case? What about "SRGB"?
- When colors combine (via alpha), should they combine back into the 16-bit color space, or should they be composed in a higher-bit space such as the graphics card native?
- Assuming "full transparent" is done by a key color, could alpha combinations of colors result in accidentally mapping to the keycolor? What does alpha-blending WITH the keycolor mean?

Also, there's this interesting post:

https://mastodon.social/@TomF@mastodon.gamedev.place/110029989349970818

Saying when 565 was tried in video cards it lead to bad results because this is bad at displaying "pure" grays, and suggesting a 5-5-5-1 where the final bit is a shared brightness rather than alpha (!), a fascinating idea I'd never thought of. Did any retro consoles have a 16-bit color space (eg that their smaller palettes draw from)? How did they handle this? Wikipedia says the SNES underlying colorspace was 24-bit… hm.