On the NES, each palette entry of the 2 x 4 on-screen palettes takes one byte, i.e. each palette entry can have a value of 0-255.
So, is there a technical reason why the total number of colors on the NES is only 64 (52 + a few black entries) instead of 256?
I would understand it if the palettes occupied only 24 bytes (6 bits for each of the 2 x 4 x 4 entries). But they take the full 32 bytes (8 bits for each of the 2 x 4 x 4 entries).
I'm sorry but those kinds of questions, such as "why are nametables 32x32 tiles", "why are tiles 8x8 pixels", "why is the screen resolution 256x240", or "why is there only 8 sprites per line", "why isn't the A15 adress line passed to the cartridge edge", "why the square channels contains an almost useless length counter feature", etc... have already been asked over and over and there's no answer. This is just how Nintendo designed the console. Only Nintendo knows. Asking here is irrelevant. Your quesiton is unanswerable for us.
Those questions are not analoguous since I'm not asking for arbitrary design decisions.
(For example, I didn't ask why the last few colors are filled with black instead of real values.)
My question was basically:
Is the color spectrum of the NES a collection of 256 colors where 204 colors are simply chosen to be black.
I.e. they could have added more colors without changing anything else since the slots already exist, they just chose not to fill them with meaningful values.
Or is there a technical reason that there are only 64 colors?
I.e. the PPU value might be one byte, but when it gets converted to the actual color, the NES reads from a six-bits-per-entry table, so adding new colors would have changed the overall logic.
DRW wrote:
On the NES, each palette entry of the 2 x 4 on-screen palettes takes one byte, i.e. each palette entry can have a value of 0-255.
No, they can't. The PPU's internal palette RAM is only six bits wide. When you write to it, the upper bits are simply discarded--you can verify this by reading it back via $2007.
As for why the palette isn't packed 4 entries in 3 bytes like you suggest, that would have had more drawbacks than benefits. Software would have to write very slightly less data in vblank to update the full palette, but updating individual colors, or doing arithmetic on palette entries for fade-outs, etc., would have become significantly more difficult with bit-packed entries.
And as for why the NES didn't support more than 4 levels of luma, I guess that would have made the DAC take up more PPU die space than the engineers could spare. The Atari TIAs (video chips in the 2600, 5200, 7800, and the 8-bit computers) had 3 or 4 bits of luma, but they needed external DACs--the video signals coming out of the chip were digital.
The PPU only stores 6 bits per entry because that's all it can use. They don't simply index a table like you assume, because such a table would be far too big for the technology of the time. Instead it has a convoluted and actually rather clever chain of logic to generate the entire image using a single square wave. The square wave sequencer has 12 steps, allowing it to be offset in 12 phases, and there are four sets of levels for the low and high parts of the wave. But that doesn't include black and white, so there is logic to switch the square wave off and generate a constant signal, either the high level or the low level.
That gives you 14×4 = 56 different possible combinations, though since the level table has to pull double duty not all of them are very different.
DRW wrote:
Those questions are not analoguous since I'm not asking for arbitrary design decisions.
Yes, you are indeed asking for arbitrary design desicion. The 56 palette is part of the console's design.
Quote:
Is the color spectrum of the NES a collection of 256 colors where 204 colors are simply chosen to be black.
No.
Quote:
I.e. they could have added more colors without changing anything else since the slots already exist, they just chose not to fill them with meaningful values.
Yes they could have added more colours, but for some reason they didn't.
Quote:
Or is there a technical reason that there are only 64 colors?
Yes, only 6 bits of memory are used. They could still have used more colours with 6 bits, for example having 15 hues instead of only 12, but for some reason they didn't.
After reading about how the NES generates those colors, you never think about the NES palette the same way again.
It's a square wave between a bright gray level and a darker gray level, and it can be shifted to 12 different phases, left as light gray, or left as dark gray.
They picked up to 4 levels of brightness for the palette. But yes, they could have used more.
Bregalad wrote:
there's no answer. This is just how Nintendo designed the console. Only Nintendo knows. Asking here is irrelevant. Your quesiton is unanswerable for us.
That in itself would be an answer, if it were true. I would imagine there's a technical (/financial) limitation behind the descision. I'm certain that the NES would have had a 256 color palette if it doesn't make the PPU more expensive produce.
Bregalad wrote:
"why isn't the A15 adress line passed to the cartridge edge"
Well, I found a clone that has it on the cartridge edge:
Attachment:
Phantom connector.jpg [ 206.5 KiB | Viewed 2779 times ]
I just don't know for what it would be useful
, unless you want to make something that works only with this clone and not with the real thing...
It was die size cost. Name a way it could have been extended to 256 colors, and someone might explain how that would have been more expensive. In addition, a 3:3:2-bit (rrrgggbb) format wouldn't have produced pure grays.
When I finish my NES time machine I'm going to go back to the 80s and tell Mr. Nintendo to fire the guy implementing color emphasis bits. Then I'm going to tell him to hire a palette engineer that knows all 256 colors, including the exotic yellow one.
Or, better, fire the one who decided 4 sub-palettes were already enough for the Mega Drive, backgrounds and sprites combined.
Though as explained in the Famicom's case here, there were many reasonable... er... reasons to this, Sega seemed to be quite bad in this area. The Game Gear is another odd ball, as it has a HUGE master palette despite having only 2 sub-palettes (though some games did change colours mid-screen), and this is more or less the only improvement over the original SMS (and the reduced resolution, if you call this an improvement).
What I really want to do with time traveling though, is to let the PC Engine have a larger master palette (4096 colours is enough). This can certainly make its arcade and PC conversions much more accurate. And AFAIK this is relatively "easy" to pull off too. You only need to change the VCE and keep the original VDC, which was already done by some arcade games using the same VDC and probably the PC-FX, which I'm not very familiar with its specs, but I think its VDC was just a minor upgrade from the PCE one.
The DAC inside the 2C02 has 10 taps; one could certainly specify palettes in a much more expanded manner where you directly specified which tap for the high and low phases instead of 2 bits specifying some pair. This would afford you 12·10·10=1200 different nominal colors, although a huge number of them would be duplicates (tons of greys and every color would be present twice), and lots of them would be completely out of gamut, too. (After all, these taps include the sync voltages)
The amount of die area needed to hold the palette would double, and addressing it (since it's now more than 8 bits) would be more complicated.
Furthermore, the location of the individual bits within the 2C02's palette RAM initially appears a little oddly interleaved, so even though there is enough
area to hold the extra bits of RAM to hold a bigger RAM, there isn't enough
width:
Code:
3f00&1 3f04&1 3f08&1 3f0c&1 3f00&2 3f04&2 3f08&2 3f0c&2 3f00&4 ... 3f0c&20
3f12&1 ...
3f02&1
3f11&1
3f01&1
3f13&1
3f03&1 remainder omitted for clarity
A more practical refinement of that idea: For one additional bit per color, the PPU could have had a set of desaturated colors.
Of the 7 taps actually used for picture, $0D and $1D are very close, $2D and $00 are kind of close, and $3D and $10 are very close. So this leaves us four easy-to-distinguish taps: $1D, $00, $10, and $20.
[code]
bbaa xppp
|||| +++- Phase (0 to 5) in twelfths of a color subcarrier
|||| Corresponds to a pair of opposing hues
||++------ In-phase tap (7.5, 40, 70, or 100 IRE)
++-------- Out-of-phase tap
All the grays $0x, $5x, $Ax, and $Fx would be duplicates.
This would produce 12 sequences of two distinct taps times 6 hue pairs plus four grays = 76 colors without adding much complexity to the signal generator.
Gilbert wrote:
Or, better, fire the one who decided 4 sub-palettes were already enough for the Mega Drive, backgrounds and sprites combined.
Though as explained in the Famicom's case here, there were many reasonable... er... reasons to this, Sega seemed to be quite bad in this area. The Game Gear is another odd ball, as it has a HUGE master palette despite having only 2 sub-palettes (though some games did change colours mid-screen), and this is more or less the only improvement over the original SMS (and the reduced resolution, if you call this an improvement).
What I really want to do with time traveling though, is to let the PC Engine have a larger master palette (4096 colours is enough). This can certainly make its arcade and PC conversions much more accurate. And AFAIK this is relatively "easy" to pull off too. You only need to change the VCE and keep the original VDC, which was already done by some arcade games using the same VDC and probably the PC-FX, which I'm not very familiar with its specs, but I think its VDC was just a minor upgrade from the PCE one.
Or even better, fire who decided that SPPU space was better used for a limited, gimmicky hi-res mode than enough space for each oam entry to be 5 bytes instead of 4 and 1/4. I've asked this before, but was the SNES originally going to have twice the vram bandwidth or something, because half of the video modes are so crippled by it that they're useless.
Color is where basically where every home console was severely behind. Even the SNES, which is considered "colorful" (really only in comparison to the Genesis) has 1/16 the amount of palette entries as the Neo Geo, which has a standard number of palette entries for arcade systems of the time. No other spec is even close to that far behind. Even the GBA, which handily destroys the Neo Geo and other arcade machines of the time, has 1/8 the palette entries. (Which really make the 8bpp support for sprites and BGs far less useful.) I don't know how much more a 2-8KB ram chip would have cost in 1990.
As far as I know, the VS/NES model was deliberately kept simple to a degree: first, to minimize costs (hitting the intended price point
was not particularly easy). It was definitely biggest bang for the buck. Another benefit of simplicity is how easy it is to program at first.
Color wasn't expected to be dynamic in the early '80s, and fun overshadowed realism. How can we forget how popular the Gameboy was despite providing only four shades of gray (or greenish gray) total? (Granted, the handheld market was different, but the point of producing fun games remains.)
And so the PPU had only 32 palette entries - eight attribute regions for any 2-bit pixel, and only 6 bits of color selection. The developers were more focused on quality assurance on the final product, and too much time thought about slight improvements would have held back subsequent console designs. It was the next home console to support 256 colors standard, the SNES/Super Famicom.
It's still interesting to find new potential for the old console, though.
ap9 wrote:
the PPU had only 32 palette entries
Actually, 28 palette entries, but only 25 can be used normally, the remaining 3 can only be displayed if rendering is turned off.
tokumaru wrote:
ap9 wrote:
the PPU had only 32 palette entries
Actually, 28 palette entries, but only 25 can be used normally, the remaining 3 can only be displayed if rendering is turned off.
Yes, forgot that only 28 entries actually exist in palette RAM. 7 in 32 mirror entry #0 -- 3 of which won't render because all #0 pixels are "transparent," and OAM-side "transparent" colors won't be put on screen unless rendering is disabled.
tokumaru wrote:
ap9 wrote:
the PPU had only 32 palette entries
Actually, 28 palette entries, but only 25 can be used normally, the remaining 3 can only be displayed if rendering is turned off.
I didn't know that, how are the extra 3 colors used?
psycopathicteen wrote:
I didn't know that, how are the extra 3 colors used?
Turn rendering off and set the VRAM address to point to the color you want to show, the PPU will then output that instead of color 0. Not the most useful feature in the world, but still.
Bregalad wrote:
I'm sorry but those kinds of questions [...] have already been asked over and over and there's no answer. [...] Asking here is irrelevant. Your quesiton is unanswerable for us.
Followed by a whole bunch of answers that detail the technical reasons for this.
Reminds me of the situation where we were discussing why the nine sprites overflow fails when used right from the beginning of a game.
There was a definite explanation for it:
The PPU skipping the rendering of certain sprites for one frame if you set PPUMASK to 0 outside of vblank, which you usually do once right in the beginning. Hence the nine sprites flag doesn't trigger since there actually aren't nine sprites on the scanline in this one frame, so the problem was caused by an unrelated issue, but the nine sprites effect itself was not to blame since it worked as intended.
But then there was also that moron who, via private messages, told me:
"Sprite overlfow is buggy, don't use it."
"You'll still run into the sprite oevrflow bug. Sprite overflow breaks with sprite rendering order in such. You can not use it. Use an MMC3 mapper, that is the only way to do it correctly."
"It never works. 9 sprites to trigger the overflow will fail randomly"
"if you read the sprite overflow flag in your game, it is bound to fail. You can NOT use it."
"I'm sorry you feel so defensive for using crap code because you utilize known-broken hardware."
Good thing most of the people on this forum are not of the "What a noob! Why you ask so stupid questions? What you wanna know cannot be done/explained" kind, but actually investigate the issue and find reasonable answers instead of simply saying: "It just doesn't work, duh!"
Quote:
Followed by a whole bunch of answers that detail the technical reasons for this.
None of the posts in this threads are answers to your
original question (of course because it's not answerable), they are just comments about the topic of colour palettes - or answers to your questions from your second post which are, indeed, answerable.
Original question:
DRW wrote:
So, is there a technical reason why the total number of colors on the NES is only 64 (52 + a few black entries) instead of 256?
Elaboration:
DRW wrote:
I would understand it if the palettes occupied only 24 bytes (6 bits for each of the 2 x 4 x 4 entries). But they take the full 32 bytes (8 bits for each of the 2 x 4 x 4 entries).
One of the answers:
AWJ wrote:
The PPU's internal palette RAM is only six bits wide.
Probably most people assumed your question was "why did the PPU designers decide to use 6 bits for palette values rather than 8 bits"
as perhaps some of us have seen similar, practically unanswerable, questions on this and other boards. Few of us stiill have the early-80s Ricoh/Mitsubishi chip designers' phone numbers in our Rolodexes.
I'm sure some of us should feel sorry for being so presumptuous.
According to
this website (or The History Of Nintendo vol. 3), Shigeru Miyamoto himself designed the palette and its color count. "Enough color to make something nice but not a lot to avoid the high price of production. Each decision about a color will influence Game’s apparences on this console. At the end, they decide to make 56 different colors." He wanted more blues to distinguish water from sky blues for developers. It's also said that he wanted 56, so the darker scale (column #13) may not have been so black in the beginning.
If his reasons aren't detailed further in the literature, we can only speculate on the rest.
SMS's full 64-color palette would have been more complete, but the electronics would have definitely been more expensive for that because we're not dealing with RGB, we're dealing with the NTSC equivalent of HSL. After some thought, I realize that:
64 is the first power of 2 to contain 12 four-shade hues - the most basic palette you could have to feature all 6 full-contrast RGB hues and one gradation in between each (one orange column). Add two gray scales and you have 14 used columns. The first column was brightened so the leading gray (#0) met about 50% intensity, and so the redundant white became the voltage limit against desaturation (which has no effect on a gray). The second gray scale became more of a black scale considering they literally became black in the RGB PPU.
ap9 wrote:
He wanted more blues to distinguish water from sky blues for developers.
There is not "more blues", all 12 coloured columns are equally spaced in the hue space. Each named colour is free to interpretation about how far we want to call it that name before it really becomes another colour.
It's perfectly plausible that "more blues" meant "in comparison to most 2nd generation video game consoles". The Intellivision, Channel F, Odyssey², as well as the contemporary computers (e.g. VIC-20, Atari 400, Apple 2) had very limited master palettes.
Thus, it could have been part of the original design document that specifically led to the cost-reduction choice of using a single (NTSC×6) master clock instead of needing the TMS9928's need for both a (NTSC×3/2) and (NTSC×2) clock.
(They didn't have to pick that pixel clock. They didn't have to provide colors from all 12 equally-spaced angles around the YUV plane)
It is (and it's an interesting perspective), but then again, Betoux identifies one red. I'm on the verge saying the nes master palette has no red colour, or 1 i'd call red in a pinch, while there's several i'd call green, blue, purple. I realize this is a personal judgement, but still...
It's like bregalad says, but at the same time our names for colours are varyingly narrow/broad in definition, and i'm inclined to say that it's mostly cultural rather than individual, at least at a pattern level. Human biology may play a part, too.
Attachment:
600px-YIQ_IQ_plane.svg.png [ 151.64 KiB | Viewed 1606 times ]
Here's the YIQ color plane.
Cut it up into 12 sections (cut each quadrant into thirds like a pizza), and give it 4 levels of brightness.
Presto, there's your NES palette.
Dwedit wrote:
Here's the YIQ color plane.
Cut it up into 12 sections (cut each quadrant into thirds), and give it 4 levels of brightness.
Presto, there's your NES palette.
What about the grays and the blacks?
Would it have been feasible to divide into 15 rather than 12, or is there something inherent about "quadrants" that makes a multiple of 4 work better? e.g. could you have easily done 16 hues if you gave up white/grey/black?
Even numbers work better. (More precisely: Designing something that works reliably at frequencies below 30MHz is much easier. Even divisors let you use both rising and falling edges of the clock usefully.)
The
Commodore 16 and Plus/4 provided access to a subset: 14 angles of the 16 equally-spaced division of the YUV plane.
I previously contemplated a design that used a 7×NTSC crystal instead. This gives you 14 equally-spaced divisions of the YUV plane.
But with both of these, you can't easily synthesize the 5.4MHz pixel clock any more. Other choices have other compromises, which may be better (more nearly square pixels) or worse (needing more nametable memory or pillarboxed display).
edit: (An 8× crystal would afford a pixel clock of NTSC×8÷5, a 272 pixel mode with a PAR of 15:14. A 7× crystal would afford a pixel clock of NTSC×7÷4 or ÷5, yielding a 296 pixel mode with a PAR of 48:49 or a 240 pixel mode with a PAR of 60:49)
rainwarrior wrote:
Would it have been feasible to divide into 15 rather than 12
Look at the palette of the Atari 2600. The TIA is such a simple chip that I can't imagine that's a hard thing to pull off... Based on the master palette alone, the NES really looks like a step back from the 2600.
The TIA implements the ÷15 as a series of carefully-tuned analog delays from the original NTSC colorburst frequency crystal. When it came to the PAL revision, they gave up retuning the inverters and only gave you 12 angles instead.
It's much harder to move analog designs from one IC fabrication facility to another; often every carefully-tuned R and C need to be revisited when you do so. A purely-digital design, or at least one where the only values that matters is the ratios of specific resistors relative to each other (such as the 2A03's DACs), means it's a lot easier to move fabs as demand changes.
lidnariq wrote:
The TIA implements the ÷15 as a series of carefully-tuned analog delays from the original NTSC colorburst frequency crystal. When it came to the PAL revision, they gave up retuning the inverters and only gave you 12 angles instead.
It's much harder to move analog designs from one IC fabrication facility to another; often every carefully-tuned R and C need to be revisited when you do so. A purely-digital design, or at least one where the only values that matters is the ratios of specific resistors relative to each other (such as the 2A03's DACs), means it's a lot easier to move fabs as demand changes.
The Atari machines have a potentiometer on the motherboard for adjusting the analog-generated hues. They were supposed to be tuned at the factory with the aid of a test-pattern cartridge, but in practice, especially as the components age, hue 15 (the one with the longest delay) ends up varying between units from orange to green--and that's in addition to the inevitable variability between NTSC TV sets.
tokumaru wrote:
Look at the palette of the Atari 2600. The TIA is such a simple chip that I can't imagine that's a hard thing to pull off... Based on the master palette alone, the NES really looks like a step back from the 2600.
I ought to disagree strongly. The NES palette is pure genius, I think. I love how the colours are fully saturated, it makes the game appears more bright and shallow than on any other console of the era. And they did that using a simple Johnson counter technique to realise the NTSC encoding ! The only complaint I'd have is that they should have used 14 or 15 hues instead of only 12, and I'd have liked one additional level of gray darker than palette $00, but who cares.
Bregalad wrote:
I ought to disagree strongly.
The 2600 has yellow and 8 brightness levels, period.
Quote:
as the components age
Can i assume this specifically means capacitors drying out? That sounds the most likely to me. Had they been produced today, and depending on application, there's types of caps with much tighter consistency over long time of use and storage, if somone were to reproduce the model, or if a new 'retro' console was made.
On a per unit level, discrete caps should be easy to replace.
tokumaru wrote:
The 2600 has yellow and 8 brightness levels, period.
Which leads to another fallacy than "the NES has more blues" - the NES indeed DOES have a yellow colour; the $x8 column is indiscutably yellow to me. It is hower true it is the only column with yellow tones, as the $x7 column is already leaning towards orange and colour $x9 already leaning towards green, although both are yellow-ish. The saying that the NES "doesn't have yellow" is complete bullshit - it just have 12 equally spaced hues, and it just happens the word "yellow" seems rather restrictive to the proposed hues.
Besides, you know the 2600 looks absolutely awful, no matter it's colour palette - for other reasons, mainly the awfully low resolution.
Colours are never indiscutable to me
. I consider 26 to be peach, 27 orange/amber, 28 overmature lime. None is actual yellow (as in lemon or Trollius altissimus), but all could be categorized as yellows when thinking in overlapping terms, just as "blue" might overlap violet and teal. The slices of the master palette cuts straight through some cultural definitions, while cutting in-between some other.
Attempt at categorizing:
x1 Cold blue
x2 "Almost pure" Floral Blue* (but really, i think 'pure' is between x1 and x2)
x3 Violets
x4 Purples
x5 0: (Dark) Cerice | 2: Cerice/hot pink**
x6 0: Off-red/wine | 1: the colour of light polution a cloudy night over a city with warm street lights | 2: Peach
x7 0: Brown 1: Mustard Seed | 2: Orange Or all of them: Amber or Citrine
x8 0-1: Olive | 2: Overmature lime
x9 Green lime
xA "Pure" Green
xB 0: Jade/Pine | 1: Cold Green | 2: Mint
xC 0: Navy/Teal (darker) | 1-2: Teal (brighter)
the 4x are simply categorized as bright pastels of the same to me.
*"Blue" flowers tend to be "almost blue", but lean slightly towards the violet upon closer inspection. Few are true blue or indigo; one exception is usually the hard-to-grow "Lingholm" variety of Meconopsis, but even then, some individual plants may develop violet streaks.
**Not named so after tint but after cultural affect. Picture-googling "hot pink" will reveal a variety of pinks, of which most lean towards the cold. It's also interesting to see what items and contexts such a colour is associated with. That goes for any colour.
It's not complete, perfect or universal. Different TV sets will shift the tint aswell. Just an attempt to formalize categorizations i half-consciously work with when pushing pixels.
Bregalad wrote:
Besides, you know the 2600 looks absolutely awful, no matter it's colour palette
A lot of people would say the same about the NES depending on which consoles they grew up with and their personal preferences. While it's true that the majority of all 2600 games look like shit (by today's standards, at least), I believe that it's possible to create captivating graphics on any platform (yes, even on the ZX Spectrum). A good artist who embraces the limitations of each console can succeed in any platform.
I mean, just look at Alp's Intellivision mock-ups in
this thread. Nothing remotely as good looking as that was previously released on that console. His Atari 2600 stuff isn't too shabby either!
Your dislike for the 2600 is very clear, but there's just no denying that 15 hues at 8 brightness levels is objectively better than 12 hues at 4 brightness levels. And the gray column on the 2600 doesn't have any weirdness like repeated colors.
I love the NES, but its master palette is undeniably one of its weaker points, along with the small number of sprite and background palettes (and the 8 sprites per scanline limit, but that's beside the point).
tokumaru wrote:
I believe that it's possible to create captivating graphics on any platform (yes, even on the ZX Spectrum).
Case in point:
The Trap Door uses characters large enough that two colors per 8x8 pixel color area aren't quite as limiting. (
Video)
And when Alp can come up with Intellivision graphics that wouldn't look
that out of place on a Game Boy Color, that illustrates your point.
FrankenGraphics wrote:
Can i assume ["as the components age"] specifically means capacitors drying out?
I think it's actually something inside the TIA's die... maybe the MOSFET-used-as-a-capacitor. Or maybe the two enhancement-mode 'FETs...
The NTSC 2600's
schematic starts with a BJT-based 3.57MHz crystal driver. The external tuning potentiometer actually adjusts a bias voltage for the inverters
inside the TIA (see page 5).
Bregalad wrote:
the NES indeed DOES have a yellow colour; the $x8 column is indiscutably yellow to me.
1: On NTSC, $x8 is pure shade -U, which is
not yellow. Yellow is
defined as 13° clockwise from shade -U. See also
my composite image in this old post.
2: PAL NES and NTSC NES have different master palettes, offset by a 15° rotation in the YUV plane. Shade $x8 on 2C07
is basically yellow. Shade $x8 on 2C02
isn't.
tokumaru wrote:
there's just no denying that 15 hues at 8 brightness levels is objectively better than 12 hues at 4 brightness levels
The PAL and NTSC 2600s
also have different master palettes. The PAL 2600 only has 12 hues.
Yeah, they certainly screwed up the PAL 2600 palette (not nearly as badly as with the SECAM version, WTF is up with that?!?), but it might still be better than the NES' due to having more brightness steps.
Here's a comparison between the different Atari 2600 palettes, for those who're not familiar with the system:
Attachment:
98874793.jpg [ 106.96 KiB | Viewed 1796 times ]
The reason I keep bringing the 2600 up is because it's significantly older than the Famicom, and the design of the TIA is incredibly simple, so I find it somewhat surprising that Nintendo came up with something with worse color capabilities.
But then some video output amplifiers are affected by slope overload or slew rate. When the output signal has a maximum slope, large changes in voltage take longer than small changes. Passing a square wave through an amplifier with a slew rate turns the rises and falls into trapezoids, adding effective group delay proportional to the square wave's amplitude. Thus when the chroma amplitude of $28 is greater than that of color burst, the amplifier shifts the phase to a greater extent.
Code:
___________ ___________ ____
| | | | |
_| |___________| |___________|
Signal with amplitude 2 lines
__________ __________ ___
:/ \ :/ \ :/
_/ :\__________/ :\__________/
Limited to 1 line of rise per character of run
Carrier delayed by 1 character
___________ ___________ ____
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
_| |___________| |___________|
Signal with amplitude 6 lines
______ ______
: / \ : / \ :
: / :\ : / :\ : /
: / : \ : / : \ : /
: / : \ : / : \ : /
:/ : \ :/ : \ :/
_/ : \______/ : \______/
Limited to 1 line of rise per character of run
Carrier delayed by 3 characters
If group delay causes clockwise phase rotation, that might explain why $28 in
Dr. Mario pills looks yellow.
The asymmetry of NMOS increases this possibility for delay as well. An NMOS output driver can pull down faster than it can pull up. This tends to widen black vertical lines on white backgrounds, narrow white vertical lines on black backgrounds, and make delay at 3.58 MHz even greater.
Code:
: ,'\ : ,'\ :
: ,' :\ : ,' :\ :
: ,' : \ : ,' : \ :
: ,' : \ : ,' : \ : ,
: ,' : \ : ,' : \ : ,'
_,' : \______,' : \______,'
Limited to rise rate 1/2, fall rate 1
The 2C02/2C07 and subsequent hardware is not slew-rate limited (the output stage is a resistor ladder and an analog multiplexer). Slew-rate limitations only happen when there's a feedback path (clamping and integration, or a digital stage) in the generation; the NES's video output stage is "just" a series of lowpass filters, highpass filters, and discrete amplifiers with bandwidth substantially higher than needed. (And, to head that off: even if these discrete amplifiers
weren't higher bandwidth than needed, they would just become another lowpass filter)
What
is true is that the DAC used in the 2C02/2C07 is effectively a voltage-controlled filter, producing a
slightly different delay depending on the specific tap used, and in turn, a slightly different hue angle as the brightness changes.
However, entertaining this level of precision means that any given column of the master palette isn't a constant hue: it is
still incorrect to say that "2C02 phase $x8 is yellow".
Quote:
Your dislike for the 2600 is very clear, but there's just no denying that 15 hues at 8 brightness levels is objectively better than 12 hues at 4 brightness levels.
Indeed - and I had absolutely no idea the 2600 had such an "advanced" palette. I assumed you were saying that it was supperior to the NES because it had not fully saturated colours or something in the like.
Also - I'm sorry to insist but 2600 looks awful no matter whether you look by today or back then standards. Even the post you linked to look awfull. I grew up with a PC and a Playstation 1, but the NES graphics are no problem to me, even in the earliest games. Sure they might not look great but they didn't directly interfere with the development of games. 2600 graphics did.
NES palette is hardly a problem, sure it is limited but I don't remember to ever have the problem that I needed a colour that wasn't in the palette. If that was the case I just pick the closest one and that's the end of the story.
Bregalad wrote:
Even the post you linked to look awfull.
That link was mostly for the Intellivision stuff. Have you ever seen what Intellivision graphics from back in the day looked like? Alp's work is in a completely different level. I can't say for sure that he followed every restriction imposed by the hardware accurately because I'm not very familiar with the Intellivision, but if he did, that'd be one very impressive game!
Alp's version of Cat Quest for the 2600 looks pretty good to me too, but tiled backgrounds are a real challenge on the 2600, I'll give you that. Any attempt at detailed tiled backgrounds will look extra chunky, no way around that. I wouldn't personally go that route, I'd rather use the blocky playfield pixels to draw the basic layout of the backgrounds but use objects (players, missiles, ball, whatever is available) for any details that are necessary, even if the details end up being somewhat sparse.
Quote:
I grew up with a PC and a Playstation 1, but the NES graphics are no problem to me, even in the earliest games. Sure they might not look great but they didn't directly interfere with the development of games.
Of course the graphics interfered with the development of games on the NES! There's stuff the NES cannot do, so it wasn't done, just as is the case with the 2600. The NES, being newer, can do more than the 2600, but its limitations are also pretty harsh.
BTW, I'm not trying to make anyone like the 2600. There's plenty of stuff I don't like that I don't want people trying to convince me to change my mind. If you don't like it, that's fine, I totally see where you're coming from, considering that lots of 2600 games look (and play!) absolutely terrible. My only reason for bringing it up here was its color palette, which's undeniably broader than the NES'.
Quote:
NES palette is hardly a problem, sure it is limited but I don't remember to ever have the problem that I needed a colour that wasn't in the palette. If that was the case I just pick the closest one and that's the end of the story.
Indeed, it's not such a terrible problem at all. And I honestly believe there's no point in complaining about this or that characteristic of retro consoles, because they are what they are and there's nothing we can do about that. If something bothers someone that much, they should just go work with another platform. But I still think it's fun to analyze WHY things are how they are and imagine how they could have been if different choices had been made, but just as a fun exercise, not as an attempt to actually "fix" anything or badmouth the people responsible for the existing designs.
tokumaru wrote:
Yeah, they certainly screwed up the PAL 2600 palette (not nearly as badly as with the SECAM version, WTF is up with that?!?)
Attachment:
98874793.jpg
GOOD GRIEF, SECAM!
As a pixel artist, I wish I had more dark shades to work with. Creating dark graphics usually ends up with tons of pitch black on screen as dithering looks awful.
I just noticed that the NTSC color signal has the colors in MBCGYR order instead of the more common RYGCBM order.
na_th_an wrote:
As a pixel artist, I wish I had more dark shades to work with. Creating dark graphics usually ends up with tons of pitch black on screen as dithering looks awful.
There is actually a solution to this, of sorts, at a cost.
1)Set all emphasis bits to 1.
2)Adjust your subpalettes to be brighter, except the darks you want to use.
3)Et voilà!
-The 'bright pastels' can actually become more useful this way, depending on application, as half-desaturated mid-brights.
-Depending on how you look at it, the washed-out effect it has can be viewed as a downside or unique feature of style. It is a bit more Commodore 64-esque.
-The biggest downsides are there's no pure white any more, and that you can't mix and match with non-damped colours.
-But you can, with some limitation and unless i'm missing something, decide per scanline (for example keep full saturation and use white in the status bar and damp the scenery, or vice versa).
FrankenGraphics wrote:
na_th_an wrote:
As a pixel artist, I wish I had more dark shades to work with. Creating dark graphics usually ends up with tons of pitch black on screen as dithering looks awful.
There is actually a solution to this, of sorts, at a cost.
1)Set all emphasis bits to 1.
2)Adjust your subpalettes to be brighter, except the darks you want to use.
3)Et voilà!
-The 'bright pastels' can actually become more useful this way, depending on application, as half-desaturated mid-brights.
-Depending on how you look at it, the washed-out effect it has can be viewed as a downside or unique feature of style. It is a bit more Commodore 64-esque.
-The biggest downsides are there's no pure white any more, and that you can't mix and match with non-damped colours.
-But you can, with some limitation and unless i'm missing something, decide per scanline (for example keep full saturation and use white in the status bar and damp the scenery, or vice versa).
The only way that could work is if you're making a "dark forest" level.
tokumaru wrote:
That link was mostly for the Intellivision stuff. Have you ever seen what Intellivision graphics from back in the day looked like? Alp's work is in a completely different level. I can't say for sure that he followed every restriction imposed by the hardware accurately because I'm not very familiar with the Intellivision, but if he did, that'd be one very impressive game!
Alp's version of Cat Quest for the 2600 looks pretty good to me too, but tiled backgrounds are a real challenge on the 2600, I'll give you that. Any attempt at detailed tiled backgrounds will look extra chunky, no way around that. I wouldn't personally go that route, I'd rather use the blocky playfield pixels to draw the basic layout of the backgrounds but use objects (players, missiles, ball, whatever is available) for any details that are necessary, even if the details end up being somewhat sparse.
Thanks! ...and yeah, I did follow every hardware restriction, and the game
was impressive (so I hear). PM sent.
psycopathicteen wrote:
FrankenGraphics wrote:
na_th_an wrote:
As a pixel artist, I wish I had more dark shades to work with. Creating dark graphics usually ends up with tons of pitch black on screen as dithering looks awful.
There is actually a solution to this, of sorts, at a cost.
1)Set all emphasis bits to 1.
2)Adjust your subpalettes to be brighter, except the darks you want to use.
3)Et voilà!
-The 'bright pastels' can actually become more useful this way, depending on application, as half-desaturated mid-brights.
-Depending on how you look at it, the washed-out effect it has can be viewed as a downside or unique feature of style. It is a bit more Commodore 64-esque.
-The biggest downsides are there's no pure white any more, and that you can't mix and match with non-damped colours.
-But you can, with some limitation and unless i'm missing something, decide per scanline (for example keep full saturation and use white in the status bar and damp the scenery, or vice versa).
The only way that could work is if you're making a "dark forest" level.
It also worked rather well in the firefly demo. Assuming you don't need to move the band, you could design your stage so that an upper or lower segment, or both, is/are damped and keep the main field of play bright. It could be pretty impressive if done right. A cave, the sewers, underwater...
FrankenGraphics wrote:
1)Set all emphasis bits to 1.
psycopathicteen wrote:
The only way that could work is if you're making a "dark forest" level.
It also worked rather well in the firefly demo.
We actually have a list of games that do it:
https://wiki.nesdev.com/w/index.php/Colour-emphasis_games
na_th_an wrote:
As a pixel artist, I wish I had more dark shades to work with. Creating dark graphics usually ends up with tons of pitch black on screen as dithering looks awful.
Actually, a very clever use of black colour has always been the key to good NES graphics, I've noticed. Although not always the case, black is typically the BG colour, so it comes for free in any BG palette, and a correct use of black allow to link different coloured areas well.
Bregalad wrote:
na_th_an wrote:
As a pixel artist, I wish I had more dark shades to work with. Creating dark graphics usually ends up with tons of pitch black on screen as dithering looks awful.
Actually, a very clever use of black colour has always been the key to good NES graphics, I've noticed. Although not always the case, black is typically the BG colour, so it comes for free in any BG palette, and a correct use of black allow to link different coloured areas well.
Speaking of which, I just randomly stumbled onto the game Knight Rider. Not a very good game but it has two portraits that I thought were very nicely done, BG only no sprites:
Attachment:
knight_rider_portraits.png [ 11.38 KiB | Viewed 2117 times ]
Bregalad wrote:
I grew up with a PC and a Playstation 1, but the NES graphics are no problem to me, even in the earliest games. Sure they might not look great but they didn't directly interfere with the development of games. 2600 graphics did.
I think if there is one system whose graphics capabilities haven't aged well, it is the Playstation 1. Lack of sub-pixel accuracy and affine texture mapping with 15-bit color dithering might be quite off-putting for a modern gamer, contrary to the more simple, but clean NES graphics.
Concerning the 2600: you got the philosophy wrong. Designing a game with this machine is all about making deliberate choices as a top-notch 6502 coder.
It's a zen-like challenge.
Ugh, lack of perspective correction ages the worst out of anything.
And the fixed point "wobble" in the polygons... to be fair the PS1 looked rubbish when it was new. except the 2D titles or mostly 2D titles...
I think PS2 looks worse than PS1 actually. PS2 graphics were always about dull colors, blurry anti-aliasing, and grainy textures applied to every freaking thing. A person's face, there's a texture, a wall, there's a texture, a side walk, if it's onscreen make sure it's textured as fuck or else people won't think it's detailed enough.
FrankenGraphics wrote:
na_th_an wrote:
As a pixel artist, I wish I had more dark shades to work with. Creating dark graphics usually ends up with tons of pitch black on screen as dithering looks awful.
There is actually a solution to this, of sorts, at a cost.
1)Set all emphasis bits to 1.
2)Adjust your subpalettes to be brighter, except the darks you want to use.
3)Et voilà!
-The 'bright pastels' can actually become more useful this way, depending on application, as half-desaturated mid-brights.
-Depending on how you look at it, the washed-out effect it has can be viewed as a downside or unique feature of style. It is a bit more Commodore 64-esque.
-The biggest downsides are there's no pure white any more, and that you can't mix and match with non-damped colours.
-But you can, with some limitation and unless i'm missing something, decide per scanline (for example keep full saturation and use white in the status bar and damp the scenery, or vice versa).
Interesting idea, never thought of it
I've played using the blue emphasis bit quite a bit in my games, but never thought on using all three bits to 1 to make it look moodier. Nice one.