Incorrect tint on Dendy

Incorrect tint on Dendy
by Drag on 2012-05-15 (#93855)

I was interested in seeing what causes that strange green-tint problem that the Dendy Chronicles host mentioned in Lion King and Aladdin. Obviously, I don't have a Dendy, and I only have the rom image for Lion King, but I had a hunch.

On the title screen, the game writes $3E to $2001. Of particular interest is the fact that the red emphasis bit is active...

Apparently, when this bit is active, the Dendy will apply a green tint to the screen, and the amount of tinting depends on the console; for some it's barely noticable, on others it's extremely obnoxious.

I imagine if we looked at Aladdin (from Super Game), we'd see the same thing.

Just what we need, more clone incompatibilities.

by Dwedit on 2012-05-15 (#93857)

So between the RGB PPU and Dendy, are the color emphasis bits now at "don't use these"?

At least you can detect a Dendy easily.

by Drag on 2012-05-15 (#93864)

Dwedit wrote:
So between the RGB PPU and Dendy, are the color emphasis bits now at "don't use these"?

I think you could still use them, it's not your problem if a clone implements a feature incorrectly. It's still better to be aware of the issue though, if your game is intolerable due to it, then you can release a special Dendy version of it.

by 3gengames on 2012-05-15 (#93872)

I didn't know Nintendos RGB was a clone. lol. Don't use them, subtract 10 and don't be lazy.

by Drag on 2012-05-15 (#93880)

3gengames wrote:
I didn't know Nintendos RGB was a clone. lol. Don't use them, subtract 10 and don't be lazy.

Insert a long, drawn out argument as to why one way isn't better than the other here.

The point is, the software is designed for canonical NES hardware. Non-canonical NES hardware is being used. Ergo, compatibility issues that aren't the fault of the designer. I could just as easily say "get a real NES and don't be lazy" right back at you.

by tokumaru on 2012-05-15 (#93893)

3gengames wrote:
Don't use them, subtract 10 and don't be lazy.

Not all uses of the emphasis bits can be substituted by "subtracting $10" of each color value. For example, the color emphasis bits are nice for making water of variable depth (such as in Noah's Ark), because these bits can be changed during rendering without problems, while modifying the palette mid-frame is near impossible without severe visual glitches.

by Jeroen on 2012-05-16 (#93896)

Drag wrote:
3gengames wrote:
I didn't know Nintendos RGB was a clone. lol. Don't use them, subtract 10 and don't be lazy.

Insert a long, drawn out argument as to why one way isn't better than the other here.

The point is, the software is designed for canonical NES hardware. Non-canonical NES hardware is being used. Ergo, compatibility issues that aren't the fault of the designer. I could just as easily say "get a real NES and don't be lazy" right back at you.

We might wanna split this if it goes on long enough.

But what about those of us that develop for famicom? There was at least 1 famicom (the famicom titler) that used an rgb ppu.

by tepples on 2012-05-16 (#93898)

That and the Sharp TVs with a built-in Famicom. The box of Just Breed apparently has a warning that it won't work on Famicom TVs.

Split as requested.

by rainwarrior on 2012-05-16 (#93902)

Ha ha, just looked at the Just Breed box. What it says is:

シャープのC-1ではご使用になれません.

(Don't use with Sharp C-1.)

by ccovell on 2012-05-16 (#93934)

Famiclone systems have long been known to have overly-strong colour emphasis behaviour compared to the regular NES/Fami PPU. This means games like Bubble Bobble (FDS), Felix the Cat, Magician, etc. are sometimes a bit unclear and harder to play on clones.

by Shiru on 2012-05-16 (#93936)

Felix the Cat suffered a lot on the Famiclones indeed, the brightness was much lower than in other games.

by Drag on 2012-05-16 (#93937)

ccovell wrote:
Famiclone systems have long been known to have overly-strong colour emphasis behaviour compared to the regular NES/Fami PPU. This means games like Bubble Bobble (FDS), Felix the Cat, Magician, etc. are sometimes a bit unclear and harder to play on clones.

On the RGB PPU, the games would be completely unplayable due to a completely white screen.

Though, this brings up another point of interest, lots of European-developed games will intentionally leave the palette darkened via the emphasis bits. This isn't just on the NES either, several European-developed SNES games have super dark palettes as well. Why is this? It must have something to do with the PAL standard or something...

by ccovell on 2012-05-17 (#93999)

Drag wrote:
On the RGB PPU, the games would be completely unplayable due to a completely white screen.

Yes, very unfortunate. I can only speculate why Nintendo made PPUs that had features incompatible with each other. My guess, then, is that the original designers of the PPU (at Ricoh?) implemented the emphasis bits and 1) never explained their use in docs for programmers, or 2) told programmers they existed but NOT to use them in regular operation, or 3) told programmers, said "go wild", but then forgot about the emphasis bits when they had to go back and make an RGB version of the PPU. Or, 3) plus 4) since they apparently used a 6-bit DAC for rather lame colour decoding on RGB PPUs, the engineers at Ricoh couldn't be bothered to expend extra die space to implement proper mapping tables for the emphasis bits. (They could have at least had a "halfbrite" function per RGB channel at little additional cost and still keep it totally compatible with the composite PPU...)

Drag wrote:
Though, this brings up another point of interest, lots of European-developed games will intentionally leave the palette darkened via the emphasis bits. This isn't just on the NES either, several European-developed SNES games have super dark palettes as well. Why is this? It must have something to do with the PAL standard or something...

Again, just speculation, but most likely European programmers never used official Nintendo docs for NES programming. All of their knowledge was based on reverse-engineering (as RARE confirmed doing it this way). Most likely another programming house (probe, Eurocom...) reverse-engineered the PPU and made docs but thought that the emphasis bits were supposed always to be on.

As for the SNES, it probably just comes down to the highly-shaded, glossy European graphics look at the time. (Contrasted with the MS Paint look of US-developed games.)

by Shiru on 2012-05-17 (#94006)

Neil Baldwin mentioned that they got a photocopy of original docs in Japanese (it is in the Magician section).

by tokumaru on 2012-05-18 (#94017)

I seem to remember, back from the NESDEV mailing list days, Andrew Davie saying that all the knowledge he had when coding for the NES was obtained through reverse engineering.

Re: Incorrect tint on Dendy
by Eugene.S on 2012-09-28 (#100414)

I've just tested "Lion King Unl" (NewGame), Felix The Cat (U) and Prince of Persia
on a custom-made dendy with 6527P+6538 (Famicom AV PCB).

Lion King doesn't have a green tint. Felix is not very dark, and Prince of Persia works correctly.

The early revisions of all-in-one UM6561 have these problems.

Old clones was really good. But all of them made before 1994.

Re: Incorrect tint on Dendy
by zzo38 on 2012-09-28 (#100467)

I think it should still be OK to use tint bits for indicating game paused, since while paused it doesn't matter the display, it only matters that it is different so that you can see the differences.

Re: Incorrect tint on Dendy
by mikejmoffitt on 2012-11-09 (#102592)

If I recall correctly, the RGB PPU was developed at the same time as the regular 2C02 so the Famicom system could be used as an arcade platform should the Famicom fall through on the consumer market. Why it does not have the color emphasis bits, I do not know.

Re: Incorrect tint on Dendy
by Dwedit on 2012-11-09 (#102596)

It does have the color emphasis bits, except they are completely different. Instead of slightly darkening the other colors, they set R G or B to 255 for all pixels drawn. Turn on all 3 and the screen is white.
There was a thread earlier about how to detect an RGB PPU. Supposedly the RGB PPU doesn't skip 1 dot every other frame like the NTSC one does.

Re: Incorrect tint on Dendy
by thefox on 2012-11-09 (#102598)

Dwedit wrote:
There was a thread earlier about how to detect an RGB PPU. Supposedly the RGB PPU doesn't skip 1 dot every other frame like the NTSC one does.

Well, actually all that was really determined was that there was some kind of timing difference between the PlayChoice-10 RGB PPU and the (composite) NTSC PPU. In fact when ccovell ran some other test on his Famicom Titler (RGB PPU), the timing of it DID match the composite PPU... so at the moment we don't know of a surefire way to test for it.

Re: Incorrect tint on Dendy
by LocalH on 2012-11-09 (#102624)

I think I remember an idea being brought up that used the Zapper to test for a white screen with all emphasis bits on.

Re: Incorrect tint on Dendy
by thefox on 2012-11-09 (#102629)

LocalH wrote:
I think I remember an idea being brought up that used the Zapper to test for a white screen with all emphasis bits on.

Which would be just a less compatible version of asking the user "do you see a white rectangle above this text?".

Re: Incorrect tint on Dendy
by Drag on 2012-11-14 (#102924)

Sorry to be a pessimist again, but I don't think there's going to be any automatic way to detect an RGB PPU. Fortunately, the only gameplay-breaking difference between an RGB PPU and otherwise is the different behavior of the emphasis bits, and fortunately again, it's not gameplay-breaking if you only use one bit at a time, which is what Nintendo seemed to recommend anyway, and it might have been because of this exact reason in the first place.

If you can live with the idea that your super sweet water effects are going to look different from console to console, then you have nothing to worry about. If you absolutely 100% can't, then you could include a "Which type of NES do you have?" menu at startup, since if someone has the knowhow to play your game on an actual console in the first place, they probably are already aware of the different PPUs and how they're incompatible with one another.

If you don't want to do a menu, then offer seperate builds of your game; one for composite, one for RGB. Don't worry, because with 32-bit and 64-bit operating systems, we're all used to having seperate builds of the same thing for the same platform.

The reason I'm so pessimistic on this particular subject is because I don't think the effort of figuring out how to automatically detect an RGB PPU (which most people probably don't even have), either purely in software (likely not possible) or with a zapper (which is too much effort on the player, in my opinion) or whatever, it's not enough of a justification for how little of a benefit it would offer. Sometimes, things are just incompatible, and you have to compromise.