That was the most tedious thing - most of the scans we had were half-resolution. These are your brand new Sonic 2 scans (that Bubbler sketch existed): https://info.sonicretro.org/File:Sonic2_MD_TomPayne_GCZ_Chunks1.jpg https://info.sonicretro.org/File:Sonic2_MD_TomPayne_GCZ_Chunks2.jpg https://info.sonicretro.org/File:Sonic2_MD_TomPayne_Chunks.jpg Thankfully it might be the most interesting. Looks like Genocide City was brown and had green watery bits. Specifically this brown. I don't know if they were still playing the time travelling game at this stage of development, but there's definitely suggestions that this was going to be related to Metropolis in some way regardless. It's never wise to join up the dots like this, but Metallic Madness present/bad future? One is green-ish one is brown. Hmm.
That's fascinating. By the by, some of these colors are still in the final. The brown colors in the last line at the very least, match four of the colors in Metropolis Zone's 4th palette. This is probably old news, since that concept document with the palettes was uploaded a decade ago. But now that we know those colors were used for the majority of GCZ, and given the fact they're also used for MZ's brown parts, it leads me to believe that they may have recycled some of the GCZ graphics on Metropolis, just like the rhombus was recycled on early Metropolis 3. Said brown parts, which serve as decoration on MZ's floor and walls, may have been initially drawn for GCZ. They certainly seem go to with the aesthetics of that GCZ concept art, as well as The Machine (ignoring the different palette), whose graphics we know were also recycled from GCZ.
Yeah, as far as I can tell, the NTSC MD just uses the same pixel aspect ratio as normal 4:3 NTSC digital video (which IIRC is 10:11). So, that grid does appear to be for NTSC H40 mode. Remember, the more tiles you have horizontally, the thinner (or "taller", if you prefer) they will appear. H32 tiles actually appear wider than square.
Here's the main chunk of palettes in the earlier two Sonic 2 prototypes, for quick reference: (Left Nick Arcade, right Simon Wai's) I hope there's no incorrections, lots of copy and paste work there.
You're right about what standard NTSC PAR is, but not what the NTSC MD's PAR is. It's 32:35, actually.
Wait a god damn minute. That lobster enemy was used in the game gear version. Along with the Sonic 1 pig. THIS gives me more speculation that while Sonic 1 GG was being developed, they were handed assets from the in progress Sonic 1. Probably the same holds for Sonic 2 GG.
It's so weird that there's some LBMs which have the correct Mega Drive colors, while their corresponding Digitizer files don't... Did DIG2LBM "fix" some of those cases?
It's possible that it drops that extra bit when converting to MD. I just duplicate all four bits when converting to 8bit RGB in the conversion too, and I think Noesis does the same. I can dropping the bit and see what we get. Do you have a comparison of LBM vs DS paleette readily available? I'd like to disassemble DIG2LBM at some point soon.
Sure, here's the PNGs made from both "dino" files: LBM DIG "Gator" and "Snail" also have the correct colors, while the Wasp LBM has non-standard color values from the get go.
No, it doesn't drop any bits. I'd only put a night in on the format and dig2lbm-Noesis comparisons before this stuff ended up going public, so I didn't go too in-depth to see what dig2lbm was doing. But the notes I'd collected might still provide some insight. This is what I observed dig2lbm doing for color mapping: 0x1 -> 0x10 ... 0xB -> 0xB0 0xC -> 0xC0 0xD -> 0xD0 0xE -> 0xE0 0xF -> 0xF0 So 0x0FFF results in RGB(0xF0,0xF0,0xF0). But there is what looks like a hack in place where 0xFFFF results in RGB(0xFF,0xFF,0xFF). This only applies to 0xFFFF, however. So 0xFF0F, for example, will not result in RGB(0xFF,0x00,0xFF). It will still be RGB(0xF0,0x00,0xF0). My conclusion was that this is a hack that the author of the program made just to get white to be pure white instead of the usual thing of saying c = (c << 4) | c when expanding from 4 to 8 bits all the way up. This was also the only time I could see the program interpreting 0xF000 to mean anything. Beyond that, I also didn't see any evidence of the program dropping bits, seems to just be straight up shifting what's in the file with the 0xFFFF special-case. Again, though, I didn't try to disassemble it or anything, just made a few observations based on the end results. So, most likely, you're comparing with a source that also didn't do the | and is just leaving 0x0F empty. You can revert to dig2lbm colors by just saying color = color & 0xF0 except when color is 0xFF.
Interesting. Maybe one of those unknown values changes the behavior of dig2lbm... ? We'll have to play around with it.
I'm just opening the LBMs natively in Paint Shop Pro (which gives those correct palettes), in case it's relevant.
Here are a couple of automated dumps I made with the -dig3chack option in Noesis. It does the same "just shift and check for 0xFFFF" behavior that dig2lbm seemed to be doing. As far as I know, it'll produce identical results, but let me know if you find any exceptions. http://richwhitehouse.com/pubdata/tom_payne_png256_dig2lbmcolors.zip http://richwhitehouse.com/pubdata/tom_payne_png256_dig2lbmcolors_mask15.zip
Now I can confirm that those four shades of brown are... almost identical. The only difference is that the second color has a 0 "Blue" value in the Sandcrab while it's 32 in Wood Zone. EDIT: I'm guessing that Sonic's palette now matches Sonic Eraser's? EDIT 2: It does!=D PS: Rich, you're a genius.
Went looking for that page and couldn't find it. I knew it was so close to 10:11 that it might as well be 10:11 lol
Just so I understand for my own implementation, you're saying dig2lbm is just shifting the bits into the upper half of the byte, and not duplicating them, right? So i.e. 0x220c (4G4Rxxxx4B) becomes 0x20, 0x20, 0xc0 RGB? If that's the case I'll switch to that method of color conversion. (Currently I shift and duplicate to lower bits.) I didn't notice before but I now see the 0xffff exceptions in the palette data. Very peculiar.
Haha, so we've had Sonic's prototype palette for absolutely ages and just didn't realise it. Amazing what new light a new discovery can shed on existing info...! Interestingly, the shades of blue used are much more consistent with those used on the large Sonic on the title screen. I'm guessing they didn't think to update the title screen colours for consistency once they changed Sonic's palette, similar to how they didn't update the background colours to match when Green Hill's water colour changed. Seems the title screen slipped through the net on both those counts...!
