Indexed colour palette Image

You are not going to be able to make an indexed file in Photoshop that contains all of the Genesis's colors, because it has a set of 512 colors and Photoshop's indexed mode only supports 256. No matter how you slice that, you would be losing data.

Best you can do is have an image on-hand that contains all 512 colors, like this:

 

Another problem with MD colors is that different programs have different methods of converting the 9-bit values to 24-bit RGB, so colors may be darker or lighter depending on what you're using. If you want to ensure that the colors in your palette are directly matching MD colors in SonLVL, you can either save and reload the level if you import a palette from an image or enter 24-bit RGB values, or use the number boxes on the left side to change the colors.

 

I've been looking for a way to make 512 colors take up less space... I'm gonna reappropriate this image for Triad if you don't mind

 

For reference, on Sega Retro.

I forgot where I got the MD and the MS palettes, probably from the 1536 colors demo (the former) and from some doc on smspower (the latter). I created the GG palette from scratch with a small program I wrote, instead.

Back to the original topic, I'm not sure why you'd want more than 61 colors in your palette file, since you can't really display more colors than that on a Mega Drive without using black magic, not to mention that each 8×8 tile is furtherly limited to a single palette line.

 

That's true many old programs were lazy and simply bit-shifted the MD color component values once. An 0xE (hexadecimal) shifted 4 bits to the left (same as multiplication by 16) equals 0xE0, or 224 decimal. Add/Or the original value, as shown in nineko's link, and you get 0xEE (238).
However, that method is wrong. Because that way, pure white on the MD (0xEEE) would not map to pure white in 24-bit RGB (255, 255, 255).
The mathematically correct conversion formula is obviously RGB = 255/7 * (MD / 2).
That is, one step on the MD side equals 255/7 = 36.428571... steps on the 24-bit RGB side.
If you're worried about performance, instead of having to do floating point math for this, you could just as well precompute a lookup table - there are only 8 possible values on the MD side, after all.

Or you could use this little known trick (which is the reason why I'm writing all this):
To mathematically extend a value of size N bits to a value of size M bits (M > N), just repeat/duplicate the N bits over and over until all M bits are filled.
Example: let's take an MD component value of 0xC, which is actually a value of six (0xC shifted one bit to the right, or divided by 2). MD components are 3 bit, and six in binary is 110.
Let's extend those 3 bits to 8 bits by repeating:
11011011 = 0xDB = 219.
Test: 255/7 * 6 = 218.57... rounded = 219.

In C notation, that operation would be x << 5 | x << 2 | x >> 1.

PS: people have measured the voltage levels that the MD VDP outputs in order to get the "correct" values. They are slightly different, but I'd say it doesn't matter much, because the actual colors you'll end up seeing also greatly depend on your screen and its settings.

 

I once made a topic about this very issue, though at the time we somehow came to the conclusion that 0xEE was correct. SonLVL currently uses a precomputed table in MD mode. Oddly enough, S&KC doesn't mask off the low bit of each component, meaning you have 12-bit colors instead of the proper 9 bits.

 

I wonder why Puggsy's developers lied us in such a big way...



Can 68k make software scaling, or is it just another lie?

 

It's not 'lying', because things like sprite rotation and scaling can be done in software if you're clever enough. It's also possible to use that many colours on screen with 'black magic' as nineko said - the Puggsy devs were pretty smart.

 

Well, my only actual doubt was the colour count, since we all know that 32x does software rotation and scaling. I guess that 32bit or 16 bit only matters in how much effort will you have to put to do it then. But with 'black magic' I took that it was just not possible. I will take random screenshots in the game to see if I can count more than 61 colours.I imagine that it would be something very resouce demanding, right? I mean, no chance to see something like this in a sonic hack then?

 

Sonic games already show more than 61 colors in the water levels. You can change any palette entry at the middle of the screen, though it has to be done carefully to prevent snow from appearing around the picture. This is as much as I can explain without getting too technical, unless you know what an H-int is.

 

Is that any different from an H-blank? Y'know, that very brief period between the CRT monitor finishing one scanline and starting the next.

 

Oh, of course... what a dumbass I am. So, what's the real deal with the colours? Is it then 61 the maximium per scanline?
Also, can shadow colours get mixed with normal ones, or the whole mode has to be changed? Can it be done in a single frame, for example, to simulate glare?

 

It's the same. A horizontal interrupt (HInt) is triggered at the start of each H-blank.

Yes, it's pretty much 61 per scanline, but you can only change a limited amount of those from one scanline to the next, if I remember correctly.
I don't understand what you mean with the shadow colors. Shadow/highlight mode is either active or not. If it is active, it does influence the colors in combination with certain sprites and pattern priority bits. You can play around with this old program of mine to test it.

 

Actually, the MD only generates a horizontal interrupt every Nth scanline from the top of the screen/previous H-Int, with N being the value in VDP register $A.

 

Usually when tech members talk I just don't understand a thing, but I did learn something today, as small as it is. Thank you very much both of you.