Symbolic names for 2600 colors PAL/NTSC

supercat · February 4, 2007

It seems that a popular convention is to name base colors things like BROWNGREEN, and then add luminance values to that. This allows for easy PAL/NTSC portability, but seems awfully clunky.

Would anyone see any disadvantage to creating symbolic constants x00 through xFE to refer to NTSC-style colors? PAL conversion could simply redefine those colors as needed. To allow for slight color tweaking between the PAL and NTSC versions, the constants v00-vFE and w00-wFE could hold the same values as the x** ones in NTSC mode, but select the color color "clockwise" or "counterclockwise" in PAL mode.

Can anyone see any disadvantage to that approach? I don't know about most people, but I have a stronger sense of what color "xE4" would refer to than "BROWNGREEN+$4"; further, the former notation would fit into tables much more nicely.

Edited February 4, 2007 by supercat

SeaGtGruff · February 4, 2007

It seems that a popular convention is to name base colors things like BROWNGREEN, and then add luminance values to that. This allows for easy PAL/NTSC portability, but seems awfully clunky.

Would anyone see any disadvantage to creating symbolic constants x00 through xFE to refer to NTSC-style colors? PAL conversion could simply redefine those colors as needed. To allow for slight color tweaking between the PAL and NTSC versions, the constants v00-vFE and w00-wFE could hold the same values as the x** ones in NTSC mode, but select the color color "clockwise" or "counterclockwise" in PAL mode.

Can anyone see any disadvantage to that approach? I don't know about most people, but I have a stronger sense of what color "xE4" would refer to than "BROWNGREEN+$4"; further, the former notation would fit into tables much more nicely.

I'm of two minds.

I think it helps to give names to the colors, but the choice of specific names can be a bit subjective. For example, which hues are red, blue, and green; are they $4x, $8x, and $Cx, or something else? And what about all the in-between colors, like the two different oranges, or all the different greens? I actually think that in a given game, it might make more sense to use names that apply to the colors' specific uses in that game-- e.g., DEEP_WATER, SHALLOW_WATER, SKY_BLUE, BLUE_CRYSTAL, etc. The specific hue of blue that's used for DEEP_WATER might not be the same hue of blue that's used for SHALLOW_WATER, SKY_BLUE, or BLUE_CRYSTAL, and the names help you pick the desired color without having to remember which hue and luminance you're using for that particular color.

However, that approach is game-specific, and of course what you're asking about is a more generic approach. I like the idea of using hex values in the "names." I haven't quite rapped my brain around it yet, but the direction I'm thinking in is that it would be nice to have two sets of color tables-- one set that uses the NTSC values as its base, and then gives the nearest PAL equivalents, and another set that uses the PAL values as its base, and then gives the nearest NTSC equivalents. After all, it's reasonable to expect that PAL programmers are used to thinking of, say, $54 as being a particular color, whereas NTSC programmers are used to thinking of $54 as a very different color, so why do we want to make PAL programmers use "hexified" color names that don't conform to the way they're used to thinking? Perhaps you could use "N" for "NTSC," and "P" for "PAL." For example, if an NTSC programmer were writing a game, he/she might say "lda #N54" and mean for it to be the NTSC $54, whereas a PAL programmer might say "lda #P54" and mean for it to be the PAL $54. Then a constant could be defined at the start of the program-- e.g., "PALETTE = NTSC," or "PALETTE = PAL"-- to tell the compiler which color table to use. In other words, if PALETTE = NTSC, then the compiler would replace N54 with the NTSC value $54, but it would replace P54 with the NTSC equivalent of PAL $54. Likewise, if PALETTE = PAL, the compiler would replace N54 with the PAL equivalent of NTSC $54, but it would replace P54 with PAL $54, if you see what I mean. That way, the programmer can use the hex values that he/she is most familiar and most comfortable with, but recompiling the program for one palette or the other would be as simple as changing the line of code where PALETTE is defined.

And of course, this could be combined with the game-specific color names, because the programmer could define a list of game-specific color names at the beginning of his/her code, then refer to these game-specific names throughout the code.

PALETTE = NTSC; Change to PALETTE = PAL when compiling for PAL
SKY_BLUE = NAE; A PAL programmer might use SKY_BLUE = P9E
  lda #SKY_BLUE
  sta COLUBK

; This would be in an includes file, e.g., colors.asm
; Replace the following *pseudocode* with the correct compiler syntax!
  if PALETTE = NTSC then
  NAE = $AE; NTSC color $AE
  P9E = $AE; The NTSC equivalent of PAL color $9E
  end if
  if PALETTE = PAL then
  NAE = $9E; The PAL equivalent of NTSC color $AE
  P9E = $9E; PAL color $9E
  end if

Michael

SeaGtGruff · February 5, 2007

Here's a simple little test I did with the method I described. I used three includes files-- colors.asm, NTSC_colors.asm, and PAL_colors.asm. You include colors.asm in your program, and then add a line that says either "PALETTE = NTSC" or "PALETTE = PAL," depending on which type of Atari/TV you're compiling your program for. Then you can use the color names N_00 through N_FF for the NTSC hex values, or P_00 through P_FF for the PAL hex values, or even mix them together in your program. (I decided to include the odd-numbered values, in case somebody is using bit 0 of the color value for some sort of flag. And I put an underline between the letter and the hex value because the 2600 has something called PF0, PF1, and PF2. :ponder: )

The NTSC_colors.asm file is included if PALETTE = NTSC. It contains two color tables-- one to define the N_00 through N_FF values, and another to define the NTSC equivalents for the P_00 through P_FF values. For example, if you use P_54 in your program, it will represent green, as it does in the PAL color palette, but the compiler will replace it with the NTSC equivalent (i.e., $C4). On the other hand, N_54 would be replaced with $54 (NTSC violet red).

The PAL_colors.asm file is included if PALETTE = PAL. It also contains two color tables-- one to define the PAL equivalents for the N_00 through N_FF values, and another to define the P_00 through P_FF values. For example, if you use N_54 in your program, it will represent violet red, as it does in the NTSC color palette, but the compiler will replace it with the PAL equivalent (i.e., $84). On the other hand, P_54 would be replaced with $54 (PAL green).

The first and second test programs use the N hex color values to define seven basic colors-- black, yellow, orange, red, purple, blue, and green. But the first test uses PALETTE = NTSC to compile the program for NTSC, and the second test uses PALETTE = PAL to compile the program for PAL/60. The only difference between these two programs is the "PALETTE =" line.

The third and fourth test programs use the P hex color values to define the same seven basic colors. But the third test uses PALETTE = NTSC to compile the program for NTSC, and the second test uses PALETTE = PAL to compile the program for PAL/60.

Test 1 -- Uses N hex color values -- Compiled for NTSC

Running in z26 with the NTSC palette

Running in z26 with the PAL palette

Test 2 -- Uses N hex color values -- Compiled for PAL/60

Running in z26 with the NTSC palette

Running in z26 with the PAL palette

Test 3 -- Uses P hex color values -- Compiled for NTSC

Running in z26 with the NTSC palette

Running in z26 with the PAL palette

Test 4 -- Uses P hex color values -- Compiled for PAL/60

Running in z26 with the NTSC palette

Running in z26 with the PAL palette

The source files, the ROM binaries, and the three includes files are all in the attached .ZIP file.

Michael

Palette_Selection_Test.zip

vdub_bobby · February 5, 2007

I don't know about most people, but I have a stronger sense of what color "xE4" would refer to than "BROWNGREEN+$4"

:lol:

Not me.

Anyway, I use (approx.) the same naming convention that the TIA Manual uses. Though looking again at the standard constants I use, it looks like I changed some of the names. :ponder:

Thomas Jentzsch · February 5, 2007

I prefer using color names instead of values (or value constants) too. IMO it makes the source code more readable.

SeaGtGruff · February 6, 2007

I prefer using color names instead of values (or value constants) too. IMO it makes the source code more readable.

Well, no one looked at my include files and code, so I'll post portions of the code to show what I did.

; from the first test program
  INCLUDE "colors.asm"

PALETTE = NTSC

BLACK   = N_00
YELLOW  = N_1A
ORANGE  = N_38
RED	 = N_46
PURPLE  = N_66
BLUE	= N_84
GREEN   = N_C6

; skip a bunch of code

  LDX #192				  ; +02; 05

active_loop

  sleep 18				  ; +18; 23

  LDA #YELLOW			   ; +02; 25
  STA COLUBK				; +03; 28

  NOP					   ; +02; 30

  LDA #ORANGE			   ; +02; 32
  STA COLUBK				; +03; 35

  NOP					   ; +02; 37

  LDA #RED				  ; +02; 39
  STA COLUBK				; +03; 42

  NOP					   ; +02; 44

  LDA #PURPLE			   ; +02; 46
  STA COLUBK				; +03; 49

  NOP					   ; +02; 51

  LDA #BLUE				 ; +02; 53
  STA COLUBK				; +03; 56

  NOP					   ; +02; 58

  LDA #GREEN				; +02; 60
  STA COLUBK				; +03; 63

  NOP					   ; +02; 65

  LDA #BLACK				; +02; 67
  STA COLUBK				; +03; 70

  STA WSYNC				 ; +03; 00

  DEX					   ; +02; 02
  BNE active_loop		   ; +03; 05

; from the second test program
  INCLUDE "colors.asm"

PALETTE = PAL

BLACK   = N_00
YELLOW  = N_1A
ORANGE  = N_38
RED	 = N_46
PURPLE  = N_66
BLUE	= N_84
GREEN   = N_C6

; everything else is identical to program 1
; in fact, the only line of code that's different is PALETTE = PAL

; from the third test program
  INCLUDE "colors.asm"

PALETTE = NTSC

BLACK   = P_00
YELLOW  = P_2A
ORANGE  = P_48
RED	 = P_66
PURPLE  = P_A6
BLUE	= P_D4
GREEN   = P_76

; this program uses the PAL "color variable names"
; but is otherwise identical to program 1

; from the fourth test program
  INCLUDE "colors.asm"

PALETTE = PAL

BLACK   = P_00
YELLOW  = P_2A
ORANGE  = P_48
RED	 = P_66
PURPLE  = P_A6
BLUE	= P_D4
GREEN   = P_76

; same as program 3 except for PALETTE = PAL

So I'm using descriptive names for the colors, but I'm defining the descriptive names with "NTSC color variable names" (e.g., N_58) and/or "PAL color variable names" (e.g., P_7A). That way, all I have to do to compile the program for NTSC or PAL is change the "PALETTE =" line; the compiler automatically plugs in the hex values that are appropriate for the specified palette. Right now the colors.asm file is very short and simple:

NTSC = 0
PAL  = 1

  ifconst PALETTE
  if PALETTE == NTSC
	 include "NTSC_colors.asm"
  endif
  if PALETTE == PAL
	 include "PAL_colors.asm"
  endif
  endif

However, you could easily expand it to define the hues using whatever your favorite color names might happen to be:

NTSC = 0
PAL  = 1

  ifconst PALETTE
  if PALETTE == NTSC
	 include "NTSC_colors.asm"
  endif
  if PALETTE == PAL
	 include "PAL_colors.asm"
  endif
  endif

GRAY		  = N_00
YELLOW		= N_10
YELLOW_ORANGE = N_20
RED_ORANGE	= N_30
RED		   = N_40
RED_PURPLE	= N_50
PURPLE		= N_60
BLUE_PURPLE   = N_70
BLUE		  = N_80
BLUE_CYAN	 = N_90
CYAN		  = N_A0
GREEN_CYAN	= N_B0
GREEN		 = N_C0
YELLOW_GREEN  = N_D0
ORANGE_GREEN  = N_E0
BROWN		 = N_F0

Then you can use the "meaningful" names, and add the desired luminance values to them, and all you need to do to compile for NTSC or PAL is change the "PALETTE =" line.

Michael

supercat · February 6, 2007

IMO it makes the source code more readable.

CLDAT7:; rocket
 byte $00,$0F,$0F,$0F,RED+$6,RED+$6,LIGHTBLUE+$8,LIGHTBLUE+$C,LIGHTBLUE+$8,RED+$6,RED+$6,$0F,$0F,$0F,$0F,$0F
CLDAT8:; dog house
 byte $00,$0F,ORANGE+$6,ORANGE+$0,ORANGE+$6,ORANGE+$0,ORANGE+$6,$0F,BROWNGREEN+$A,BROWNGREEN+$8,BROWNGREEN+$6,ORANGE+$A,ORANGE+$A,ORANGE+$A,$0F,$0F

That sure looks readable to me. Much better than hex

DATA "0f 0f 0f 0f 0f 46 46 98 9c 98 46 46 0f 0f 0f  40 70" : 'rocket
DATA "0f 0f 2a 2a 2a C6 C8 Ca 0f 26 20 26 20 26 0f  20 30" : 'house

vdub_bobby · February 6, 2007

IMO it makes the source code more readable.

[snip]

That sure looks readable to me. Much better than hex
DATA "0f 0f 0f 0f 0f 46 46 98 9c 98 46 46 0f 0f 0f  40 70" : 'rocket
DATA "0f 0f 2a 2a 2a C6 C8 Ca 0f 26 20 26 20 26 0f  20 30" : 'house

You can make anything unreadable if you format it poorly enough. Looking past the line-length issues, it is much easier to look at the first snippet of data and (a) tell that it is a table of color values and (b) tell what the colors are at a glance. Orange plus a luminence, browngreen plus a luminence, red plus a luminence, etc. Next you'll be arguing that the constants WSYNC, COLUP0, etc. aren't readable either and everyone should just memorize the hex values. :roll:

:lol:

Edited February 6, 2007 by vdub_bobby

Thomas Jentzsch · February 6, 2007

That sure looks readable to me. Much better than hex

Yup, for me it does.

And my way for switching between PAL and NTSC looks like this:

NTSC_COL  = 1

and:

IF NTSC_COL
 RED = $40
 ...
ELSE
 RED = $60
 ...
ENDIF

or:

IF NTSC_COL
 WATER_COL = $84
 SKY_COL = $9c
ELSE
 WATER_COL = $d4
 SKY_COL = $bc
ENDIF

or both combined:

IF NTSC_COL
 BLUE = $80
ELSE
 BLUE = $d0
ENDIF

 WATER_COL = BLUE|$4

Whatever works best for me.

Sign In

Symbolic names for 2600 colors PAL/NTSC

Recommended Posts

supercat

Link to comment

Share on other sites

SeaGtGruff

Link to comment

Share on other sites

SeaGtGruff

Link to comment

Share on other sites

vdub_bobby

Link to comment

Share on other sites

Thomas Jentzsch

Link to comment

Share on other sites

SeaGtGruff

Link to comment

Share on other sites

supercat

Link to comment

Share on other sites

vdub_bobby

Link to comment

Share on other sites

Thomas Jentzsch

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members

Apps

My Activity Streams

More