Store the logos as PNGs

[ISSOtm]

This would be a little more visually pleasing than the macros we are currently using.

• [ ] The GAME BOY logo is the easiest one: run it through rgbgfx -d 1, and skip every other byte of the generated .1bpp. (@Rangi42 pointed out that a consistency check that the image is 2× upscaled would be good for anyone modifying the ROM.)

• [ ] The Nintendo logo is however trickier, because it's also upscaled 2× horizontally.

[ace-dent]

Could this expose the project to some Copyright / litigious issues...? 👀 If you're going to store bitmap images, perhaps the human readable and easily parsable PBM format might be good?

[Rangi42]

There are no special copyright laws for PNG images.

[ISSOtm]

Human readability and easy parsability are generally in direct conflict! For example, humans treat all kinds of whitespace indifferently, whereas computers are much more picky (consider the[^posix] various definitions[^notes] of[^locale] “whitespace”[^locale][^consistency]).

[!NOTE] (I wanted to explain why textual formats are not easy to parse, and then fell into a bit of a rabbit hole researching it, which I've preserved in links and in footnotes. I hope not to come off as arrogant or overwhelming; I intend this as a neutral summary, not to berate anyone.)

Likewise, there's case sensitivity, and just having a lot more failure modes because there's a lot more leeway in text than there is in raw bytes. You can always read a 32-bit number from just 4 bytes and then range-check it, whereas parsing it from text means ensuring that you can read at least one digit, that all characters are digits, that the result doesn't overflow 32 bits, and then you can range-check if you haven't forgotten to by then.

(EDIT: There's yet more aspects that could be talked about, but I feel like that'd be more appropriate for e.g. a blog post :stuck_out_tongue:)

[^posix]: And even which of these 128 characters counts as whitespace—not everyone agrees! POSIX's definition of whitespace includes U+000B Vertical Tab (compared to WhatWG/Rust's), but POSIX also defines shell splitting to be much more restrictive. Meanwhile, RGBDS, like a lot of other hobbyist software, sticks to U+0020 Space and U+0009 Horizontal Tab. [^notes]: See the two footnotes below; e.g. U+0085 Next Line is considered whitespace by Rust but not JS! [^locale]: Note that this depends on the “active locale”, which is global state! :) See this nicely-ranty commit message to get an idea of how awful locales can be. [^consistency]: Note that isblank's locale-specific chars are only required to be a subset of issspace's (N3096 7.4.1.3), but not to be the same!

[Rangi42]

That's a fascinating and well-researched "whitespace" rabbit hole! And I agree with you about the general difficulty of parsing plain-text "human-readable" formats. But for the PPM format specifically, "whitespace" just means Space, Horizontal Tab, CR, and LF.