z88dk forums

Hi everyone,

Choice of colors is personal and it depends on the applications. So I am not complaining. I am just asking how to use other colors.
In my games I would like to have bright and more visible colors as standard colors (selectable with the macros such as CYAN and RED).

For the Laser500 target the standard available palette in Z88DK macros are the half-bright colors. This makes them barely visible on (the common) black background. So, I would suggest to use the brighter corresponding colors.

On the CPC the "cyan" color is also the half-bright version of cyan or blue, i.e. it is a sort of "teal". It qualifies as "cyan" anyway.
Is there a way for me to select the "bright cyan" instead? Should I try different integer values and see what I get.

By default (on the whole), the colours are mapped from the named constants in conio.h on a "best" efforts basis. There's been numerous times when they've been tweaked: I'm certainly not the best person to pick colours so I'm always open to changing the mappings.

If you use -pragma-define:CLIB_CONIO_NATIVE_COLOUR=1 then this mapping is disabled and the colour value will correspond to the native palette index. Of course doing this loses the portability but would allow the full 27 colour palette on the CPC to be used (subject to screen mode etc).

Thanks Dom! I may try the pragma. In my Cross-Lib-based games, I have my own cross-dev-kit astraction layer. So I use my own macros to achieve portability across all systems.

Coming back to the Laser500, the colour mappings are defined here: https://github.com/z88dk/z88dk/blob/mas ... ur.asm#L28

So the LIGHT colours from <conio.h> are probably the ones you want if the standard ones are too dark - you may want to try it on the CPC as well.

GameGear and SMS have also a weird khaki (dark greenish brown) "YELLOW" color and no "LIGHTYELLOW" is available.
Apart from the luminance, the hue is wrong for me.

@dom, if I look at the palette in the Emulicious emulator, I see YELLOW ($A) and the KHAKI ($B) next to each other. Maybe this is a bug.

The SMS palette in the legacy VDP modes is known to be a bit wonky: https://www.smspower.org/Development/Pa ... temMarkIII

@dom, why don't we also expose LIGHTYELLOW then?

Obviously, all VDP colours are available if you disable the mappings.

However, that becomes a pain when you're dealing with multiple machines so it's nice to use the colour names in conio.h. These names were inherited presumably from some windows compiler so the distribution is a little weird to say the least.

Add that in to the available colours of old hardware being limited or horrible then a little bit of creativity has to be used in the mappings to fill in the gaps. The VDP mappings are these (conio.h on the left, VDP data sheet name on the right)

;BLACK -> BLACK
;LIGHTGREEN -> LIGHT GREEN
;BLUE -> DARK BLUE
;LIGHTBLUE -> LIGHT BLUE
;BROWN -> DARK RED
;CYAN -> CYAN
;LIGHTCYAN -> CYAN
;RED -> MEDIUM RED
;LIGHTRED -> LIGHT RED
;YELLOW -> DARK YELLOW
;LIGHTGRAY -> LIGHT YELLOW
;GREEN -> DARK GREEN
;LIGHTMAGENTA -> MAGENTA
;MAGENTA -> MAGENTA
;DARKGRAY -> GRAY
;WHITE -> WHITE

So, if you want VDP colour LIGHTYELLOW (index $0b), use named colour LIGHTGRAY. The only colour that isn't exposed is MEDIUM GREEN which is colour index 2.

The situation with the VDP is further complicated by the palette used by the SMS for the legacy modes not actually matching the machines with a vanilla TMS99x8 chip.

As mentioned above, I'm quite happy to change colours and add in a special override for the SMS, but bearing in mind that using that smspower link in the right hand column I can see 6 shades of green, I'm really not the right person to deciding them!