That isn’t what I said at all. I meant only there is a certain pleasure and simplicity in designing for a very specific spec and NOT having to worry about other concerns. When it works on the target hardware, it’s done, period.
Sure, but let’s not confuse or conflate the library with the hardware itself thought, because they are very different things - the library only supports a fraction of the OLED hardware features, just to pick one example.
Remember that an API is also a ‘specification’ of a sort.
Sure, but if the implication then becomes “code only to the Arduboy2 API, not the hardware” that’s where I’d take issue (and that’s kind of how I read your original post, and what made me respond) . There are a lot of innovative things the screen can do that we’ll never see done if everyone steers clear of them and focuses instead on a “generic 8-bit vertical OLED/LCD interface”.
The one(?) game published that’s greyscale uses custom OLED commands to do the fading between screens. Does that work on other LCD/OLED controllers? I’m not sure if it does. I’m not sure it matters. I think it’d be WORSE to have never seen that innovation happen because someone was too concerned it wasn’t in the core library.
With that all said, it should hopefully be clear that I have no intent of ‘shaming’ the author.
There is no shame to be found.
Yeah I should have been clearer. I wasn’t accusing you per se, just saying I think it’s too easy to go down that road if we’re not careful - even if the intentions are good. Hence me adding my viewpoint to the discussion.
It’s cool to have a “homebrew” community (and I’m the last person who’d try and shut that down) but I also think there is real harm if it leads to avoiding super cool things that ONLY the REAL Arduboy can do - just for the few building custom units from scratch: units that don’t match the hardware spec.
[Note: Yes, I’m very clearly aware that isn’t what was happening in this specific case… it’s the sentiment I’m discussing, not this one particular case.]