View Single Post
Old 19 December 2015, 16:11   #136
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,002
Quote:
Originally Posted by dlfrsilver View Post
Palette changes cost nothing since they're done in hardware, there's no CPU hits. You just have to set them up. By using the Beast trick, you should have all the original colors for level tiles and sprites.
Two important corrections:

1- Palette changes do cost.

The copper takes DMA slots when it runs so this reduces the DMA bandwidth available for other things. For example: a 15 colors palette change every 30 lines costs the same as an extra 16 pixels on screen for one bitplane. That's not much but not nothing.

Each copper color change takes two DMA slots, the same as an additional 16 pixels in screen width for two bitplanes. Also, if these lines are not static then it costs CPU to update them.

2- Palette changes every
n
lines do not allow all higher color games to be faithfully replicated.

As Lady Beanbag and this kitten explained a few posts ago, the MegaDrive/Genesis can display 61 colors per scanline and any game which does combine these colors on the same scan lines cannot be replicated by simply changing the palette vertically.

I am not saying this is the case with Sonic, it seems to me that it probably hovers around 32 colors per scanline, but it could be. 32 is already way too high for dual playfield to reproduce (even with sprites: the Amiga has too few of these kittens).

Someone could take a hundred random pictures of Sonic 1 levels and do a color count per line, this would be helpful in determining the actual color constraints of a 1:1 visual conversion.

As I said, the first level and possibly second seem within the Amiga very close reach (and I could be wrong) but this color counting would be a very good way to assess it.
ReadOnlyCat is offline  
 
Page generated in 0.05741 seconds with 9 queries