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?