nesdev.parodius.com

[blargg]

I liked Loopy's PALTEST demo and extended the concept to show all ~410 colors on screen: (2 grays + 12 colors) * 4 brightness levels * 8 emphasis bit settings + 1 black about 39 duplicates. It came out pretty nice:



full_nes_palette.nes

I took a different approach of keeping PPU rendering off and manually refilling the palette at the proper time mid-scanline. I spread the spectrum horizontally and first tried vertically cycling through the four brightness levels for each emphasis combination. I noticed that I could get a smoother light-to-dark transition if I instead cycled through each emphasis combination for each brightness.

UPDATE: I wrote a color counting program using nes_ntsc and it only counted 410 unique colors (using 8 bit resolution for the red, green, and blue components). Adjusting brightness and contrast didn't affect this number by more than a couple of colors.

[Celius]

Nice Demo! Too bad it only works on Nintendulator. FCEUXD wouldn't play it correctly. I loaded it in FCEUXD, and I was like "This can't be the demo, this is crap." Because it showed like 3 different blues on screen at once. Do you think this would work on real hardware? It seems very buggy. Maybe a little more precise scanline counting would be good, if you can do that.

[NewRisingSun]

[Celius]

[Quietust]

The problem with FCEU is that it only supports three "colour emphasis" modes at once on the screen: "no bits", "all bits", and "some bits" (i.e. any other combination, but only the first one it encounters).

[Bregalad]

It doesn't work under Nestopia for me. Since Nintendulator don't run on my PC but only on the family's PC (because mine is way too slow), I cannot test it yet.

[Quietust]

[Bregalad]

You're right. It seems very shacky. Why not use a standard method for horizontal palette chaning an use tricky tricks only for vertical palette changing ? It sounds much more reasonable to me.

[tepples]

[baisoku]

Disregard the noise, blargg. Nice work. Ditto for the RGB mixing page.

[Memblers]

This is really cool. It made me think of all kinds of crazy stuff, like someone could theoretically draw a picture like this on a cart that has no CHR memory at all. Couldn't it select colors in a given pattern rather than cycling through them all? (Why someone would do that is a whole other thing, but anyways.. CopyNES TV display maybe? heheh).

[blargg]

Hahaha to all who try this on a puny emulator. I developed it on my NES and it is not at all buggy (but it is a hack in the good sense); where do you think the screenshot came from? Not my emulator, ha! It's using the CPU to do all pixel timing, not the PPU, so the edges of colors are ragged by three pixels. If timing weren't perfect the image would roll and be skewed horizontally. To those who suggest I use normal palettes and tiles, this would add glitches on a whole scanline between colors, as with Loopy's PALTEST.

[NewRisingSun]

Inspired from reading those articles about Color Dream's "Hellraiser" cart, I have always wondered about such a thing: putting a custom CPU with the actual game code and PPU on the cartridge, and all the 6502 program does is feed the picture data from the custom CPU/PPU to the NES, and controller input from the NES to the custom CPU; the custom PPU would output a 7-bit color code (4xNES color + 3xEmphasis) for each and every pixel, which the NES program then writes into the NES PPU's palette register.

Of course, that wouldn't work because of the speed issue, as explained previously, unless the cartridge hardware could somehow change the PPU's palette register directly, without using the 6502 CPU.

[blargg]

Here's one with an earlier color arrangement that I like better, since it's clearer what's going on and each color rectangle is more distinct:



full_nes_palette2.nes

As before, run on a NES or an accurate emulator.

[Jagasian]