Color counts per screen

[MottZilla]

I said it "seems inexcusable to me". As In I don't understand nor could I think of a reason for this to be the way it is.

Eke, I had not even though about Color RAM being embedded raising the cost. I suppose that makes sense. But that just leaves me to wonder what the cost would have been to double that amount, as then I could disagree or agree with their decision to go with the amount they did.

Sheath, are you kidding that no PCE or SNES game displays more than 32 colors on screen while displaying parallax or whatever other effect you are talking about? SNES can display 32 colors with ease. And they do. What effects are you talking about in these games?

There is no denying that SNES games can have more colors on screen than the Genesis and there is no denying that they actually do this. I would agree with you if you said that in total different colors, few SNES games ever show 256 unique colors on screen, as this is impossible without color arithmetic being used or possibly changing the brightness via HDMA.

Again, "inexcusable" is explained above. I would like to know what Sega's engineers were thinking when they went with this limitation. If it would have raised the cost of the system by something like 5 dollars, I have to disagree with them not doing it. But if it would have raised the cost by say 50 dollars, I could understand that's a hard sell back when you are competing with NES and can't see the future ahead. Basically my argument is that the cost of having additional color palettes is far outweighed by the benefit to games by having twice as much color available. I would say they didn't need to go as far as SNES or PCE did with 16 and I think it was 32 palettes. 8 palettes of 16 colors would have been sufficient I think to reduce or prevent people thinking the SNES or PCE were more colorful systems than the Genesis.

[sheath]

Let's not forget that we're blending "technical capability" with in game capability arbitrarily. The Genesis could technically display 1536 colors simultaneously in a static screen:



I think it's absurd to say that developers for some reason chose not to do this when it is now proven to have been possible. There must be some other explanation. Maybe they didn't know about the possibility of using Shadow and Lighting to this effect. Maybe they didn't think it mattered enough to delay the development process. It might be practically impossible to use this principle in a game at all (though I doubt that).

It is possible that Genesis/MD developers looked at what the system could do easily and decided to roll with what the system was designed for. I am assuming that they were looking at the results on a standard Television screen and were considering the "excessive" effects they could readily generate in this process.

[sheath]

Sheath, are you kidding that no PCE or SNES game displays more than 32 colors on screen while displaying parallax or whatever other effect you are talking about? SNES can display 32 colors with ease. And they do. What effects are you talking about in these games?

Sorry, I should have been more clear. I was referring to SNES/TG16 games, that display similar effects to top Genesis software, not displaying over 32 colors more than the 61 color limitation of most Genesis games. Any SNES/TG16 games I have seen with more than four scrolling background layers are limited to 90-100 colors on screen.

There is no denying that SNES games can have more colors on screen than the Genesis and there is no denying that they actually do this. I would agree with you if you said that in total different colors, few SNES games ever show 256 unique colors on screen, as this is impossible without color arithmetic being used or possibly changing the brightness via HDMA.

Right, and that is all that I am saying. No gameplay modes go over 150 colors in my experience. Perhaps tomorrow somebody will show me that random game that displays 150 colors with a realistically scrolling horizon like Sonic 2&3 or Thunder Force IV. I can tell you that it would greatly impress me

Again, "inexcusable" is explained above. I would like to know what Sega's engineers were thinking when they went with this limitation. If it would have raised the cost of the system by something like 5 dollars, I have to disagree with them not doing it. But if it would have raised the cost by say 50 dollars, I could understand that's a hard sell back when you are competing with NES and can't see the future ahead. Basically my argument is that the cost of having additional color palettes is far outweighed by the benefit to games by having twice as much color available. I would say they didn't need to go as far as SNES or PCE did with 16 and I think it was 32 palettes. 8 palettes of 16 colors would have been sufficient I think to reduce or prevent people thinking the SNES or PCE were more colorful systems than the Genesis.

I think the picture is very complex in the decision of what to include or exclude. Let's not forget that Nintendo is on the record for cutting hardware out of the NES, SNES and N64 in order to make a profit on each console sold. This includes, and is not limited to, video hardware that would have helped the NES with notable graphical glitches during scrolling, the DSP chip in the SNES and the sound chip in the N64.

Think large, and let's assume your $5 analogy is accurate. $5 times 1 million consoles sold is $5 million dollars, times 30 million it's $150,000,000. That's a whole lot to consider when we know in retrospect that the SMS and MD/Genesis strugged for every million sold and were produced by a company that was constantly under financial constraints.

[MottZilla]

That is a good point about the multiplying effect of the cost. But I think at 5$ you could just pass that on to the consumer. You don't have to make 5$ more profit per console. If you do, you are perhaps greedy.

I highly doubt that the shadow and highlight could be used in a game situation to the same effect that more palettes would have had. Honestly I agree with what I think tomaitheous said about they should have cut that feature out in favor of more palettes.

About no SNES game going over 150 colors, that's alot of colors, alot more than the Genesis gets. It doesn't need to be 256 or even 32 thousand. Realistic scrolling horizon. I'm not sure exactly what that means so if you could point out a youtube video and give the time stamp that would help. Maybe I can think of a SNES game with some effect like that. The only thing I can think of to support your argument that the SNES may not have been able to do it would be if the scrolling horizon type effect where certain rows scroll faster than others, would be that the Genesis has more time to process so that you could update each row independantly so say the foreground is so far ahead in scrolling than the distant horizon that you need not to update a whole vertical row of tiles on the scroll map but only the parts that are scrolling by faster and need to be updated with new map area. But ofcourse if you are looping a background, it doesn't matter then.

[tomaitheous]

I was referring to SNES/TG16 games, that display similar effects to top Genesis software, not displaying over 32 colors more than the 61 color limitation of most Genesis games. Any SNES/TG16 games I have seen with more than four scrolling background layers are limited to 90-100 colors on screen.

Are you implying that the number of scrolls (in whatever fashion) is related or limited to the number of colors "on screen" for SNES/TG? The more colors, the less scrolls or vice versa? I hope not, because that's ridiculous. There's no trade off as such.

I'll assume you didn't mean the above. But again, you're missing the point I make quite a few times in this thread; onscreen colors means less in relation to color detail than the number of subpalettes. I've already tried to explain to you, 1) you're not going to simply get "61" colors and by that you can't just simply add "32" more or whatever, 2) 40+ unique colors on screen via 4 subpalettes offers less applicable detail in color than 40+ colors onscreen with 16 or 32 subpalettes. You seem to fail to grasp this understanding. Genesis will uses all it's 61 color slots to show ~40 colors on screen. Because colors from one subpalette cannot be accessed in conjunction with another subpalette in an 8x8 pixel area (tile). This gets worse for sprites, because of group of 8x8 cells are all sharing the same single subpalette. The normal solution to when you need 6 existing colors from 1 subpalette, but 9 from another, is to create a whole new subpalette with this new set. Even though these two sets of colors already exist. On a 4 subpalette system, you quickly run out. So what do you do? You start limiting the number of colors across a range for a tile or whole sprite. Forcing them to use either lots of other redundant colors and there for limiting the range of colors detail has in general, or limiting most objects to 7-8 and dividing the 4 16color subpalettes into pseudo 8 8color subpalettes. Forcing the object to only use the upper or lower set of 8 colors from 16 (it's a little more complicated than that because of transparent/common color 0, but I'll keep it simple), then you can the ability to either cycle colors like a real subpalette or change out colors in that sub-subpalette on the fly like you could/would on a normal subpalette system. Either method, you're loosing detail in one way or another and imposing limitations on the art style. Most people look at TF4 and say, "Wow, those are some nice graphics for the Genesis". I look at TF4 and think, "Wow, I can really see how they tried to hide the color limitations of the system". It sticks out like a sore thumb. That's one of the reasons why I prefer TF3 over TF4 (that and gameplay/music is better IMO). Same with Final Fight on the SegaCD. Once I saw the pics of what the graphics really looked like in RGB, there's not way to un-see it anymore. Some of the graphic detail is worse than SMS. Down right NES level for a lot of enemies. In contrast, all the SOR games look better than FF port (and I don't think the SOR games look impressive at all color wise. Just average in that department for a Genesis game). Instead of making the necessary sacrifices to keep things respectable color wise, they went over board by stretching the subpalette system too far and the result is too thin (and dim. lower colors blend better).

Meh - FF always makes me go off on a rant. But back to my original point... Hmm. I forget what that was. I think I was leading up to the point that the number of unique colors isn't a direct measurement of detail via color because the subpalette system. Systems like the Genesis and Duo/TG16, you also have redundant colors because of the master palette - not just the subpalettes. This is more of a problem on the TG16 though, because of its huge number of subpalettes displayable at once without any tricks. It runs into the problem that the master palette isn't large enough in relation to the number of colors onscreen through the subpalettes. So when you have that much freedom on the TG16, you start running into redundant colors not because of subpalette restrictions (although that's still happening - you're still getting redundant colors because of cross over between subpalettes) but because you don't have access to additional RGB values that what the master palette gives you. So you end up using some the same colors again because you don't have anything else to pick from the master palette. On the Genesis, you have to deal with both. Both the smaller master palette and the limitation a subpalette system puts onto a graphic system.

Maybe I should try to explain the subpalette system a little more?

You're mostly likely familiar with PC colors and resolutions. And further still, you're probably familiar with 256 color mode of PCs. I'll lay that out so we are on the same terms:

In 256 color mode on a PC, any pixel is 1 byte in length. It can hold a color from 0 to 255, giving a total of 256 values. The pixel, or rather its value, is a pointer to a table. The table hold 256 defined colors. The defined colors, BITD, were 6bit for each R/G/B. Giving 262k master palette. So one (or more) of these entries in the table holds a direct RGB value/color. That's a palette system.

A subpalette system is a palette system with more than one palette. In the case of the 16bit era consoles, the pixels weren't 8bit but 4bit. And, they weren't just a 2D matrix of memory to form a picture like the PC used. That PC method is called a bitmap display. There are no restrictions as to what palette entry any of the pixels could use/point to. This is not the case with consoles. They use a tile based system and realtime moveable objects layers ontop of that (sprites). A tile is an 8x8 mini bitmap. Of those 64 pixels in that 8x8 bitmap cell, each pixel is only 4bits. The pixels can only point from 0 to 15 (16 values). Because the pixel width is so small and normally would only allow up to 16 colors on screen, the devised a method where there were multiple palettes. These multiple palettes were still only 16 colors in length. But - you could only assign 1 palette to an 8x8 area at a time. So any of those 64 pixels could only be assigned and access from one of these palette. Scrolling has no effect on this system. All the logic happens before scrolling. Sprites work on the same method. While a sprite entry in the sprite definition table could be 8x8 (1 cell) up to 32x32 (4x4 cells), they can only access one of those subpalettes. So a single 32x32 sprite still only has 0 to 16 colors to choose from, even though it's using a bunch of 8x8 cells to make up that dynamic image. Other sprite entries can be assigned to other subpalettes. But like tiles cells(8x8 mini bitmap), they can't access colors from two different subpalettes. Of course, for sprites - color 0 is never shown regardless of the palette chosen. And for tiles, it's the same. But if a BG layer ( A tile map. A map telling which 8x8 mini bitmap is show and where onscreen relative to a single larger bitmap existence) is closest to the bottom priority and *nothing* is going to show behind it, you can use color 0 as a "common" repeated color that all subpalettes for that BG layer use. That only works for 1 BG layer and only if nothing is shown behind it.

So while most games have all 61 colors used up between the four subpalettes, that is; even entry in color ram is holding a color value that's being used on screen, you don't necessarily have 61 unique colors on screen. And though you're counting unique colors as a representation of detail and depth, you're missing the importance of the redundant colors you *can't* count by such a method. Those redundant colors used in cross over for tiles or sprites, are directly effecting color detail in a compact area. Saying console X number of colors onscreen is misleading. The amount by which it is directly misrepresenting is related by the number of subpalettes available (assuming 4bit indirect pixels. Once you get other systems with lower/higher indirect pixel depth, things get more complicated to compare). If these were all bitmap based systems with blitters, then colors per pixel (onscreen color count) would be directly comparable. So while 481 colors or 241 (snes subpalette mode) might seem ridiculous because you don't see games display that many colors (and in the case of the PCE, anywhere near that number) - I would still say that number is somewhat representative if your going saying 61 colors for the Genesis.

What you're doing is taking 61 colors *capable* by the Genesis and directly comparing it with games that are in the 90-100 unique color count range of an output shot from the SNES or TG16. And then thinking it's really only 2 more subpalettes in difference. You don't take the unique color count, divide it by 16 or 15, and then say it's only the difference of X subpalettes. It doesn't work like that. Not even close. The amount of detail in color from four subpalettes to 8 is exponentially greater (it's greater than 2 times more subpalettes). While difference from 16(snes) to 32(pce), isn't as great of difference (excluding the master palette differences, which makes the difference that much less. And on that same token, it makes the difference between 4(Gen) to 16(SNES) subpalettes that much *more* greater).

I can make a kind of lame example:

Take the Genesis. For subpalette of 15 colors.

It's not uncommon to have 12-15 colors for a single BG layer, right? And it's not uncommon to have 12-15 colors for a sprite, right? Those are pretty reasonable expectation of the 16bit era, I would think. Actually, those are kinda low expectations. But here we go...

subpalette 0 = 15 colors for BG layer 0
subpalette 2 = 13 colors for BG layer 1
subpalette 3 = 14 colors for the main sprite character of the game
subpalette 4 = you'll have to squeeze the rest of the enemies into this one.

Now, chances are you're going to use some basic colors that tend to get reused quite a bit. Grays are one of them. Some blues and some reds. So chances are that not all the colors in are going to be unique.

Right away you can see the limitation in this type of setup. BG often have more that just 13-15 colors per whole layer. You'd normally have at least a few subpalettes per layer. In the early days, this didn't show out too much. Expectations and styles fit withing this style of setup. Ass games matured, so did their requirements. Instead of reserving a subpalette to a whole layer, you could reserve two subpalettes and create common use colors between the two BG layers to use. This means less max colors per cell to use, but you spread the wealth so to speak. The only problem, is the wealth isn't that big to begin with. And transition tiles tend to give you the most problem. A transition tile is when transition from one edge to another doesn't happen on a natural 8x8 edge, but in the middle of or somewhere in an 8x8 tile. That means this tile needs to have access to the two opposing edges colors. Maybe not all of them, but *enough* of them to make the transition seamless. To do this, this means you need to start subtracting colors from both BG subpalettes to make room for such transitions. You gain detail in transitions, but you lower detail in the rest and loose detail over all. With sprites, you don't want to really reduce the color detail of the main sprite. So one tends to make other "sprites" using the same palette of the main sprite when applicable (or forced). This tends to make the overall picture of the game look bland. The lack of differences in color range. For the last sprite palette, one tends to cut that in half. You might not have sprites that less detail in color, but more range in color.

Also, you need to remember (or know) that a game level design will more than likely have more colors than what you see on screen. Not because the system can't show that, but because it's related to content. You just happen to have capture an "instance" of the game, and count it colors. But really, level are actually bigger than when the display window is. If you could see the whole virtual tilemap, you'd get an increase in color in most cases. The Genesis could take advantage of this, but with the tiny amount of subpalettes - doing realtime transitions via updating palettes still isn't easy (I'm taking about transitions that need to take place mid screen while scrolling, not fades in/outs or such).

So you see, having just 4 *more* subpalettes, regardless if that number looks like 121 colors onscreen to you to as a figure, means much more freedom in attention to detail via color. 2 more would be better than nothing, but really four more would be reasonable and ideal. And like Mozilla said, even the NES had 8 subpalettes... back in '83! :/

I think it's absurd to say that developers for some reason chose not to do this when it is now proven to have been possible. There must be some other explanation. Maybe they didn't know about the possibility of using Shadow and Lighting to this effect. Maybe they didn't think it mattered enough to delay the development process. It might be practically impossible to use this principle in a game at all (though I doubt that).

It is possible that Genesis/MD developers looked at what the system could do easily and decided to roll with what the system was designed for. I am assuming that they were looking at the results on a standard Television screen and were considering the "excessive" effects they could readily generate in this process.

Just because you see a demo showing almost every color possible, using S/H and a series of mid screen change effects - doesn't mean that's practical for in game applicable sitautions. In almost all situations, it's not applicable. Extending the "amount" of onscreen colors like this doesn't really add any detail in color. It just bumps up the color count.

Look as this pic here:
or this one

These are the Amiga pics of Bonk. There's detail lost in the port due to the colors onscreen limitation of the Amiga. Tricks only go so far and are only applicable in certain situations. It's apparent to me that they boosted the onscreen color count to make up for the detail lost, by doing a vertical graduate effect on color #0 - effectively increase the colors on screen but uneffectively not increasing detail. You can do the same effect on all three consoles snes/duo/gen. But you rarely ever see it, if at all. You see it on quite a few Amiga games though. I personally think it doesn't really add much. It's a cheap trick. Cheap as in it's noticeable without much effort being put in.

Both the Genesis and Duo also have games that do mid screen effects. And it does boost the color count, but that's not the purpose. The purpose is usually transparent effects like water and such. Shadow/Highlight can be used to increase color and detail at the same time, but it can be pretty limiting. Being on reducing number of BG layers, increase vram for emphasizing masks (like silhouettes), reducing the number of sprites displayable per scanline, etc. Increased use of VRAM space is always a constant, regardless if you use BG or SPRITE S/H method. Using sprites to increase colors of other sprites, eats into your sprite per scanline limit (sprite drop out, blank out, or flicker if the programmer wrote a flicker routine. Flicker isn't automatic, it's done be the programmer to show the dropped sprite frames under said condition). If you planned to use it on almost all sprites, you just decreased your vram reserve for sprite frames by half. And, if your engine is uploading sprite frames during vblank - double the amount it needs to transfer because you need to update the mask frame cells too. Not very practical. If you go the BG route, then you loose a BG layer (there's only two of them) and you still have to double the tile size amount in vram to make room for the mask tiles of the S/H layer. Also not worth the trade off IMO. S/H was meant for doing just that, shadow or highlight FX. Not as some dual purpose device used to get more colors on screen. I would sooooooo rather have 4 more subpalettes *just* for sprites, than S/H any day. That's not to say you could cleverly use S/H here and there to help out. Like for instance; reducing the main character/sprite to only use 7 colors - but use one S/H sprite to increase that to double (or more! Depends if the logic overlaps and creates redundant colors). You've just freed up 8 colors for something else to use. You could use it here and there more often if you game doesn't use that many sprites. Like Sonic for instance. It doesn't have many sprites onscreen at once (with the exception for when you lose your rings). Sure, it doesn't drastically increase the colors by 1500 or even 40+, but it does help out and it *is* applicable in *more* conditions than most tricks to expand colors do. It's still not as nice as four more subpalettes, but it's better than nothing. You know, I feel like I've repeated myself on this several times already. Didn't we talk about all of this already in this thread??? I thought for sure we did.

Right, and that is all that I am saying. No gameplay modes go over 150 colors in my experience. Perhaps tomorrow somebody will show me that random game that displays 150 colors with a realistically scrolling horizon like Sonic 2&3 or Thunder Force IV. I can tell you that it would greatly impress me

Would a demo suffice?

[tomaitheous]

Inexcusable is a very strong word when we have no facts to add to the discussion.

It is inexcusable. And there are plenty of facts to support that. I can point out some simple ones: PCE was already out 1 year before the Megadrive with an incredible amount of 32 subpalettes. NES was out 5 years early with more subpalettes. Arcades predating the Megadrive were out with more subpalettes. The Megadrive design was supposedly inspired by the arcades at the time (read that from an interview with the designer of the system). On chip memory is expensive, but the PCE has 1024bytes of palette ram, compared to the Megadrive's 128bytes. That's more expensive on chip ram, not off chip. If the cost was that much of a problem, the Megadrive VDP has a means to use an external RAM DAC via the digital serial bus output. I don't think any disagrees that it was cut for cost reasons (and was originally there. This was discussed in another thread). I think the problem lies in that "was the cut worth it?". And my answer is no. This isn't the same as a bigger high speed DAC and running more data lines internally. The choice to cut out the second half of palette ram was a poor choice.

This isn't the case like for the PCE. Where the VDC is definitely running fast enough to handle/process another BG layer. Instead, those cycle slots are given to the CPU for free access to vram during active display. It's actually more CPU slots than the cpu can write/read in time. That's wasted bandwidth. Granted, the VDC wasn't made to specifically handle this accompanying CPU. It's a 16bit device and EVERYTHING has to be read/write or offset (address calculation) in 16bits. It's just that there is a pin to put the VDC in 8bit data bus compatibility mode (the DATA is latched on the address+1 write or read). The VDC being developed for other stuff than the PCE, was obviously made in mind to run with a faster CPU than 7mhz for mid screen updates (or possibly DMA device mid screen). That extra bandwidth should have went to process/fetch another BG layer. But that's more complicated and requires more parallel running logic than simply re-adding the second half of palette ram on the VDP of the Megadrive (or actually just keeping it there).

The consensus in this group seems to be that both the PCE/TG16 and SFC/SNES could do all of the effects, and scroll speed, seen in numerous MD/Genesis games.

PCE, not exactly. I believe I already went over the limitations of a single BG plane display? Can it do line scrolls line in Sonic back BG lake/water? Easily. It can do all sorts of line scroll effects; be it scrolling or warping or both. Can it do the foreground part at the same time? Obviously no. It doesn't have two BG layers. And it doesn't have enough sprite per scanline bandwidth to fake a foreground layer. A game made from the ground up with more open areas could be done, but that's obviously not the same type of game. If you asked my the same question for the SGX, then the answer would be an easy yes. It has the two BG layers to pull it off. It didn't sell even though it was backwards compatible with the PCE library and CD attachment. Guess why? Because the existing user base didn't care. The more double sprite bandwidth, double vram, double BG layers didn't matter. Its why it was never included into the Duo. Why shell out the cash to support it in the all in one system when the customer based was just as happy without it?

And the SNES? Yes. Definitely. While your busy being amazed with linescroll effects and lesser (multiple wider scrolls are like line scrolls with gaps. I.e. even easier to do), the snes was doing more intensive effects per scanline - just not on scroll registers (and sometimes on scroll registers at the same time). Mode 7 perspective view requires an update on EVERY scanline. It's not some automated thing. And you that plane needs to pivot, then you need additional work to recalculate it (even if it's a LUT, it still needs to be applied to every scanline entry in the HDMA table). I'm pretty sure I already mentioned that the space warping effect in Space Megaforce (the vertical one, not the mode 7 one - even though that one requires new updates to the transform and rotation regs EVERY scanline too). There's more work going on there then there is on the Sonic engine to do the linescroll + wider section scroll on the fake back layer with the water and mountains. Well, on the Genesis it has more overhead than the SNES (every scanline scroll entry in the scroll block has to be updated regardless if you doing said scroll effects in that area or not. And on both BG layers. For the Genesis. Unless you do H-INT method, but then you have the 50 cycle overheard of the interrupt handler on the 68k per call) - but I'm sure the slower clock speed of the snes bring them closer.

Are there any games for the TG16 or SNES that demonstrate the effects shown in Sonic 2-3&K, Streets or Rage 2, Thunder Force IV, Ranger X or others? If there are, do these games display over 100 colors simultaneously?

I'm not sure what you point is in relation to colors? Why do you specifically need to display over 100 colors? What's purpose of your point? Is it to somehow lessen the relevance of the poor color/subpalette ability of the Genesis? Or even remove it completely? If so, then you have a different tolerance to graphics then... well me anyway. I love the Genesis system and games. I just find it a waste that they couldn't have a little more color capability to go with the muscle. Especially considering the bar was already set by the PCE a year before. The Megadrive doesn't even come close to that bar. If you see good graphics on the Genesis/Megadrive, it's a testament to the artist. It's not a given. And there are some damn fine examples out there too. But that still doesn't detract from the reality and from the games that *did* suffer because of this hardware limitation (where as on the SNES or PCE, bad graphics are directly related to the artist ability).

[notaz]

I know this thread is about color counts/detail, but what about horizontal resolution? What I like about MegaDrive is that most games use 40 column display mode which is good for emulation on QVGA LCDs, i.e. various handhelds like GP2X (yes I'm from handheld scene). SNES and PCE games mostly use 32 columns, which means uneven scaling is required on QVGA to use full screen width.
I do believe this increased graphics level of detail when played on TV in the old days too.

[tomaitheous]

I know this thread is about color counts/detail, but what about horizontal resolution? What I like about MegaDrive is that most games use 40 column display mode which is good for emulation on QVGA LCDs, i.e. various handhelds like GP2X (yes I'm from handheld scene). SNES and PCE games mostly use 32 columns, which means uneven scaling is required on QVGA to use full screen width.
I do believe this increased graphics level of detail when played on TV in the old days too.

I like the increase res mode of 40 columns, not specifically because of the increased res output - but because how you can optimize for sprite better in this mode for the Genesis. Well, compared to its lower res mode. But if you're running double horizontal res to match the QVGA screen without blurring or nearest neighbor artifacts, you still need to do that vertically. Megadrive's 40 column mode isn't square PAR. If you don't care about PAR, it's nice I guess. But not *all* Genesis/Megadrive games run on 40 column mode. Quite few run in 32 column mode. Just as not all PCE games run in 32 column mode either. Some run in 44 column mode and some in 64 column mode (although quite rare for this mode). For SNES, 512pixel mode is extremely rare and has some sort of weird analog mix down mode (they call it 512 pseudo res mode), so like 99.99% run in 32 column mode.

Since you mention res. For composite (and RF) mode on the Genesis, 40 column mode produces artifacts on the NTSC color carrier. Almost like you're running a 4:2:2 color resolution. It's weird. Kind of reminds me fo the old home computer of the real early 80's or even CGA composite output cards. So you effectively get less color resolution do to the artifacting (RGB out fixes that though). Of course some games require this to pull off their "256 color" or such mode (I'm looking at you, Final Fight! And you too EC/EC2!). PCE and SNES have really crisp composite output. PCE output is surprisingly crisp in 44 column mode and impressive for 64 column mode - over composite. Hell, dithering in 64 column mode doesn't even work as good as Genesis 32 column mode ;>_>. PCE also does this thing where it shifts the color burst reference signal 180 degrees out of phase *every* other scanline. I assume this is to keep the color errors in check or something. Can't remember if the SNES alternates color burst signal that much (been a while since I hooked the snes to the scope). I haven't look at the Genesis composite output to see what it does.

Funny thing I've noticed, all the EU guys that do stuff/demos on the PCE always seem to use the mid res mode. Even when it's less optimal for sprites on the PCE. I'll never understand that. 32 column mode is nice in that it also requires less vram space relative to 44 (or 40 in Genesis case) column mode too. Although, on the Genesis with the color limitations - I'd probably go 40 column mode every time to help make up for it (and it's the best mode for sprites).

[sheath]

I was referring to SNES/TG16 games, that display similar effects to top Genesis software, not displaying over 32 colors more than the 61 color limitation of most Genesis games. Any SNES/TG16 games I have seen with more than four scrolling background layers are limited to 90-100 colors on screen.

Are you implying that the number of scrolls (in whatever fashion) is related or limited to the number of colors "on screen" for SNES/TG? The more colors, the less scrolls or vice versa? I hope not, because that's ridiculous. There's no trade off as such.

As ridiculous as it seems, I am. The historical record of published titles for all three systems shows this discrepancy. Rather than implying anything, I am actually working on a theory that there must have been some correlation between color counts and remaining CPU performance for software effects like line scrolling or parallax.

I'll assume you didn't mean the above. But again, you're missing the point I make quite a few times in this thread; onscreen colors means less in relation to color detail than the number of subpalettes. I've already tried to explain to you, 1) you're not going to simply get "61" colors and by that you can't just simply add "32" more or whatever, 2) 40+ unique colors on screen via 4 subpalettes offers less applicable detail in color than 40+ colors onscreen with 16 or 32 subpalettes. You seem to fail to grasp this understanding.

You seem to fail to grasp that I am trying to reduce these concepts to something the average website reader might understand. Until we have websites dedicated to hardcore coding as this one is, that are frequently cited by media run pages, I think I'm on even ground.

Also, I have no interest in fighting with you, and I will not reduce the importance of this conversation to the insignificance of your snarks. I am aware that this topic is as touchy as religion or politics for a great many people, and am trying to use objective means to arrive at a reasonable conclusion. The whole "MD/Genesis was stoopid" line is, well, stupid. You do realize that is the vast majority's ill founded opinion right?

Genesis will use all its 61 color slots to show ~40 colors on screen. Because colors from one subpalette cannot be accessed in conjunction with another subpalette in an 8x8 pixel area (tile). This gets worse for sprites, because a group of 8x8 cells are all sharing the same single subpalette.

The normal solution to when you need 6 existing colors from 1 subpalette, but 9 from another, is to create a whole new subpalette with this new set. Even though these two sets of colors already exist. On a 4 subpalette system, you quickly run out. So what do you do?

You start limiting the number of colors across a range for a tile or whole sprite. Forcing them to use either lots of other redundant colors and therefore limiting the range of colors detail has in general, or limiting most objects to 7-8 and dividing the 4 16color subpalettes into pseudo 8 8color subpalettes. Forcing the object to only use the upper or lower set of 8 colors from 16 (it's a little more complicated than that because of transparent/common color 0, but I'll keep it simple).

Then you have the ability to either cycle colors like a real subpalette or change out colors in that sub-subpalette on the fly like you could/would on a normal subpalette system. With either method you're loosing detail in one way or another and imposing limitations on the art style.

So when you see a large number of Genesis/MD games that display anywhere from 55-75 colors using the limits you describe, what do you see?

Most people look at TF4 and say, "Wow, those are some nice graphics for the Genesis". I look at TF4 and think, "Wow, I can really see how they tried to hide the color limitations of the system". It sticks out like a sore thumb. That's one of the reasons why I prefer TF3 over TF4 (that and gameplay/music is better IMO). Same with Final Fight on the SegaCD. Once I saw the pics of what the graphics really looked like in RGB, there's not way to un-see it anymore. Some of the graphic detail is worse than SMS. Down right NES level for a lot of enemies. In contrast, all the SOR games look better than FF port (and I don't think the SOR games look impressive at all color wise. Just average in that department for a Genesis game). Instead of making the necessary sacrifices to keep things respectable color wise, they went over board by stretching the subpalette system too far and the result is too thin (and dim. lower colors blend better).

I have emphasized some of your statements in the above paragraph for a purpose. You have misunderstood me and my intentions, I want you to see how I might choose to likewise misunderstand you in this very conversation.

I have a feeling that you are a very passionate and talented programmer. I have no experience or skill to challenge your opinions on the matter of programming. There is, unfortunately, another means by which I may attain data and draw conclusions, the historical record. In the historical record of published games, my assertions make a great deal of sense so far. In the historical record of published games I feel that there are a great deal of unanswered questions regarding these systems. If I felt otherwise, I would have already written a book and would be seeking publishers, rather than programmers.

Meh - FF always makes me go off on a rant. But back to my original point... Hmm. I forget what that was. I think I was leading up to the point that the number of unique colors isn't a direct measurement of detail via color because of the subpalette system. Systems like the Genesis and Duo/TG16 have redundant colors because of the master palette - not just the subpalettes.

This is more of a problem on the TG16 though, because of its huge number of subpalettes displayable at once without any tricks. It runs into the problem that the master palette isn't large enough in relation to the number of colors onscreen through the subpalettes. So when you have that much freedom on the TG16, you start running into redundant colors not because of subpalette restrictions (although that's still happening - you're still getting redundant colors because of cross over between subpalettes) but because you don't have access to additional RGB values that what the master palette gives you. So you end up using some of the same colors again because you don't have anything else to pick from the master palette.

On the Genesis, you have to deal with both. Both the smaller master palette and the limitation a subpalette system puts onto a graphic system.

Maybe I should try to explain the subpalette system a little more?

You're mostly likely familiar with PC colors and resolutions. And further still, you're probably familiar with 256 color mode of PCs. I'll lay that out so we are on the same terms:

In 256 color mode on a PC, any pixel is 1 byte in length. It can hold a color from 0 to 255, giving a total of 256 values. The pixel, or rather its value, is a pointer to a table. The table hold 256 defined colors. The defined colors, BITD, were 6bit for each R/G/B. Giving 262k master palette. So one (or more) of these entries in the table holds a direct RGB value/color. That's a palette system.

A subpalette system is a palette system with more than one palette. In the case of the 16bit era consoles, the pixels weren't 8bit but 4bit. And, they weren't just a 2D matrix of memory to form a picture like the PC used. That PC method is called a bitmap display. There are no restrictions as to what palette entry any of the pixels could use/point to. This is not the case with consoles. They use a tile based system and realtime moveable objects layers ontop of that (sprites). A tile is an 8x8 mini bitmap. Of those 64 pixels in that 8x8 bitmap cell, each pixel is only 4bits. The pixels can only point from 0 to 15 (16 values).

Because the pixel width is so small and normally would only allow up to 16 colors on screen, they devised a method where there were multiple palettes. These multiple palettes were still only 16 colors in length. But - you could only assign 1 palette to an 8x8 area at a time. So any of those 64 pixels could only be assigned and accessed from one of these palettes. Scrolling has no effect on this system. All the logic happens before scrolling. Sprites work on the same method. While a sprite entry in the sprite definition table could be 8x8 (1 cell) up to 32x32 (4x4 cells), they can only access one of those subpalettes. So a single 32x32 sprite still only has 0 to 16 colors to choose from, even though it's using a bunch of 8x8 cells to make up that dynamic image. Other sprite entries can be assigned to other subpalettes. But like tiles cells(8x8 mini bitmap), they can't access colors from two different subpalettes. Of course, for sprites - color 0 is never shown regardless of the palette chosen. And for tiles, it's the same. But if a BG layer ( A tile map. A map telling which 8x8 mini bitmap is shown and where onscreen relative to a single larger bitmap existence) is closest to the bottom priority and *nothing* is going to show behind it, you can use color 0 as a "common" repeated color that all subpalettes for that BG layer use. That only works for 1 BG layer and only if nothing is shown behind it.

So while most games have all 61 colors used up between the four subpalettes, that is; even entry in color ram is holding a color value that's being used on screen, you don't necessarily have 61 unique colors on screen. And though you're counting unique colors as a representation of detail and depth, you're missing the importance of the redundant colors you *can't* count by such a method. Those redundant colors used in cross over for tiles or sprites, are directly effecting color detail in a compact area. Saying console X number of colors onscreen is misleading. The amount by which it is directly misrepresenting is related by the number of subpalettes available (assuming 4bit indirect pixels. Once you get other systems with lower/higher indirect pixel depth, things get more complicated to compare). If these were all bitmap based systems with blitters, then colors per pixel (onscreen color count) would be directly comparable. So while 481 colors or 241 (snes subpalette mode) might seem ridiculous because you don't see games display that many colors (and in the case of the PCE, anywhere near that number) - I would still say that number is somewhat representative if your going saying 61 colors for the Genesis.

Aside from my persistence that onscreen color count is the only thing measurable from the games themselves in regard to color, I'm not sure what you think I don't understand. I did say that PCE/TG16 games needed to display 32 objects with unique color palettes in order to meet its 482 "maximum" technical display. My only assertion is that while the specs say 256 colors or 512 colors for the SNES or PCE respectively, that is not what they are displaying, which is true. Your statement here agrees with what was said earlier, that in order to have more 16 color palettes in color RAM, more color RAM than the Genesis had would be needed. So there was a technical/cost related reason for the Genesis' relative color limitation.

What you're doing is taking 61 colors *capable* by the Genesis and directly comparing it with games that are in the 90-100 unique color count range of an output shot from the SNES or TG16. And then thinking it's really only 2 more subpalettes in difference. You don't take the unique color count, divide it by 16 or 15, and then say it's only the difference of X subpalettes. It doesn't work like that. Not even close. The amount of detail in color from four subpalettes to 8 is exponentially greater (it's greater than 2 times more subpalettes). While difference from 16(snes) to 32(pce), isn't as great of difference (excluding the master palette differences, which makes the difference that much less. And on that same token, it makes the difference between 4(Gen) to 16(SNES) subpalettes that much *more* greater).

I'm actually not, and I'm not sure where you got that from. When I do direct color count comparisons I use the actual color count of screenshots used. So if the Genesis game maxed out at 55 colors on screen, that's what I write down, if the SNES game maxed out at 124, that's what I write down. In regard to the new comparisons with the icons, I've settled on 32 color jumps after 16 color NES titles (16-32-64-96-128,160) and as long as a game displays more than half way to the next 32 color mark I use that next icon. I am okay with the slight fudging of numbers because of what you say actually, if the onscreen color count got most of the way there, the colors must have been available. Again, if you can show me a method where I could easily show what palettes where in CRAM I would use it as well. As of right now I will show actual colors on screen via emulation, and then I will show what Irfanview sees from the Composite outs in an Apples to Apples comparison. Any other measurable aspects of the games that might exist will also have an icon created and an explanation in the legend.

I can make a kind of lame example:

Take the Genesis. For subpalette of 15 colors.

It's not uncommon to have 12-15 colors for a single BG layer, right? And it's not uncommon to have 12-15 colors for a sprite, right? Those are pretty reasonable expectation of the 16bit era, I would think. Actually, those are kinda low expectations. But here we go...

subpalette 0 = 15 colors for BG layer 0
subpalette 2 = 13 colors for BG layer 1
subpalette 3 = 14 colors for the main sprite character of the game
subpalette 4 = you'll have to squeeze the rest of the enemies into this one.

Now, chances are you're going to use some basic colors that tend to get reused quite a bit. Grays are one of them. Some blues and some reds. So chances are that not all the colors in are going to be unique.

If software counts a unique color from an emulation shot, it's a unique color. I'm not supposing anything when I make comparisons.

Right away you can see the limitation in this type of setup...

That is not in question. However I do find the comparison between one game that is documented to only be displaying 55 colors max and another virtually identical game that is documented to be displaying 124 or so very interesting.

Just because you see a demo showing almost every color possible, using S/H and a series of mid screen change effects - doesn't mean that's practical for in game applicable sitautions. In almost all situations, it's not applicable. Extending the "amount" of onscreen colors like this doesn't really add any detail in color. It just bumps up the color count.

Look as this pic here:
or this one

These are the Amiga pics of Bonk. There's detail lost in the port due to the colors onscreen limitation of the Amiga. Tricks only go so far and are only applicable in certain situations. It's apparent to me that they boosted the onscreen color count to make up for the detail lost, by doing a vertical graduate effect on color #0 - effectively increase the colors on screen but uneffectively not increasing detail. You can do the same effect on all three consoles snes/duo/gen. But you rarely ever see it, if at all. You see it on quite a few Amiga games though. I personally think it doesn't really add much. It's a cheap trick. Cheap as in it's noticeable without much effort being put in.

I think you've entirely missed my point here. I know full well that demos are not games, and I would suppose that if a demo demonstrates a capability that was never used in game there must be a reason. You also seem to keep equating more colors to more detail on screen, which I'm sure you don't mean as a defacto. I've seen 256 color games that looked bland, had bad art, etc, and 32 color games where literally everything stands out. Mortal Kombat and Eternal Champions on Genesis have the same color counts, but Eternal Champions looks much more detailed because of the optimized art style. If you want to get right down to my own personal opinion, I'd say that the difference between detail on screen between the three major 16-bit platforms was very small.

Both the Genesis and Duo also have games that do mid screen effects. And it does boost the color count, but that's not the purpose. The purpose is usually transparent effects like water and such. Shadow/Highlight can be used to increase color and detail at the same time, but it can be pretty limiting. Being on reducing number of BG layers, increase vram for emphasizing masks (like silhouettes), reducing the number of sprites displayable per scanline, etc. Increased use of VRAM space is always a constant, regardless if you use BG or SPRITE S/H method. Using sprites to increase colors of other sprites, eats into your sprite per scanline limit (sprite drop out, blank out, or flicker if the programmer wrote a flicker routine. Flicker isn't automatic, it's done be the programmer to show the dropped sprite frames under said condition). If you planned to use it on almost all sprites, you just decreased your vram reserve for sprite frames by half. And, if your engine is uploading sprite frames during vblank - double the amount it needs to transfer because you need to update the mask frame cells too. Not very practical. If you go the BG route, then you loose a BG layer (there's only two of them) and you still have to double the tile size amount in vram to make room for the mask tiles of the S/H layer. Also not worth the trade off IMO. S/H was meant for doing just that, shadow or highlight FX. Not as some dual purpose device used to get more colors on screen. I would sooooooo rather have 4 more subpalettes *just* for sprites, than S/H any day. That's not to say you could cleverly use S/H here and there to help out. Like for instance; reducing the main character/sprite to only use 7 colors - but use one S/H sprite to increase that to double (or more! Depends if the logic overlaps and creates redundant colors). You've just freed up 8 colors for something else to use. You could use it here and there more often if you game doesn't use that many sprites. Like Sonic for instance. It doesn't have many sprites onscreen at once (with the exception for when you lose your rings). Sure, it doesn't drastically increase the colors by 1500 or even 40+, but it does help out and it *is* applicable in *more* conditions than most tricks to expand colors do. It's still not as nice as four more subpalettes, but it's better than nothing. You know, I feel like I've repeated myself on this several times already. Didn't we talk about all of this already in this thread??? I thought for sure we did.

We have, and it was promptly forgotten in the reassertion that the Genesis design was arbitrary and stupid. I am not debating that more palettes is better from a developer perspective. I am debating that they make a significant difference in the end result. Noticeable sure, difficult for developers definitely, but a generational leap it is not. I am also pointing out that "technical capability" and in game performance are two entirely different things and should be kept seperate in discussions to avoid confusion.

Right, and that is all that I am saying. No gameplay modes go over 150 colors in my experience. Perhaps tomorrow somebody will show me that random game that displays 150 colors with a realistically scrolling horizon like Sonic 2&3 or Thunder Force IV. I can tell you that it would greatly impress me

Would a demo suffice?

Provided it was playable and didn't demonstrate obvious gameplay limitations (glitches besides), sure.

[sheath]

Here is my (faulty)attempt (based on incorrect specs that have been published for 15 years) to simplify and then analyze the matter on hardware engineering choices. For this comparison I will only discuss video processors and will leave sound processors out of the equation. For this post I will focus on the PCE and Megadrive hardware since they were released within 1 year of each other. Starting with the PCE we have the following chips dedicated to central processing and graphics:

CPU: 7.16 MHz 8-bit HuC6280 (custom 6502) -edited-
Video Processor: 16-bit HuC6270
Color Processor: HuC6260 (specifically manages the 16 background x 16 sprite 16 color palettes before output) -edited-
RAM: 8KB
Video RAM: 64KB

Now the Megadrive has the following directly related to central or graphics processing:

CPU: 7.6 MHz 68000
CoProcessor: 3.58 MHz Z80 (Sound or Graphics, and backward compatibility)
Video Processor: 16-Bit VDP
RAM: 64 KB
Video RAM: 64 KB

Now let's break down the most obvious differences in these configurations.

CPU:
The PCE uses a customized/optimized 3.6 Mhz iteration of the NES CPU, probably for ease of development with the already dominant Famicom in Japan.

The Megadrive uses a 16-bit 7.6Mhz 68000, probably for compatibility with Sega's System 16 arcade boards.

It is reasonable to assume that the 68000 cost more per chip than the HuC6280.

Video:
The PCE has two dedicated video processors, the 16-bit Hu6270 (VDC) for the handling of backgrounds and sprites, and the HuC6260 (VDE) to actually manage the 16x16 (16 palettes for the background, 16 palettes for sprites) 16-color palettes available before displaying (http://www.zophar.net/fileuploads/2/107 ... vdcdox.txt [see:5. The HuC6260 Video Color Encoder (VCE)]). So, one full chip in the system is dedicated primarily to managing "sub palettes" and outputting the video. The VDC is capable of 64 sprites at 16×16, 16×32, 16x64, 32×16, 32×32, 32×64 pixels. -edited-

The Megadrive has the 16-Bit VDP for handling backgrounds and sprites and output. Among other things, it displays two backgrounds and up to 80 sprites, the noted shadow and lighting effect, and handles line scrolling in either individual lines or or 8 line rows (leaving no hit to the CPU?).

Sprite pixel possibilities for VDP according to http://www.genny4ever.net/g4e_modules2/ ... l_overview

8*8, 8*16, 8*24, 8*32
16*8, 16*16, 16*24, 16*32
24*8, 24*16, 24*24, 24*32
32*8, 32*16, 32*24, 32*32

I think at this point we have established the superiority of the VDP over the Hu6270 VDC, but that leaves out one point. The Hu6260 VDE manages to give the PCE an advantage in "sub palettes", elevating the PCE from the MD's mere 4 16-color palettes to as much as 32 palettes total. No game actually displays all 32 palettes, and no game (based on this discussion) displays more than 128 simultaneous colors on screen, but the capability was there thanks to the VDE.

The Megadrive has one other video related processor, the 3.58 Mhz Z80. When the VDP was in Mode V, the Z80 was primarily used to manage the various sound processors the Megadrive could use simultaneously. However, the Z80 was also available for graphics processing (preprocessing?) which reputedly came in handy in real time polygonal 3D games and custom special effects such as those in Red Zone. In addition to that dual functionality, when the VDP was in ModeIV, the Z80 became the CPU for Sega Master System ROMs, allowing for full backward compatibility with the SMS/MarkIII.

RAM:
The PCE has 8KB of RAM and 64KB of VRAM, for a total of 72KB (totalled only for cost purposes). The Megadrive has 64KB of RAM and 64KB of VRAM for a total of 128KB of RAM. Since I have no knowledge otherwise, I will assume that each byte of RAM cost the same between the two systems, and between the system's RAM and VRAM. The Megadrive has 1.777 times the RAM that the PCE has.

Speaking strictly from a video related standpoint, I can find absolutly no substantial evidence to claim that the single weakness of the MD configuration, namely sub palettes, negates the numerous positive aspects in any way.

[MottZilla]

I don't understand why you belittle the PC-Engine's 32 "sub-palettes" cause no game you've seen used them all. I would agree they didn't need to go quite that far, 16 would have been enough. But it's not the hardware designers fault if you never saw software that you could tell used it. But even though you never saw it clearly being used in a game doesn't mean they didn't take advantage of all the sub-palettes.

I am glad that someone else thinks the same as I do that the 4*16 color palette in the Genesis was far too small. From a developer's perspective I can see how having this limitation would drastically effect all visual elements in your game. Increasing to 8*16 color palettes would give you so much more working room. As tomaitheous said it's not just about the total number of unique colors on screen. It's about how the game can use them. Since each tile can only have one set of 16 colors, you have 4 groups which as I stated before even the NES had more than that. In the early days of the Genesis this isn't a big deal, you are mainly up against the NES and the PC-Engine which I believe tomaitheous said many games were only using maybe 8 colors for tiles. But later on particularly going up against the SNES which had far more room to give different objects and parts of background color sets it showed.

Tricks to get more colors on screen are pretty irrelevant as they have very specific uses. They will never make up for the reduced amount of colors you have to work with for your background and more importantly sprites. It also makes it worse when you see alot of the very same colors being reused on screen and things start blending together. For example a gray suited character against a concrete looking wall.

I'm not arguing that you can't work around the limitation but I just think Sega shot developers in the foot by apparently cutting the extra palette RAM to save a buck. In general I hate whenever quality is cut in the name of making a buck.

As I stated before, if someone could restore the functionality of 8 * 16 color palettes in the Genesis that would be awesome to see what could be done with it.

[sheath]

I am not belittling more sub palettes, I'm just not agreeing that they are tantamount. So many other graphical elements factored into the engineering of the PCE, Megadrive and SFC that this one point simply cannot trump the rest. Beyond that, I maintain that the end result between these three systems (when displayed on a standard def television) is affected very little by the differences in color counts or sub palettes. The difference is primarily on the developer side, and each system has its own strengths and weaknesses in the games actually produced.

The TG16 was capable of nearly perfectly replicating Arcade titles based on hardware much more capable (See Ninja Spirit and the V90 processor it was based on). The Genesis was a consumer priced System 16 Arcade board with backward compatibility to the SMS. The SNES was an entirely unique approach at home console gaming with no Arcade counterpart, Mode 7 and the SPC caught so many eyes and ears that they cannot be ignored. This is where I would like the comparison to lay. Each system could compete in different arenas in very significant ways, but no system was the master of all things 2D or 3D.

[mic_]

CPU: 3.6 MHz 8-bit HuC6280 (custom 6502)

Where do these figures come from? AFAIK, the HuC6280 ran at either 1.78 or 7.16 MHz (approx). This was switchable through software, so games could run at the higher speed whenever they needed to, assuming that the ROMs they came on were fast enough.

Of course I've never done any measurements on the 6280 with an oscilloscope or anything, so I can't verify whether it's 100% true.

[sheath]

The TG16 specs are posted from, http://classicgaming.gamespy.com/View.p ... 33&game=15, which are repeated by numerous sources on the Internet and Usenet. I have seen the 7.16Mhz rating in various sources, including Wikipedia, but haven't seen anything about how, or whether, it was used. It would certainly explain how the Arcade Card games managed to pull of their amazing visuals though.

Updated the previous post regarding TG16 sprite sizes with:
16×16, 16×32, 32×16, 32×32, 32×64

[mic_]

how, or whether, it was used.

There were two instructions on the 6280 for that; CSL and CSH (Change Speed Low/High).
Charles MacDonald's PCE doc also says 1.78 and 7.16 MHz, and he usually knows his stuff.