Genesis Colour Specs?

[Biggie]

Hello. I'm a new member here and a longtime sega-fan who also happens to be a pixel artist. I really enjoy is making mockups based on the specs of older systems. I've done quite a few based on NES and Master System. I have a a fair knowledge about their limitations and such, but I want to move up a level and try one for my absolute fave system; The Mega Drive (or Genensis if you prefer that). So I hope someone here can clear some things up for me or at least point me in the right direction.

From what I understand the MD can show 64 colours on screen at the same time, based on a 9-bit RGB palette. That part seems simple enough, but please let me know if I'm mistaken. Basically what I need to know is whether I have to divide these 64 colours into 4 palettes for sprites and tiles, or if I can use multiple palettes as long as I don't exceed the 64 colour limit.

Any help would be greatly appreciated!

 

[slobu]

Hello. I'm a new member here and a longtime sega-fan who also happens to be a pixel artist. I really enjoy is making mockups based on the specs of older systems. I've done quite a few based on NES and Master System. I have a a fair knowledge about their limitations and such, but I want to move up a level and try one for my absolute fave system; The Mega Drive (or Genensis if you prefer that). So I hope someone here can clear some things up for me or at least point me in the right direction.

From what I understand the MD can show 64 colours on screen at the same time, based on a 9-bit RGB palette. That part seems simple enough, but please let me know if I'm mistaken. Basically what I need to know is whether I have to divide these 64 colours into 4 palettes for sprites and tiles, or if I can use multiple palettes as long as I don't exceed the 64 colour limit.

Any help would be greatly appreciated!

I'm not the definitive answer. Technically the great and powerful Wiki says "512 colors, 1536 including shadow and highlight mode"

All I know is that each tile can use one of four palettes. Each palette has 16 entries. 1 is used up by transparency and the other 15 are whatever colors you choose. Some try to fake tiles with more colors by overlaying 2 of them on top of eachother.

 

[Chilly Willy]

I'm not the definitive answer. Technically the great and powerful Wiki says "512 colors, 1536 including shadow and highlight mode"

All I know is that each tile can use one of four palettes. Each palette has 16 entries. 1 is used up by transparency and the other 15 are whatever colors you choose. Some try to fake tiles with more colors by overlaying 2 of them on top of eachother.

As mentioned, there are four palettes with 16 entries, where 15 are used for cells to display color and one transparent value. The entry that is normally transparent can be set as the main background color by a separate register in the VDP. This means there are a total of 15*4+1 = 61 colors you can display easily. Those palette entries use 9 bit RGB. Using priorities and/or specific colors in sprites, you can make certain pixels hilighted or shadowed. Shadowed merely cuts the RGB values in half, so if your RGB entry was $AAA (light grey), the shadowed value is about $555. Hilight cuts the RGB value in half, then adds $888 to the value. So a dark blue of $620 would become $310 + $888 = $B98, or a bright blue. Note that shadow/hilite works on the signal in analog, so the digital equivalent I describe isn't quite right, but close enough for government work.

Note that palette entries are 0, 2, 4, 6, 8, 10, 12, and 14 for each color. Each gun is 4 bits with the least significant bit ignored (14 and 15 are the same value). This is why the digital approximation I described is common - for hilite, just take the palette entry, shift it right 1 bit, then OR in $888. For shadow, simply shift the entry right one bit. Something like this: hilite = ((entry & 0x0EEE) >> 1) | 0x0888; shadow = (entry & 0x0EEE) >> 1; Quick, simple, and close enough to what you'd actually see.

Of course, you can always also change palette entries on the fly via the CPU or VDP DMA to get more than 61 colors. Many games change the palette on the fly; for example, the water on levels of the Sonic games is done by changing the palette on the fly.

 

[antime]

I can't find it anymore, but didn't Charles MacDonald write a test program that displayed all the possible Megadrive colours? A screenshot of that (taken via a capture card for maximum accuracy) would be a good tool to sample colours from.

 

[slobu]

I can't find it anymore, but didn't Charles MacDonald write a test program that displayed all the possible Megadrive colours? A screenshot of that (taken via a capture card for maximum accuracy) would be a good tool to sample colours from.

I think the OP wants to create authentic mock-up art. I'd say focus on coming up with a good common 16 color palette and stick with it for each mock-up screen. Worst case Genesis games look EGA. Best case like an average Amiga game. Dithering is also very important and lowering your allowed colors per mock-up kinda forces you in that direction.

Here is a palette I use in my games when I'm too lazy to pick out 4 different ones. Basically, I averaged the palettes of several 16 color machines and then manually selected a few to keep it closer to crayola crayon values.

' Transparent, Black, Orange, Yellow, Green, Blue, Magenta, Purple

' Brown, Lime Green, Sky Blue, Light Pink, Grey, Dark Grey, Red, White

 

[antime]

I think the OP wants to create authentic mock-up art.

Yes, but you could use the screen capture to construct your palettes of authentic colours rather than approximating RGB slider values.

ETA: I found an emulator screencap of Charles' demo here, but still haven't managed to track down the binary yet.

 

[TascoDLX]

ETA: I found an emulator screencap of Charles' demo here, but still haven't managed to track down the binary yet.

http://code.google.com/p/genplus-gx/downloads/detail?name=md_test.zip

Includes MD1536.bin (the 1536 color demo) and several other test roms.

 

[Biggie]

Thank you all so much for all the info. It's helped me quite a bit to grasp how the specs work. I won't try to implement any Shadow/highlight modes for now. It seems a bit too advanced for me right now, especially for the style I'm going with right now.

Here's a temporary mockup of what I got going so far. I've only just begun, so it's a bit empty and bleak right now, but I bet the colours will increase as I fill it with more background details and enemies.

the waves in the foreground is just placeholder to make it a bit more interesting.

One thing I've been curious about is how many graphic layers the MD can use? Right now I picture it using one for background, one for the action plane (sprites and the actual level), one for foreground, and eventually one for some kind of HUD (score/Life/Time and such). I figure I have to fake more layers and depth by scrolling the rows of tiles in the background in different speed. Please correct me if I'm way off here

 

[antime]

The Megadrive has a solid colour background, two tile layers and sprites. The official specifications say the sprite limitations are 20 sprites or 320 pixels per scanline, and 80 sprites total.

 

[Chilly Willy]

The MD also has a "HUD" layer that overlays part (or all or none) or layer A. It's called the Window or W layer. You can use it to make a display to the left or right side, or the top or bottom, or a combination of the two.

 

[antime]

Yes, but as the window replaces layer A there's still only two tile layers visible at any point on the screen.

 

[Chilly Willy]

Yes, but as the window replaces layer A there's still only two tile layers visible at any point on the screen.

Right - that's why I called it a HUD layer. It doesn't scroll, and it covers part of the scroll layers. It's normally used for status display on games that scroll since putting a status in the scroll layer itself would be a huge pain in the butt. That it replaces part of layer A is really of no consequence... it could just as easily be part of B or part of neither. It only matters when you are setting the priorities of the layers, otherwise it's just easier to think of W as a separate layer.

 

[antime]

It's just needlessly overcomplicating things. If the goal is to produce something that is reasonably similar to the Megadrive's specs the inner workings of the VDP are irrelevant.

 

[Chilly Willy]

It's just needlessly overcomplicating things. If the goal is to produce something that is reasonably similar to the Megadrive's specs the inner workings of the VDP are irrelevant.

Exactly my point - it's FAR less complicated to think of W as a separate layer that covers up part of layer A. Any other view is needlessly complicating things.