Color counts per screen

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Post Reply
sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Color counts per screen

Post by sheath » Sat Feb 07, 2009 4:12 pm

Hello all,

When I am doing comparison pieces I like to list as many relevant provable facts as possible and emphasize those over my own observations. In the case of 8-bit and 16-bit games, I have been using Gif Movie Gear to analyze .bmp screenshots from emulators to give me a total color count of the screenshots taken. Gif Movie Gear does not analyze .png or .jpg screenshots as precisely, and tends to simply keep their color counts at a 256 palette. So, I have been using .bmp only and making sure the emulators were not using any filters when I took the screenshots. I thought that I would let this group review my methodology to be sure that there is not some better way to do this. Examples of my comparison pages using Gif Movie Gear are below.

http://www.gamepilgrimage.com/Gensvsgenesis.htm
http://www.gamepilgrimage.com/16bitArcadeComp.htm
http://www.gamepilgrimage.com/TheSegaGenesis.htm

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Sat Feb 07, 2009 5:19 pm

Irfanview has an option to report the total number of colors in a pic. It supports a wide range of formats.

In your animated gif, just reducing colors isn't going to be a good representation of seeing a transition between TV and unfiltered pixels. Plus, gif animation has that annoying limitation of 256 colors. I did something similar a few months back - http://pcedev.net/sf2_hack/tech/SSF2_filter_compare.gif

Anyway, reducing a pic down to 64 colors because that's what the system is reported as showing onscreen, has some flaws. 1) some shots might be less than 64 colors on screen, so unless you know that number you're going to be showing more. 2) color reduction works on a specific algorithm, it doesn't know what colors should be preserved - it predicts which colors are needed. This means colors get cut and/or colors get merged together. "True" colors might get mangled or lost. 3) The Genesis doesn't have a single 64color bitmap mode. It's not like the 256 color pixel mode of VGA. In *general* you have 4 subpalettes of 15 colors, plus 1 common color if it's used for tiles with nothing shown beneath them. Most games are in the 30-40 color count range because of this. You have redundant colors through out the 4 subpalettes, so that's what brings down the color count. It's the same with SNES, but it has 16 subpalettes of 15 colors (excluding the 256color per tile mode(7 and another mode) ). So that makes it less restricting. I know you're trying to give a simulation, but I just figured I'd through in some feedback.

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Sat Feb 07, 2009 5:41 pm

Very good, I'll try using irfanview this time around, if it contradicts Gif Movie Gear, I might have to redo all of the previous color count comparisons as well.

The reducing color pic is intended to demonstrate that with the "lossiness" of composite cables colors are blended. The end result is that more transition colors are visible on the actual television set than were output from the system.

I've seen the same actual color counts as you describe as well, the Genesis usually hangs around 40-52 colors on screen with rare exceptions, the SNES usually hangs around 90-150 colors on screen. The points I'm trying to make in the comparison is that the difference is not huge on a television set. This is, in my opinion, because most of the color differences are hidden in transitions, and both Genesis and SNES game characters were typically limited to 16-color palettes.

I find the biggest noticeable difference between Genesis and SNES graphics to be the bold Genesis colors versus the pastel SNES colors, and not anything directly related to simultaneous colors displayed. I'm off topic now though, I appreciate the feedback, irfanview does indeed look much more functional than Gif Movie Gear is at discovering the actual number colors on screen.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Sat Feb 07, 2009 5:58 pm

I find the biggest noticeable difference between Genesis and SNES graphics to be the bold Genesis colors versus the pastel SNES colors, and not anything directly related to simultaneous colors displayed.
I'd say that's more to do with the number of colors on screen for the Genesis. When you only have so many you can display at a time, you're more limited in the colors you pick. Take a look at this shot:
http://pcedev.net/final_fight/ffig0001_9bit.png

That's 94 colors on screen using the Genesis palette (RGB output of course). Sure the difference between the SNES palette and the Genesis palette is huge, but the limited number of colors onscreen and due to small number of subpalettes, greatly influenced artist's choice of colors per frame/area/whatever. The Genesis has less subpalettes than the NES, which totally baffles me. There really was no excuse for not having the sprites use their own separate 4 sub-palettes.

Yeah, Irfanview is a great utility :D

Jorge Nuno
Very interested
Posts: 374
Joined: Mon Jun 11, 2007 3:09 am
Location: Azeitão, PT

Post by Jorge Nuno » Sat Feb 07, 2009 6:11 pm

tomaitheous wrote:[...]There really was no excuse for not having the sprites use their own separate 4 sub-palettes.

Yeah, Irfanview is a great utility :D
The VDP seems to support that, but sadly it's not implemented in the Gen/MD

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Sat Feb 07, 2009 6:58 pm

Well, not knowing what the constraints were for chip manufacturing in 1988, I can't really say why the MD can't do what you say. It is notable, however, that the beginning ROM sizes were 4Mbit, and that the average Genesis game displays more sprite animation and has more background layers than the average SNES or PC-Engine title. All of the console designs suffered in some area.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Sat Feb 07, 2009 8:15 pm

sheath wrote:Well, not knowing what the constraints were for chip manufacturing in 1988, I can't really say why the MD can't do what you say.
It is notable, however, that the beginning ROM sizes were 4Mbit, and that the average Genesis game displays more sprite animation and has more background layers than the average SNES or PC-Engine title. All of the console designs suffered in some area.
The excessive scrolls in Genesis/Megadrive games are more of a attribute they focused on, than some exclusive feature. I mean, comparing to the SNES, which had more BG layers than the Genesis. It's not like it's cpu intensive to setup the a scanline X/Y position for any scanline - of all three systems, quite the opposite. It's just something the Megadrive game designers focused on. The NES on the other hand has very complex/convoluted method for changing the X/Y registers per scanline and can really eat into the cpu's resource per frame.

As far as sprite animation, all three have no problem updating VRAM. The SNES vDMA is just as fast as the Genesis for updating VRAM during vblank, and the PCE can fully read/write VRAM without delay during active display. The SNES even has a higher sprite per scanline count than either of other two systems, and yet you don't see games overly doing 'particle' effects.

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Sat Feb 07, 2009 9:42 pm

Couldn't that be said of any system's strengths? They focused on Mode 7 effects and used more simultaneous colors on screen on the SNES. But the fact remains that they didn't use as many frames of animations or background layers in most games. I would agree with your assessment if I could find any examples of SNES games with backgrounds like Sonic 2, or the number of enemies with constant animation as the SOR games.

I suspect that displaying more simultaneous colors on screen hogged more system resources than if the games ran at Genesis color counts. Anecdotal evidence that I'm right would be arcade versions of Genesis titles that lack parallax levels like Altered Beast. I'm not going to assert that this argument must be true until better evidence surfaces. But the fact remains that systems that use 90-150 colors, short of NEO GEO, just don't have as many animations or background layers/details as Genesis games do.

I do find your Final Fight pic very interesting. At first glance I would have thought that was a SNES palette. What's interesting is that Final Fight CD and Final Fight for SNES look very similar in palette, even though the SNES game is displaying more simultaneously ( http://www.gamepilgrimage.com/ffc1.htm ). Your picture doesn't look like either of them color wise, and the art decisions for the color transitions are very nice indeed. I wonder how much memory would be required to make a game around this design though. The Sega CD game clearly takes advantage of the 768KB RAM for more diverse detail elements in comparison to the 1024MB SNES game.

In this generation, I find that ROM is the biggest defining factor in how much detail can be factored in on screen simultaneously, and artistic design, coupled with the natural blending of the output, can disguise almost everything else. I would rather gamepilgrimage be more of a sum of all perspectives though, and that's why I'm asking questions here.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Sun Feb 08, 2009 5:25 am

sheath wrote:Couldn't that be said of any system's strengths? They focused on Mode 7 effects and used more simultaneous colors on screen on the SNES. But the fact remains that they didn't use as many frames of animations or background layers in most games.
Sorry if I wasn't clear. That was point :D The fact that they didn't do it meant they felt it hadn't as much value as other visual aesthetics. Having experience with coding on these consoles, I can tell you that setting up raster effects for multiple parallax (like the far BG of green hill zone) is dead simple and not cpu resource intensive. I would put it under 5% of cpu resource per frame for a change on every scanline. On the PCE, it's a little different story. Line scrolls for part or all of the screen and such as just as easy, but overlapping BG layers are not as easy. Since there is only a single BG layer, doing overlapping BG layers requires dynamic tiles and sprites. It can be done, but with all tricks comes limitations. Lords of Thunder on the PCE CD does a good job of hiding that fact.
I would agree with your assessment if I could find any examples of SNES games with backgrounds like Sonic 2, or the number of enemies with constant animation as the SOR games.
Sonic 2 isn't very impressive on a technical level. It's just a line update on one of the BG layers. No different than the fire level of TF3. Nothing the SNES couldn't do just as easily. Space Megaforce is doing the same thing, just looks different - but on every scanline. As far as animation, the CPU isn't 'drawing' the frames into memory. On both systems(SNES & GENs), the video processor has a DMA that handles super fast transfers to VRAM. This is all done during off screen. So the slower CPU speed of the snes has no relation to the rate of animation in that respect. It's just a matter of cartridge space. I can't think of any good examples at the moment. Check out Anomie's doc. Mode 1 has a 3rd BG layer. The SNES could do the Ocean side level of TF4 and even add to it. The Ocean side level is still just two BG layers, but updated X scroll register at key points to give the illusion. Notice the clouds are static in position to each other as the screen scrolls. If you look closely, you can see the 'line' (not literally) were the layers don't overlap into 3 different ones. Matter of fact, the boss ship requires the game to strip one of the layers because it itself is using a BG layer.


SOR3 is pure perfection. It's thee most impressive example of sprite optimization on the Genesis. Every character is draw to sprite specification limit. Down to the arm punching out and the upper torso width, etc in relation to the other sprites on the same scanline. Every thing is optimized to reduce sprite drop out (flicker or blank out if you prefer). The AI is perfect in that it keeps other enemies on screen out of the way of sprite overflow, yet remaining on screen to keep the appearance up. Some enemies will even walk off screen. Enemies fly farther and are more likely to land offscreen. A vertical lying enemy has more of a change to cause flicker, and the more lying on the same row the greater. Having them even partially off screen reduces this. It's a master piece of optimization IMO.
I suspect that displaying more simultaneous colors on screen hogged more system resources than if the games ran at Genesis color counts.
That's a common misconception. That the additional colors of the SNES or PCE or whatever system take up more 'resource' or processing power. That's just a myth. Because the tiles/sprites are all 16 color objects with sub palettes, having more sub palettes takes no additional storage or processing power. The PCE has 16 sub palettes for tiles and another 16 sub palettes for sprites. A total of 32 sub palettes or 482 unique colors on screen. It's simple multiplication. The object pixel * the palette number. You have to use a palette # regardless and it takes no extra cpu or video processing power to multiply a 1-4 or 1-8 or 1-16. The PCE graphic style of most games are simplistic because of the appeal. The PCE beat out the FC(NES) in Japan and lived on that simplistic design for quite a bit of its life. Minus a few exceptions, it was mostly later games that started to get away from that trend. A Genesis artist/developer would "hardly squander" the chance to show as many colors on screen as the PCE, and yet PCE developers did just that ;)

Anecdotal evidence that I'm right would be arcade versions of Genesis titles that lack parallax levels like Altered Beast. I'm not going to assert that this argument must be true until better evidence surfaces. But the fact remains that systems that use 90-150 colors, short of NEO GEO, just don't have as many animations or background layers/details as Genesis games do.
Like I said, it's just a matter of style. You really think other systems (including arcades) couldn't handle the same type of scrolling effects? If you don't have experience with console coding, you'd probably think so(I've seen this mentioned on youtube by sega fans). To me, a lot of Genesis/Megadrive games abuse/overuse parallax scrolling.
I do find your Final Fight pic very interesting. At first glance I would have thought that was a SNES palette. What's interesting is that Final Fight CD and Final Fight for SNES look very similar in palette, even though the SNES game is displaying more simultaneously ( http://www.gamepilgrimage.com/ffc1.htm ).
The SNES version has a really poor choice of colors IMO. I know the SegaCD version gets lot of praise as a game, but I've come to think that the graphics are worst than what they could have done. Take a look at this pic: http://pcedev.net/final_fight/ff_segacd.png

The guy in the back looks like he's straight out of an NES game. Thank god for the blurry composite/rf output of the Genesis. The poor guys with scart/RGB weren't so fortunate. I do think a Genesis port is more capable than this. There are such things a dynamic palette management and limiting the different colored enemies onscreen at once.

Your picture doesn't look like either of them color wise, and the art decisions for the color transitions are very nice indeed. I wonder how much memory would be required to make a game around this design though. The Sega CD game clearly takes advantage of the 768KB RAM for more diverse detail elements in comparison to the 1024MB SNES game.

Not any more memory at all. If the Genesis used 4 separate sub palettes for sprites, that pic would be totally possible. It's an exponential leap from 4 sub-palettes to 8. Tiles are limited to 4 sub-palettes because of the bits reserved in the tilemap, but sprites have no excuse. I'd give up other features of the VDP just for that, including shadow/highlight.
In this generation, I find that ROM is the biggest defining factor in how much detail can be factored in on screen simultaneously, and artistic design, coupled with the natural blending of the output, can disguise almost everything else. I would rather gamepilgrimage be more of a sum of all perspectives though, and that's why I'm asking questions here.


Some of the most impressive color fidelity in relation to color limit onscreen, comes from Genesis developers. Simply impressive.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sun Feb 08, 2009 11:53 am

tomaitheous>
The main reason why genesis game offers more sprites and more animations isn't related to VDP capabilities but to CPU.
Sending sprite image data to the VDP isn't the only task to do during the frame rendering, a big part of the job is the sprite "logic" calculation : move, collision... and on that point the SNES cpu is just weak compared to the genesis. Look at Gunstar Heroes, it's just impossible to get the same animation level on SNES. Same goes for Contra : the SNES version offers some transparencies effects, big sprites... but compared to the Genesis version it looks poorly animated. The best exemple are shoot'em all games, SNES can't compete the genesis here because these games requires many computations on sprite movement calculation.

By the way about sprite limitations, here're the exact number :
- SNES can display up to 128 sprites per frame (8x8 tile max).
- SNES can display 256 pixels of sprites per scanline.

- Genesis can display up to 80 sprites per frame (4x4 tile max).
- Genesis can display 256 or 320 pixels of sprites per scaline depending the video resolution.

But in the facts the SNES can barely handle 128 sprites per frame
or with very simple logic or/and lowered frame rate.
Genesis games sometime reach the 80 sprites limitation while keeping a solide 60 frame rate animation (contra does it sometime, making more sprites displayable on emulator ignoring the 80 sprites limitation).
SNES has very nice video capabilities, but the CPU is just too limited to use them at max.

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Sun Feb 08, 2009 4:11 pm

stef>
Yeah, I was referring to 'cell' animation specifically, not the number of sprites on screen or such (section/ball animation).

Throwing sprites around on screen is hardly taxing. Yeah, it's the object-to-object and object-to-map collision detection that takes up resource to process. A frame of animation has nothing to do with the collision process in 95% of the time in most games. If you have frame A and frame B, and then decide to add three cell frames in between - it's not going increase any logic other selecting an address to DMA from. You still have to test the object every frame, regardless if you change the x/y position or the actually cell data itself. And then you have explosions, particle effects, and other onscreen sprites that require no object or map intervention testing, that take up little resource to update.

So collision detection is happening at 1/60 regardless of a sprite has a new X/Y position or not. I'm not saying the SNES CPU isn't hindered by the slow clock speed, I'm saying that updating a 'frame cell' of animation has nothing to do with the CPU speed. The CPU isn't copying the cell data to VRAM itself, the video processor is.

The best exemple are shoot'em all games, SNES can't compete the genesis here because these games requires many computations on sprite movement calculation.
Shooters in general* are one of the more easier platforms for collision logic. Map collision detection can easily be exploited to use a single whole square per tile. It only requires one (pass) test to see if the collision box coordinates are in that 8x8 section. I think Space Megaforce is a good example, and as far as shooters go - it has a bit more collideable map areas than your typical vertical shooters.

By the way about sprite limitations, here're the exact number :
- SNES can display up to 128 sprites per frame (8x8 tile max).
- SNES can display 256 pixels of sprites per scanline.

- Genesis can display up to 80 sprites per frame (4x4 tile max).
- Genesis can display 256 or 320 pixels of sprites per scaline depending the video resolution.
I'm not sure how that is relevant. But..

SNES:
34 sprites per scanline or 272pixels - which every comes first. Check out Anomie's doc that I linked to previously.

The number alone is much more than the Genesis, and going by ratio to screen width it can show more pixels as well.

Those numbers look incredible (to me they do), but I like the Genesis' more flexible sprite size management. You can set a sprite size to 24x24 for example and be done with it. On the SNES, the sprite can only be 1 of 2 sizes, from the whole configurable list. IIRC, that's for the whole table, per frame. So either 8x8 and 32x32, 8x8 and 64x64, 16x16 and 32x32, etc. The Genesis' sprite system is straight forward and easier to work with in that respect. The SNES sprite system is convoluted. The sPPU looks like a patch work of last minute addons.
But in the facts the SNES can barely handle 128 sprites per frame
or with very simple logic or/and lowered frame rate.
Genesis games sometime reach the 80 sprites limitation while keeping a solide 60 frame rate animation (contra does it sometime, making more sprites displayable on emulator ignoring the 80 sprites limitation).
SNES has very nice video capabilities, but the CPU is just too limited to use them at max.
I agree :)

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sun Feb 08, 2009 4:50 pm

tomaitheous wrote:stef>
Yeah, I was referring to 'cell' animation specifically, not the number of sprites on screen or such (section/ball animation).
...
I'm not saying the SNES CPU isn't hindered by the slow clock speed, I'm saying that updating a 'frame cell' of animation has nothing to do with the CPU speed. The CPU isn't copying the cell data to VRAM itself, the video processor is.
Almost games use DMA for that, and yeah the SNES could theorically send as much data in VRAM than genesis per frame... but taking only this point in account about "sprite capabilities" is irrelevant.
Shooters in general* are one of the more easier platforms for collision logic. Map collision detection can easily be exploited to use a single whole square per tile. It only requires one (pass) test to see if the collision box coordinates are in that 8x8 section. I think Space Megaforce is a good example, and as far as shooters go - it has a bit more collideable map areas than your typical vertical shooters.
Collisions are simple to compute but you have to test them on many objects compared to others games and this is really CPU consuming.
SNES:
34 sprites per scanline or 272pixels - which every comes first. Check out Anomie's doc that I linked to previously.
What so weirds numbers O_o !? i always though we had the same limitation as Genesis hardware here.
Anyway having capabilites we can't use is just pointless :p

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Sun Feb 08, 2009 9:49 pm

Sorry if I wasn't clear. That was point :D The fact that they didn't do it meant they felt it hadn't as much value as other visual aesthetics. Having experience with coding on these consoles, I can tell you that setting up raster effects for multiple parallax (like the far BG of green hill zone) is dead simple and not cpu resource intensive. I would put it under 5% of cpu resource per frame for a change on every scanline. On the PCE, it's a little different story. Line scrolls for part or all of the screen and such as just as easy, but overlapping BG layers are not as easy. Since there is only a single BG layer, doing overlapping BG layers requires dynamic tiles and sprites. It can be done, but with all tricks comes limitations. Lords of Thunder on the PCE CD does a good job of hiding that fact.
Is this entire paragraph talking about raster effects alone, or parallax levels with raster effects? I am not aware of any technique that used raster effects to create parallax background layers. Forgive me, I am not a programmer and do not pretend to be. Myself, my sources, and my audience only knows what programmers say in interviews and nothing more. Raster effects, as I understand it, were used to create animated background elements like waterfalls, and are essentially an animated palette gradient like the Sega logo at the start of most Genesis titles.

In regard to independently scrolling background layers I understand several concepts. The standards for consoles are to have hardware limited background layers of 1-4 (up to the SNES). That is, in order for a background plane to be considered its own background technically, it would have to be hardware supported.

However, developers had various means for creating the effect of multiple scrolling backgrounds within the limitations of the hardware. These include, but are not limited to, rows of sprites, animated sprites, and line scrolling. The Genesis, while being technically limited to 2 backgrounds, could break them up into eight line rows or independently scrolling lines. While this hardware supported effect might not be hardware intensive, it was a distinctive characteristic of Genesis games over PCE/TG16 or SNES titles.

So much so that while some SNES and PCE titles do display more parallax layers than their technical limitations would allow, none display as many simultaneously as Genesis titles. This indicates some sort of processing advantage on the side of the Genesis. Since all Genesis games are limited to 64 colors on screen divided up into four palettes of sixteen, I *suspect* this limitation has something to do with it.
Sonic 2 isn't very impressive on a technical level. It's just a line update on one of the BG layers. No different than the fire level of TF3. Nothing the SNES couldn't do just as easily. Space Megaforce is doing the same thing, just looks different - but on every scanline. As far as animation, the CPU isn't 'drawing' the frames into memory. On both systems(SNES & GENs), the video processor has a DMA that handles super fast transfers to VRAM. This is all done during off screen. So the slower CPU speed of the snes has no relation to the rate of animation in that respect. It's just a matter of cartridge space. I can't think of any good examples at the moment. Check out Anomie's doc. Mode 1 has a 3rd BG layer. The SNES could do the Ocean side level of TF4 and even add to it. The Ocean side level is still just two BG layers, but updated X scroll register at key points to give the illusion. Notice the clouds are static in position to each other as the screen scrolls. If you look closely, you can see the 'line' (not literally) were the layers don't overlap into 3 different ones. Matter of fact, the boss ship requires the game to strip one of the layers because it itself is using a BG layer.

Are you referring to every level of Sonic 2, or the first level? Aquatic Ruins has to be more than a line update on background layers. I would assume that the presence of independently scrolling backgrounds behind and in front of the playing field be a combination of several workarounds, rather than simple line scrolling.
SOR3 is pure perfection. It's thee most impressive example of sprite optimization on the Genesis. Every character is draw to sprite specification limit. Down to the arm punching out and the upper torso width, etc in relation to the other sprites on the same scanline. Every thing is optimized to reduce sprite drop out (flicker or blank out if you prefer). The AI is perfect in that it keeps other enemies on screen out of the way of sprite overflow, yet remaining on screen to keep the appearance up. Some enemies will even walk off screen. Enemies fly farther and are more likely to land offscreen. A vertical lying enemy has more of a change to cause flicker, and the more lying on the same row the greater. Having them even partially off screen reduces this. It's a master piece of optimization IMO.
That is amazing, and much more optimized than I ever would have presumed.
That's a common misconception. That the additional colors of the SNES or PCE or whatever system take up more 'resource' or processing power. That's just a myth. Because the tiles/sprites are all 16 color objects with sub palettes, having more sub palettes takes no additional storage or processing power. The PCE has 16 sub palettes for tiles and another 16 sub palettes for sprites. A total of 32 sub palettes or 482 unique colors on screen. It's simple multiplication. The object pixel * the palette number. You have to use a palette # regardless and it takes no extra cpu or video processing power to multiply a 1-4 or 1-8 or 1-16. The PCE graphic style of most games are simplistic because of the appeal. The PCE beat out the FC(NES) in Japan and lived on that simplistic design for quite a bit of its life. Minus a few exceptions, it was mostly later games that started to get away from that trend. A Genesis artist/developer would "hardly squander" the chance to show as many colors on screen as the PCE, and yet PCE developers did just that ;)
I see that 482 number tossed around for the PCE about as often as I see 256 for the SNES, but the reality of actual commercial software is much different. I haven't seen the PCE display over 90 colors simultaneously, and I haven't seen the SNES display over 150 colors simultaneously during gameplay. Some SNES title screens and cut scenes approach 256 colors, but I have not seen gameplay scenes that do so. This indicates a resource issue to me.

Secondarily to that, do you mean to say that 32 distinct color palettes would not take up more ROM than 4 would? That does not make sense to me at all. If, furthermore, 32 distinct color palettes were to be displayed on screen simultaneously, would they not require more bandwidth and RAM than 4 distinct palettes would?
Like I said, it's just a matter of style. You really think other systems (including arcades) couldn't handle the same type of scrolling effects? If you don't have experience with console coding, you'd probably think so(I've seen this mentioned on youtube by sega fans). To me, a lot of Genesis/Megadrive games abuse/overuse parallax scrolling.
I would blame development time before I would say that an artist would intentionally limit background layers because he thought they were not aesthetically pleasing. As I mentioned above, the Genesis was capable, in hardware, of splitting up its background layers. I suspect that is why more Genesis games do so. You seem to favor the look of other consoles more, and that's fine, but in doing so you are overlooking advantages that the Genesis hardware actually has.
The SNES version has a really poor choice of colors IMO. I know the SegaCD version gets lot of praise as a game, but I've come to think that the graphics are worst than what they could have done. Take a look at this pic: http://pcedev.net/final_fight/ff_segacd.png

The guy in the back looks like he's straight out of an NES game. Thank god for the blurry composite/rf output of the Genesis. The poor guys with scart/RGB weren't so fortunate. I do think a Genesis port is more capable than this. There are such things a dynamic palette management and limiting the different colored enemies onscreen at once.
I totally agree, the Sega CD game has some artistic choices that I feel were not necessary. If both Final Fight SNES and Sega CD came out in the same month, and had the same development cycle, we could split hairs in this way. Since we do not know the human resources spent on either title, we can simply look at background elements of both games and wonder why they aren't more detailed. Yet both games still exemplify the standard advantages and deficiencies of both systems in the sprite limitations of the SNES game, and the color limitation of the Sega CD title.
Not any more memory at all. If the Genesis used 4 separate sub palettes for sprites, that pic would be totally possible. It's an exponential leap from 4 sub-palettes to 8. Tiles are limited to 4 sub-palettes because of the bits reserved in the tilemap, but sprites have no excuse. I'd give up other features of the VDP just for that, including shadow/highlight.

I really don't understand then. How can the screen have four more palettes of 16 colors each and that not impact the ROM, bandwidth, or RAM at all? Why would sacrificing Shadow/Highlighting in the VDP make more sub palettes possible?
Some of the most impressive color fidelity in relation to color limit onscreen, comes from Genesis developers. Simply impressive.
I think there are plenty of excellent art choices on all game consoles. I'm not sure how I would qualify "color fidelity", unless I believed games should appeal to photo realism (which in itself is not real). I am impressed with the talent and ingenuity it took to create games not only under these system's limitations, but under standard development cycle constraints as well. At the same time, I see budgets totally ruin art decisions. Especially in the case of ports by Probe, which chose dithering over recreating backgrounds with the Genesis palette. Overall, I think the systems had their own strengths and weaknesses that could be argued forever, but the games prove their equality.[/quote]

tomaitheous
Very interested
Posts: 256
Joined: Tue Sep 11, 2007 9:10 pm

Post by tomaitheous » Mon Feb 09, 2009 2:51 am

These are definitely some healthy questions you have and this is great for the discussion. I know my word alone probably doesn't mean much, but I can tell you that I have lot of coding experience in these matter both in graphic design and concept execution. So I'll whip some examples and explanations to help explain sub palettes and scrolls in usage :D Of course anyone else can jump in as well ;)

(Edit)

Is this entire paragraph talking about raster effects alone, or parallax levels with raster effects?
Both. Raster effects is a generic term meaning you change an attribute of the display on a given scanline. This could be; the X BG(s) position, Y BG(s) position, turning on/off sprites, turning on/off BG layer(s), changing colors, and other video registers that whatever specific allows to be changed. Now- in parallax scrolling you change the X position of the BG layer on a given scanline. If you use a sine table, you get a wavy effect. If you use a constant fixed or ratio'd addition to the existing X value, you get a different scroll speed (faster or slower). If you set the X reg to a non changing value, you get a status window. For parallax scrolls, the height of the scroll is just the difference between the two values set for the background X register. You see, if you scroll a background farther than what the width of the tilemap is, you get wrapping. The back ground will wrap back into itself. There other names for this; hsync, h-int, line scroll, etc. The idea is still the same - to change the X and/or Y position of the BG layer on a given scanline. With all three systems, you can do it on every scanline.

Say the background is scrolling at 1 pixel per frame. On scanline 42(from the top) you add +2 to the scroll value, on scanline 50 you add +3 to the scroll value. This gives you 3 multi-scrolling planes. The upper part of the BG is scrolling at 1 pixel per frame, scanline 42 through 50 scrolls at 3 pixels per frame, scanline 50 to the bottom scanline scrolls at 4 pixels per frame. If you wanted, you can do this for every scanline. When you do that, it's usually referred to 'line scrolls'. Because you're setting the scroll value on every sequential scanline. X position of the BG is not the only reg you can change. Changing the Y reg gives different effects. You can scale or squish the screen vertically. Squishing it by skipping Y positions on every scanline or enlarging it by repeating the same Y position for multiple scanlines. All three systems can do this. If you combine X and Y updating per scanline and use a sine table as an offset, you get an effect like in this video (3:07):

http://www.youtube.com/watch?v=eIFkFQjTAg0

So when I say that the multiple scrolls in the back layer of Green hill zone aren't impressive technically, I mean that other effects require updating *every* scanline(like in that video) unlike those parallax scrolls in Sonic. The SNES or PCE have no problem doing such parallax scrolls. Doing the calculations for these effects are resource heavy either. It's simple addition and most of the time it's just a index into a pre-calculated table(no one is stupid enough to calculate sine in realtime - at least I would hope not). You know the vertical levels in Axelay? That's not mode 7. It's simple Y scaling hsync effect. The PCE and Genesis can do the same (Chris Covell wrote a demo of the first level boss using that effect).

Now to get into some more detail. The way each system does the hsync effects are slightly different. I'll start with the PCE since this uses the traditional method. On the PC-Engine, you can set the video processor to create an interrupt on every scanline (all 262 scanlines - yes even the ones in vblank). An interrupt is when another device taps the CPU on the shoulder to perform a small task (or larger or whatever). The CPU takes a break from what it's doing, jumps to the interrupt routine, then jumps back and continues its work. This means the CPU doesn't have to sit there in a specialized timed loop wait for the correct time for update the X/Y/whatever video registers. On the Genesis, this method isn't the best for the 68k CPU since it uses a slow interrupt system (pushes all regs onto the stack in comparison to the PCE an other processors with push barely anything onto the stack for the call). To get around with a more efficient method, Sega chose to have a block in VRAM that contains scroll values for each scanline. So no interrupt is needed. The method of the SNES is similar to the Genesis, even though it has fast interrupt call like the PCE - the slower clock speed isn't really efficient for updating lots of video registers. In comes the HDMA system. DMA is a controller that copies nibbles/bytes/words/whatever from a source location to a destination. It's automated and doesn't require CPU attention other than to initialize. The SNES has 8 of these DMA channels, so it can transfer up to 8 different registers per scanline. This is also how you get perspective scaling for mode 7(the 3D looking plane). The HDMA channels have a block of memory like with the Genesis, but for more than just scroll registers and it exists in main ram(and can be reconfigured on the fly). The HDMA is fast and doesn't ask the cpu to do the work manually like an interrupt system would. Perfect for a slower processor too.

A side note: Without getting too technical in details, the SNES CPU runs at 2.68mhz, 3.07mhz, and 3.58mhz. A lot of early games ran in 'slow rom' mode which is 2.68mhz. Later games ran in 'fast rom' mode which is 3.58mhz. Technically the CPU runs at a constant 3.58mhz, but 'wait states' in slow rom bring down the speed. A stupid mistake on Nintendo's part was to also use slow RAM. The WRAM, or work ram has the same number of wait states as slow rom. The majority of instructions access ram and also memory mapped registers (ZP registers, or DP as they were renamed, are the life blood of the CPU's architecture). So even with fast rom, you're only achieving about 3.07mhz on average. Couple that with the fact that in 16bit mode (it can run in 8bit mode if selected), strictly 8bit operations are 25% slower in 16bit mode thanks to the stupid decision of WDC to use only an 8bit data bus. 16bit operations of course are faster than what there were in the 8bit previous model CPUs, but when it comes to console dev - 8bit operations are done more frequently than you think. And no, have a 16bit CPU doesn't mean you can do two individual 8bit operations at once. It doesn't work like that.

Back on topic. So you can have up to 224/240/whatever scrolls on all three systems. It's simple addition or indexing into a LUT (look up table). On the Genesis, you have two BG layers. They can overlap one another. If you change the X position at the right scanline/point of the tilemap, you can cascade the layers vertically. This is done in the Ocean side level of TF4. But since there's only two BG layers, you can't overlap these 'pseudo' as you scroll the map upwards or downwards because it doesn't have as many layers as the viewer thinks they are seeing. It's somewhat hard to describe if you don't have the technical background (and I'm probably doing a poor job of it ;) ). While the SNES can have up to 4 backgrounds, only 1 mode(0) uses it and it's not terribly useful. Each layer uses 2bit tiles (3colors +1 if nothing appears behind it). There is another mode though that shows 3 BG layers. Two layers are standard 4bit tiles with palettes and 1 layer with 2bit tiles and 4 palettes. So the amount of pseudo overlapping layers is some magnitude higher than 2 layers. And yet you don't really see SNES games take advantage of it. Compared to the many other effects the snes could show off, crazy parallax really isn't a pressing point. There are other effects that are more cpu intensive that the SNES does than doing some crazy parallax effects. It is a matter of choice. The Genesis lacks color sub/add, mosaic, scaling rotation, pixelizing, huge palette, etc. Developers add what they can to make up for the difference. Whether it be SNES, arcade, or whatever. Look at newer systems than the Genesis. You don't see the excessive parallax even though those system could pull it off even more so. The PCFX(since it never gets mentioned) has 6 BG layers and a much faster processor, yet you don't see massive parallax effects. Heh - all you ever see on that system is FMV and dating sims ;).

I think I forgot about the PCE. So it only has one BG layer, but can so up to 240 independent scrolling lines. Overlapping sections are usually done by dynamic tiles and sometimes accompanied by sprites. Doing scrolls like in Air Zonk or Coryoon are easy. They are just parallax done with an hsync interrupt. The parallax scrolling in Lords of Thunder first level (desert) for the sand is good example of dynamic tiles. This also allowed the large sand monster to appear to be it's own layer ontop of the parallax when in fact it's just part of the same BG layer. http://www.youtube.com/watch?v=PVqkODdAI4o @ 3:58. It's hard to see the parallax scrolling of the sand, but you've probably played the game already ;) Anyway, that's the guy I was referring to. This method *is* more processor intensive, but the PCE doesn't really have a choice if it needs overlapping BG layers. The PCE's processor is pretty fast ( a testament is the games lack of slowdown even on the hardest setting with 'revenge' bullets filling the screen at times while doing this method). The trick has its limitations. You're not going to see Sonic Green Hill zone on the PCE as is. It's just not feasible with a single layer. That said, you can do an approximation of it. PC-Engine SGX, of course has two independent BG layers (and sprite layers too).

Anyway, I hope that helps explain how parallax is basically the same method as other wavy or such screen type effects. And just because the SNES games don't necessarily show that style of parallax, doesn't mean it can't as it has examples of finer X/Y register updating effects, as does the Genesis itself in other games.



Myself, my sources, and my audience only knows what programmers say in interviews and nothing more. Raster effects, as I understand it, were used to create animated background elements like waterfalls, and are essentially an animated palette gradient like the Sega logo at the start of most Genesis titles.
That's color cycling. It's not done as a raster effect. Horizontal gradient bars of the early Amiga days and demos are raster effects. Color cycling is just offsetting the color in a sub-palette by 'rotating' and wrapping it, once every frame(s).

However, developers had various means for creating the effect of multiple scrolling backgrounds within the limitations of the hardware. These include, but are not limited to, rows of sprites, animated sprites, and line scrolling.
For line scrolling, see above. As for using sprites, that's usually more common on the PCE than the SNES or Genesis, since they rarely need assistance for multiple layers. Sprites are used in some situations for more complex masking of sprites and layers. But again, used much-much more on PCE since it lacks an additional BG layer. In Xanadu I or II for instance, when you go behind a structure(anything) and part of the sprite i s covered up by the BG layer. It uses dynamically placed sprites to mask and clip the player sprite as to appear to go behind the object. SNES and Genesis usually don't need this as they'll have 2nd BG layer ontop of the first BG layer, and scroll it at the same time - giving areas where the sprite will go behind BG layer 1 and be hidden.
The Genesis, while being technically limited to 2 backgrounds, could break them up into eight line rows or independently scrolling lines.
While this hardware supported effect might not be hardware intensive, it was a distinctive characteristic of Genesis games over PCE/TG16 or SNES titles.

So much so that while some SNES and PCE titles do display more parallax layers than their technical limitations would allow, none display as many simultaneously as Genesis titles.
See the first part.
This indicates some sort of processing advantage on the side of the Genesis. Since all Genesis games are limited to 64 colors on screen divided up into four palettes of sixteen, I *suspect* this limitation has something to do with it.
Not at all. The colors and palettes have nothing to do with the scrolling or its processing cost (or video processing cost). The colors also have no bearing on CPU resource or speed.

Are you referring to every level of Sonic 2, or the first level? Aquatic Ruins has to be more than a line update on background layers. I would assume that the presence of independently scrolling backgrounds behind and in front of the playing field be a combination of several workarounds, rather than simple line scrolling.
I was using the first level as an example of extreme parallax. See the first part for line scrolling and such.


I see that 482 number tossed around for the PCE about as often as I see 256 for the SNES, but the reality of actual commercial software is much different. I haven't seen the PCE display over 90 colors simultaneously, and I haven't seen the SNES display over 150 colors simultaneously during gameplay. Some SNES title screens and cut scenes approach 256 colors, but I have not seen gameplay scenes that do so. This indicates a resource issue to me.
And you wouldn't be the first to think that either. Most people are skeptical on the color counts of PCE. And I guess less so with SNES, but not that I've seen. It's usually exaggerated. Like, "That game looks like it's using all 256 colors onscreen", etc. And the SNES far exceeds the '256' color count onscreen when mosaic and color add/sub layer is used. But I usually don't count that because it doesn't work in the same method as plotting a tile or sprite pixel, i.e. it's not the same direct pixel method.

First the PCE and the common SNES mode. Every tile or sprite onscreen is only 16 colors. That's it. You can't define a color higher than 16 because it only used 4bits per pixel. This is done because 4bits is twice as smaller as 8bits to store in vram (not to mention the speed of fetching the pixel data during active display to build it out). But 16 colors really isn't going to cut. So the work around was to attach a palette number to each tile or sprite. This palette number indicates which 16 colors the tile or sprite is referring to. The video processor takes the current 4bit pixel and adds it to the palette number associated with that tile or sprite (or multiplexes it along with some conditional test zero logic, but end result is the same). The palette number is multiplied by 16.

So if a tile is using palette # 3, then all the colors in that tile would range from 48+1 to 48+15 (or $30+$1 to $30+$F in hex). Color # 0 isn't shown.

A tile or sprite can't access colors from two separate sub-palettes. So if one tile needs 8 shades of green and also needs 4 shades of gray and the those shades of gray exist in another sub-palette (group of 15 colors) but don't have any of those shades of green, you're going to have to create a whole new sub-palette just for that tile. You've now wasted 4 color slots in new sub-palette, that already exists in different sub-palette. You get redundant colors through out the sub palettes. The smaller the number of sub-palettes a system has, the less efficient it becomes as storing unique colors because of the redundant colors being stored. Sure, you can find a Genesis game that has 50 colors onscreen, near its maximum palette usage, but this still greatly limits how the graphics are designed. Ports tend to show this artifact more so. Games designed around the limitations will have greater color fidelity because they are designed around the limitation. Looking at Sonic 2, you'd think that the system would have no trouble handling other 'ports' of games (usually arcade). And when it doesn't happen, you hear stuff like "They didn't really try" or "lazy programmers/designers", etc. Hmm. I've seen to have drifted onto talk about the Genesis. Back to the palette explanation.

So the more sub-palettes the system can work with, the less restricted the system is in color usage. Does this effect storage? Slightly, yes. If you have a larger palette, you still have to store it somewhere, right? And that's true, but the sub-palette data itself is pretty tiny in comparison to many other structures or code in a game/program.

For one, you're not going to have a completely new palette for every color slot, for each level. But less say you did. It takes 2 bytes to store a color. That's 32bytes to store a single sub-palette. A 4bit 8x8 tile alone is 32bytes. And a level will have hundreds and hundreds of tiles, but only 16 sub-palettes for SNES and 32 sub-palettes for PCE. It's not uncommon to have 512 tiles in a PCE game - that's 16k. And then you have sprites on top of that which easily take up 32k or more. In comparison it takes only 1k for the whole set of PCE sub-palettes, and 0.5k for the SNES. Of course that's uncompressed. A simplest of compression schemes takes a full blown PCE palette down to 512bytes+32bytes or 0.53k.

But like I said, you're not going to have a totally new palette set per level. That's only worst cast scenario.

So you can see, it takes a fraction of a fraction of space for palette management and storage, and it costs no extra processing time by the video processor to output these additional colors.

There are PCE games that range into the 100-125 color count range and there are PCE games that range into the 20-40 range. The PCE's problem is that is can display soo many colors onscreen, that its 'main' palette definition is, relatively speaking, small. Even though it's the same size as the Genesis. Try to display all 482 out of the 512 colors on screen and not have it look like a rainbow fest ;)

So you're not going to see 200+ color count on the PCE, but that doesn't mean the sub-palettes are going to waste. 50 colors onscreen for the Genesis is more restrictive than same 50 colors onscreen for the PCE. Having more subpalettes allows one to spread out the redundant colors without as much restriction to tiles or sprites.

Here's an example an SF2 background that I did work on:
http://pcedev.net/sf2_hack/tech/sf2_guile.png
http://pcedev.net/sf2_hack/tech/sf2_guile_tilemap.png

It uses 62 colors, but 14 tile sub-palettes. Compare it to the original SF2 BG from the PCE SF2'CE game. It's more detail, more colors, and the same amount of storage. The first pic is the palette map overlaid ontop the image to show which tiles use with sub-palettes.



Secondarily to that, do you mean to say that 32 distinct color palettes would not take up more ROM than 4 would? That does not make sense to me at all. If, furthermore, 32 distinct color palettes were to be displayed on screen simultaneously, would they not require more bandwidth and RAM than 4 distinct palettes would?
That's just it, it doesn't require any more bandwidth. These console systems are not designed like PCs. Like when going from 8bit pixels to 16bit pixels required double the bandwidth, etc. It doesn't work like that. The Genesis already has previsions for handling an additional 4 sub-palettes just for sprites. It also has support to putting all the sub-palette ram externally of the video processor and have the cpu interface it without additional multiplexing logic.

PCE games were simplistic for design and appeal reasons, not hardware reasons. The same goes for Genesis and parallax. And the SNES under(?) usage of parallax. The SNES had a slow CPU, not a slow video processor. There a lot of SNES games that uses additional chips for speed up reasons, and yet you didn't see the usage of parallax go up ;)

Why would sacrificing Shadow/Highlighting in the VDP make more sub palettes possible?
Well, features come down to chip real state and cost. I personally think the Genesis would have benefited more from a separate 4 sub-palettes for sprites, than the shadow/highlight effect.


Note: I hope all this reads ok. It's late and I'm a bit tired.

Snake
Very interested
Posts: 206
Joined: Sat Sep 13, 2008 1:01 am

Post by Snake » Mon Feb 09, 2009 10:52 am

tomaitheous wrote:Throwing sprites around on screen is hardly taxing.
You would think so, but try it. It takes a fairly huge chunk of the CPU just to do that with all of them.
tomaitheous wrote:The CPU isn't copying the cell data to VRAM itself, the video processor is.
Worth mentioning here that SNES DMA is quite a bit slower than Genesis DMA...
tomaitheous wrote:34 sprites per scanline or 272pixels...
The number alone is much more than the Genesis
It's actually 32 or 272 but it doesn't really matter. Not sure what you mean by the second bit, the genesis can do 320.
tomaitheous wrote:On the SNES, the sprite can only be 1 of 2 sizes, from the whole configurable list. IIRC, that's for the whole table, per frame.
Correct, and yes it can be annoying. I also agree that parts of the PPU do feel a bit hacky. In general, though, I like it, it lets you do some nice stuff. I even like the CPU, but given the system that it's sitting inside, it IS hideously slow.

Post Reply