Define color channel constants

[Rangi42]

Here's what we have for CGB colors so far:

def COLOR_SIZE equ 2 ; size of color in bytes (little-endian BGR555)
    def B_COLOR_RED   equ  0 ; bits 4-0
    def B_COLOR_GREEN equ  5 ; bits 9-5
    def B_COLOR_BLUE  equ 10 ; bits 14-10
        def COLOR_RED        equ %000_11111  ; for the low byte
        def COLOR_GREEN_LOW  equ %111_00000  ; for the low byte
        def COLOR_GREEN_HIGH equ %0_00000_11 ; for the high byte
        def COLOR_BLUE       equ %0_11111_00 ; for the high byte

And for DMG shades:

def SHADE_WHITE equ %00
def SHADE_LIGHT equ %01
def SHADE_DARK  equ %10
def SHADE_BLACK equ %11

What we lack is the meaningful values for individual CGB color channels:

• Each channel is 5 bits wide (COLOR_DEPTH? RGB_DEPTH?)
• The maximum value is 2**5 - 1 = 31 (MAX_RGB? RGB_MAX? or just let this be derived from the color depth?)

This would allow an edit to the above:

    def B_COLOR_RED   equ COLOR_DEPTH * 0 ; bits 4-0
    def B_COLOR_GREEN equ COLOR_DEPTH * 1 ; bits 9-5
    def B_COLOR_BLUE  equ COLOR_DEPTH * 2 ; bits 14-10

[quinnyo]

The term 'colour depth' typically (always, in my experience) refers to the number of bits used for the whole colour value, not the size of the component channels. I would say that the colour depth on the Game Boy Color is, without-a-doubt, 15 bits.

'RGB depth' (RGB_DEPTH) isn't an established term, but to me reads as if it's deliberately named 'RGB' to refer to the combined R, G, & B channels.

Using COLOR_DEPTH to refer to the components would clash with the existing COLOR_SIZE which refers to the whole.

The {CLASS}_{PROPERTY} convention (as in RGB_MAX in your example) makes sense. {CLASS} being the same as whatever is used for the bit width constant.

So, COLOR_CHANNEL_WIDTH & COLOR_CHANNEL_MAX?

Finally I'll mention that I'm not sure that adding these constants adds much practical value, but I recognise that that's just me!

[Rangi42]

Thank you, that's useful feedback!

Good points about the problems with my proposed names. I think that COLOR_CHANNEL_WIDTH and COLOR_CHANNEL_MAX are accurate, but longer than hardware.inc names tend to be. We already use "CH" sometimes regarding audio channels, (PCM12_CH1, AUDENA_CH1_ON, etc) so I think COLOR_CH_WIDTH and COLOR_CH_MAX would work.

And yeah, I'm suggesting pretty niche constants by now. :P Frankly I think the register names are the main chunk of hardware.inc's value for a lot of users -- the bit/flag constants were pretty sparsely defined until recently, let alone other aspects of the hardware. It's probably rare for people to need to refer to these two values, but when they do, they are tied to the hardware and not going to change, so IMO hardware.inc is the right place for "standard" names.