Companion file for conveniences

[ISSOtm]

See #36 and #37 for context.

It would be useful to distribute a file whose defines aren't just strictly hardware-related. For distribution convenience, I'd suggest putting it in this same repo; this should not be a big deal, considering the size of the files in question.

Here are some discussion items:

• [ ] Any reasons not to do this?
• [ ] How to call it?
• [ ] What to put in it?

An obvious candidate for the contents is the PAD{B,F}_* constants, but there are likely more that I'm missing right now.

[Rangi42]

How about "hardware_extras.inc" or "hardware-extras.inc"? "foo-extras" looks like a common pattern for useful but inessential library additions.

[zlago]

maybe name it after the constants it has, but store them in extras/ directory? so hardware.inc would have hardware constants, pads-gba.inc would have gba convention pad constants...

[pinobatch]

windows.h automatically includes some lesser-used convenience headers if WIN32_LEAN_AND_MEAN is not defined. For the sake of easing the transition, would an analogous define for hardware.inc that disables the extra headers be a good or bad idea?

[aaaaaa123456789]

I'd call it something like stdlib.inc, since that's what its goal seems to be. (And I'd have stdlib.inc include hardware.inc for simplicity.) Some other possible additions for such a file would be:

• The identity palette mapping for DMG-based games, $E4 (as PAL_IDENTITY or BGP_IDENTITY or something like that)
• An identity character map (setcharmap ascii or setcharmap identity; I favour the latter) to suppress the corresponding warnings in RGBASM when identity mappings are used
• Alternate unofficial names for registers with known official names (like the audio or HDMA registers)

---

windows.h automatically includes some lesser-used convenience headers if WIN32_LEAN_AND_MEAN is not defined. For the sake of easing the transition, would an analogous define for hardware.inc that disables the extra headers be a good or bad idea?

Copying what I said in #37:

First of all, if a constant for "extra" definitions was to be added, it would have to be opt in, not opt out. That being said, it's still a bad idea. This project has been offered to users as a way to reference hardware, not to impose opinionated non-hardware non-conventions onto unaware codebases. The registers have official names, and the flags have obvious behaviors; anything else shouldn't be here, because the advertised goal isn't to impose on random codebases.

If you want to make a "standard library", the proper way to do that is to make an actual standard library repository.

[Rangi42]

If it's going to be called stdlib.inc, I can think of various things besides "subjective hardware-related constants" that could be added. In particular, the macros that are frequently recommended and even used in example code, like lb hl, HVAL, LVAL, or bigdw BigEndianWord. Conversely, if it's not going to define such utility macros (understandable since many projects define their own), I think "stdlib" is too broad a name for that one file.

[ISSOtm]

I'd add them to the file, since projects that define their own aren't using stdlib.inc in the first place; and if they were (and it had incompatible semantics, or something), then PURGE would allow overriding them anyway.

Shall we open a PR, then?

[evie-calico]

A CGB-format rgb macro would be nice too.