Color counts per screen

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

Moderators: BigEvilCorporation, Mask of Destiny

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Fri Feb 19, 2010 8:39 pm

mic_ wrote:The Saturn was way too complicated, had an underpowered VDP1 which couldn't keep up with the PlayStation's 3D capabilities, and a large part of the good Saturn titles only saw a japanese release.

With the Dreamcast they corrected most of these problems and released a good console with a strong software library. But in the end it didn't sell well enough, and they decided to get out of the hardware business.
Despite all its glitches, I feel that the Saturn VDP1 was more limited by the bad dual sh2 design.

The Dreamcast really had no weak points, hardware wise... but Sega played off their good name by this point, and the more important developers just didn't care by the time.

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

Post by sheath » Fri Feb 19, 2010 9:58 pm

My opinion is that there is a way to measure some of the subjective matters we are talking about. To that end I have just completed the first of many analysis on the topic of color counts.

The first comparison pages under this new method are the Battletoads & Double Dragon (http://www.gamepilgrimage.com/content/b ... comparison) comparison pages on Gameplilgrimage.

In this preliminary comparison I have arrived at the conclusion that color output using Composite outputs can be measured and the data is reliable. Keep in mind that I have no interest in giving up on this idea until the numbers tell me I must, so if you think the idea is "ridiculous" go do whatever it is you do and read no more.

In this preliminary comparison I have found the following statistics from the data achieved.

There is no linear correlation between how many actual colors are being displayed and the Composite color count. This means that a simple multiple between any given amount of colors on screen and the Composite output does not exist.

So, I have focused on how reliable the Composite output color counts are in the same screen. I did this by taking multiple screenshots, using FRAPS png screenshots of the MPEG2 encoded video, of the same exact scene and recording the color data from each shot. Since the Super Nintendo and Genesis screenshots are using different colors and different amounts of colors, I have not combined the two sets of data for each version of Battletoads and Double Dragon.

Genesis Composite Color Data:
Average Range: 1696 colors (per screen)
Standard Deviation of Average Range: 1569 colors
Average Standard Deviation of Screens: 614 colors

Generally speaking, I am comfortable with saying that the average screenshot via Composite in the Genesis version of BT&DD is within 2000 unique colors of the color count listed in the link above. When the screenshots are mostly in the 40k-60k range, I find this an acceptable variation in the data for comparison.

SNES Composite Color Data:
Average Range: 1256 colors (per screen)
Standard Deviation of Average Range: 701 colors
Average Standard Deviation of Screens: 527 colors

Like the Genesis data, I can say the same for the SNES data only more so. Unless somebody wants to suggest a different methodology for collecting data via Composite outputs, I am going to continue collecting the same data on every comparison I create from now on. The purpose, as stated on the 16-Bit Comparisons page, is to further the understanding of game development during this era.
Last edited by sheath on Fri Feb 19, 2010 10:44 pm, edited 1 time in total.

mic_
Very interested
Posts: 265
Joined: Tue Aug 12, 2008 12:26 pm
Location: Sweden
Contact:

Post by mic_ » Fri Feb 19, 2010 10:43 pm

using FRAPS png screenshots of the MPEG2 encoded video
Why are you using a lossy video codec for recording test material?

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

Post by sheath » Fri Feb 19, 2010 11:13 pm

Why are you using a lossy video codec for recording test material?
Great question. The problem was presented to me, in here, that one would have to land upon a standard before one could measure anything regarding the actual console outputs. So, my present solution is to use the same video capture card's native MPEG-2 encoding capabilities to encode videos from every system within S-Video or Composite video capabilities.

All other connections from the systems to the video input are the same, and the codec settings are the same for every video. This is my attempt to measure the "lossy" subjective nature of SD-Video outputs from these generations in a standard. i.e. "apples to apples", form. Obviously an ideal scientific approach would be to use multiple solutions and find out which solution had the least variance, but this is the one that I have settled on given other cost factors.

I do not anticipate this to prove the superiority of any system. As I have seen that the data is consistent I do expect the results from more games to increase the understanding of game development from this era.

MottZilla
Interested
Posts: 40
Joined: Mon Feb 08, 2010 9:54 pm

Post by MottZilla » Sat Feb 20, 2010 2:57 am

Your "new test" makes no sense. Composite Video, is a poor encoding of the original Video signal on both SNES and Genesis. Plus you are introducing the NTSC color encoding to the mix. It seems to me more like you are just looking for any way to prove to people some point you have predetermined in your mind.

I'm not sure what this... apples to apples means. It's really quite easy to understand all this. SNES has 16 palettes of 16 colors (one transparent). Half are BG use, half are sprite use. That's 241 colors. Genesis has 4 palettes of 16 colors. That's 61 colors. That's how many any given game has available to use in a normal fashion. You cannot change thing or bend this to make your favorite seem better or worse than it is.

It's very simple really. Take Characters in video games for example. On Genesis if you use 15 color characters, you can have characters on screen with 4 different palettes. But you must share some of these colors with your background layers. So you have to decide how to divide these up. Do you just give background 30 colors in two 15 color sets, and leave another 30 in two 15 color sets for characters? Or do you go and divide them up further, dividing these palettes in half. Or do you try to share background colors with certain characters.

On SNES or PCE you don't have this issue at all. BG and Characters are separate. On SNES you have plenty of room for 8 different characters with their own palettes. On PCE you have room for 16 different characters with their own palettes. One advantage with this is for a character like Mega Man he can change his palette to have the weapon charging effect, or to signify equipping another weapon. You can do this on Genesis, but it comes at the cost of either not sharing the palette with other characters or having those objects palette effected too.

The overall "master" palette limitation is not so serious. It's the "active" palettes that you have to assign to background tiles and characters which limits you. When you think about it, 61 colors is very limiting. You have to be very clever and careful about what colors to use. The better made games work with this well, but even some of the good ones have this showing through.

By the way, a great example of the Genesis's serious palette problems is the game Mortal Kombat. Both Genesis and SNES versions have 4bpp tiles. Both systems have to deal with a Background, two characters, and a small status bar area at the top of the screen. So at a minimum, two palettes are going to be taken up by each fighter. That leaves only 2 for each background and the status bar. And that doesn't take into account projectiles. I was always bothered by Cage shooting a "gray blob" rather than the green energy ball he is supposed to. The other characters fair a bit better as I recall. But hopefully you get the point. On SNES this wasn't an issue. Backgrounds were free to use up to say 7 of the color palettes leaving one for the status bar probably. Then for the characters you have 8 of them. So you have plenty of room for each character and any projectiles. You could even make the timer a sprite and save on colors used for the status bar.

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

Post by sheath » Sat Feb 20, 2010 12:18 pm

As I said, I am set on proving or disproving whether it is possible to measure the subjective aspect of playing these games on the output they were intended for. To that end, I have so far taken hundreds of movies and tested five different capture cards to arrive at this conclusion. Data taken from the native MPEG 2 encoder of this card is reliable.

After I do a few dozen more comparisons (i.e. hundreds of screenshots with representative color data takn) I will have enough data to start running numbers. At this point I don't know what they will show, but we will know whether the NTSC format created a law of diminishing returns in regard to colors when I am done.

Emulator shots will only be used to prove what the actual chip output was in regard to colors, but this proves nothing about actual system output.

MottZilla
Interested
Posts: 40
Joined: Mon Feb 08, 2010 9:54 pm

Post by MottZilla » Sun Feb 21, 2010 4:16 am

My point was your "test" is meaningless. It doesn't matter how many colors your capture hardware sees. This really isn't some big mystery. Defects and impurity in your video captures doesn't magically make the games better and say they are displaying more colors.

The only thing that matters is what the hardware is doing. There is always some color variation due to the calibration of the TV and signal noise. You seem to want to find some device in which you can say the Genesis performs better than it does. Or to say that the SNES performs worse than it does. There are cold hard facts. 4 * 16 colors vs 16 * 16 colors vs 16 * 32 colors for Genesis, SNES, PCE. You can't exactly spin it some other way.

I have no idea what exactly you are trying to prove, but if you think it's going to vindicate Sega, it won't.

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

Post by sheath » Sun Feb 21, 2010 7:56 pm

My premise is simple, if we are going to make subjective qualitative statements about the games, then we need to consider what conditions the target audience was viewing the games under. If you can't see the logic in that we genuinely have no further basis for a discussion on the matter.

Keep in mind, that I am not trying to declare the absolute superiority of one system over the other here, which seems to be where your bias lies. I am saying all of these systems have their own strengths and weaknesses.

I am also saying that developers back then didn't work from a reverse engineered perspective with VGA monitors and HDTVs as the target. Historically speaking, my approach is very relevant. From a developer's standpoint, at least one who wants a greater understanding of development during this era, my point is relevant. My data is consistent within an acceptable variance, which I will post in more detail today or tomorrow. How Composite affected the "pure" chip or emulated image is relevant to the discussion.

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Feb 21, 2010 8:45 pm

Much of the time, the reason games don't look better (or not much better) on other platforms comes down to the most basic of all reasons: money. A company is not going to spend money on the artists needed to make twelve versions of the same artwork. They'll aim at the lowest common denominator and leave it at that. So they'll pay some artists to convert an arcade game's graphics to the Genesis, and keep the same graphics for every other platform, even if they're capable of more. It has NOTHING to do with technical reasons. Just because a platform can show sixteen different palettes doesn't mean the company will pay for artwork that uses them, not when they already have "adequate" artwork that uses four palettes.

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

Post by sheath » Sun Feb 21, 2010 10:08 pm

Chilly Willy, thank you for your response. I agree that there were probably not technical reasons, related directly to the actual chip outputs, behind the artists decisions in any given game. I also agree that funding, and the arbitrary decisions made by corporations regarding their own bottom line, probably affected development significantly more than technical limitations did.

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

Post by tomaitheous » Sun Feb 21, 2010 10:26 pm

My premise is simple, if we are going to make subjective qualitative statements about the games, then we need to consider what conditions the target audience was viewing the games under. If you can't see the logic in that we genuinely have no further basis for a discussion on the matter.
So subjective and *not* objective. Don't you think that conflicts with your "scientific method"?
Keep in mind, that I am not trying to declare the absolute superiority of one system over the other here, which seems to be where your bias lies. I am saying all of these systems have their own strengths and weaknesses.
I don't see any bias in motzilla's comments. If anything, he speaks specifically in absolute specs, facts, and knowns. Please point out where he's being bias? You're the one boasting small advantages of one system, and putting down fairly large advantages of the opposing system, on your site. That can't be construed as anything but biased. Or at minimum, as suspect.
I am also saying that developers back then didn't work from a reverse engineered perspective with VGA monitors and HDTVs as the target. Historically speaking, my approach is very relevant. From a developer's standpoint, at least one who wants a greater understanding of development during this era, my point is relevant. My data is consistent within an acceptable variance, which I will post in more detail today or tomorrow. How Composite affected the "pure" chip or emulated image is relevant to the discussion.
Reverse engineered perspective? What does that even mean? And why do you keep mentioning HDTVs? Is there some common method or gauge nowadays in which people are comparing the Genesis to the SNES that irritates you? You're pretty adamant to counter the fact.

Here's one of the problems you have. First, you mention on your site that everything on your site is relative to the US. I willing to bet the vast major of gamers ran RF than composite BITD. If you're trying to directly compare what the majority used, why aren't you using RF?

Second, the composite captures you have don't represent REAL composite on an NTSC TV. Nor does using a 32x composite for Genesis, to get more saturation and a little clearer composite. Your captures also don't emulate the missing scanline gaps on a real SDTV too. You don't capture full 720 res and if you do, your scaling introduces additional anomalies not custom to SDTVs. Let alone additional filtering done on the capture card side, etc. There are *SO* many variables with composite (and RF) and that the signal needs to be interpreted on a few levels before you even get RGB to the CRT in the SDTV. You're making exceptions for your shots and think RGB captures is out of the question. That in itself is questionable. If anything, RGB captures (since you don't like emulation shots for whatever reason) would eliminate many of the variables and differences between composite captures and real SDTV output. You'd still be missing the "scanlines" of an SDTV, but at least you'd be closer.

And implying that the systems internal capability is not the end all and that "composite" is part of the final graphics - even though RGB was a perfectly valid output on both systems. You turn around and make exceptions to exclude things that don't fit your point of view (or to dismiss know facts/specs) or just outright ignore them. Nobody is saying you're making *one* system look better than the other, more like we're (well, MottZilla and I at least) are saying that you're making handicaps for a system to make the differences closer together - under some guise you label as "scientific method".

There's also the thing with your counting colors in the composite captures. What is that??? I mean, there are soooo many reason why that is just wrong. I would think this wouldn't need *any* explanation as to why this is a bad idea. Just looking at the *two* color part of the image, white text on black background - shows up to 37 "colors" from one of your captures. And I use the term "color" very loosely.

It basically boils down to this; if you're just comparing some games between systems - that's fine. Even if you say,"You know what, I just want to make some comparisons between the system as how I played them as a kid/teen/whatever BITD". But when you start counting colors in composite captures (this makes my laugh each time I think about this) and you start listing systems specs, making judgments on the systems capabilities, etc. You're crossing the line between genuine observation and strictly technical comparison. Well, you're really blurring that line. To fit your agenda.


Much of the time, the reason games don't look better (or not much better) on other platforms comes down to the most basic of all reasons: money. A company is not going to spend money on the artists needed to make twelve versions of the same artwork. They'll aim at the lowest common denominator and leave it at that. So they'll pay some artists to convert an arcade game's graphics to the Genesis, and keep the same graphics for every other platform, even if they're capable of more. It has NOTHING to do with technical reasons. Just because a platform can show sixteen different palettes doesn't mean the company will pay for artwork that uses them, not when they already have "adequate" artwork that uses four palettes.
This generation seems to break that trend more. You could see that trend more in last generation and this. At least, going from memory of last generation.

MottZilla
Interested
Posts: 40
Joined: Mon Feb 08, 2010 9:54 pm

Post by MottZilla » Mon Feb 22, 2010 2:36 am

sheath wrote:Keep in mind, that I am not trying to declare the absolute superiority of one system over the other here, which seems to be where your bias lies. I am saying all of these systems have their own strengths and weaknesses.
I can agree both systems had strengths and weaknesses. But I don't have a bias. I'm not trying to declare one system the victor. I'm only pointing out facts. You don't seem to care what the facts are if they don't suit you. Atleast that's how it seems.

This whole thing about how many colors you capture from the output of the real system is a flawed idea. Depending on the quality of the video circuitry, it would seem to me the poorest one will actually generate the most different colors. The cleanest signal would generate the closest result to what the hardware actually does.

While Chilly Willy has a point that money for development is a major factor I find it hard to believe that one of my example games was held back by money. Mortal Kombat and Mortal Kombat II were hugely anticipated. They clearly suffer due to hardware limitations. While it's possible with some more money thrown at development it could have perhaps improved a little it still runs into the wall that is the hardware limits.

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

Post by sheath » Tue Feb 23, 2010 12:11 am

Okay, now that I have checked and double checked and then checked some more. Here is the data from my sample study on Composite video outputs of the Genesis and SNES using BT&DD.

This only tests the reliability of the color counts in any given identical screenshots taken from different frames of the MPEG 2 encoded video. Some pertinent terms:

Sum of Squares (SOS) is the sum of the color count in one individual png (score) minus the average color count of all identical screenshots taken ("true" score).

Variance = SOS / ((number of same screen pngs) - 1)
Standard Deviation = Square Root of Variance
Reliability = 1 - (Standard Deviation / Variance)

The closer a Reliability score is to 1 the more reliable the measurements are. Reliability means that the score is within a predictable range, and thus the next time I take a screenshot from the same scene in the same video I will get a similar score within the same variance.

So here are the scores:
Genesis BT&DD:
Average Standard Deviation: 614.2594144
Average Reliability: 0.997722412
Minimum Reliability: 0.996686929

The color data taken from the Genesis version using my method is reliable.

SNES BT&DD:
Average Standard Deviation: 527.1437336
Average Reliability: 0.997292283
Minimum Reliability: 0.99223637

The color data taken from the SNES version using the same method is reliable.

What this means is that I can continue taking color counts from screenshots using the same methodology and expect the color counts to be consistent with all other screenshots taken. I can expect the color counts given to be within a minimal acceptable variance, and I can expect this variance to not radically change.

As this is only two games using this method (nearly 100 screenshots though) I will test future games just to see if these results prove incorrect for different games when everything else remains the same.

What this does not necessarily mean is that the color counts given are an accurate valid count of some direct mathematical association with the actual color counts of the chip outputs. As I collect more color data from more games and systems using the same method, the reliability score should creep ever closer to 1. I expect to pick up on more correlations between the actual chip output colors and what the Composite color count is.

blargg
Newbie
Posts: 7
Joined: Sat Feb 20, 2010 6:27 am

Post by blargg » Tue Feb 23, 2010 5:43 am

One thing is that the Genesis pixel rate is slightly less than twice the color carrier frequency, so the color fringes do a rainbow as you go horizontally across the screen. For example, a simple black and white alternative vertical pattern will generate a rainbow. On the other hand, the SNES pixel rate is exactly 1.5 times the color carrier rate, AND it alters the phase by 120 degrees each frame, so you get much less color fringing, and only three possible tints.

The above effect is very minor, and changes depending on the horizontal position, so it's not something that contributes to colors in graphics, but it will contribute to a low-level count of the total number of colors in a screen capture.

I do find the idea interesting, to capture screens and compare the total number of colors, but I think it needs to be done in a sophisticated way. For example, if you have two colors that are only slightly different, but not used near each other, for all intents and purposes they are the same color, and shouldn't count as two. On the other hand, if they were next to each other and distinguishable visually, then you would count them as two.

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

Post by sheath » Tue Feb 23, 2010 2:07 pm

Any recommendations you have I'd love to hear. I'll keep the original MPEG-2 files if we need more screenshots for any reason. I did test taking screenshots straight from the capture card display and got the same results. I don't have the resources to try any more capture card solutions right now, and I have no reason to believe another card would be better. Ati cards filter the image in order to super compress it, and they add lag to the screen so I can't play the games. Hauppauge WinTV cards can't read Genesis SMS outputs without inverting the colors. The next one I'm going to try, hopefully this year, is a Hauppauge HD-PVR box, it'll be interesting to see if it supports Genesis - SMS when the SD cards did not. All capture card companies refuse to support video capture from game consoles.

That is why I decided to test for reliability, if I had even one below .85 I'd be sitting on the whole project until I found something better. Some preliminary ideas I have for how to compare these color counts across system aren't very well formed yet. I thought I might just post the range of Composite colors in relation to the range of actual colors. Or I might represent them as a percentage in relation to the chip color count, but with no linear correlation I don't know how that would be helpful. Until I find a logical or mathematical connection between the actual color counts and the Composite color counts in screens I'm just in data collection mode. There is obviously more to learn about what you know about the physical outputs of these systems as well.

BTW, I play with your NTSC filter on my RPTV at all times. Would you consider a comparison between raw emulator output color counts, the NTSC filter's, and Composite useful in any way?

Post Reply