nesdev.com

What we actually need at this point is this image running on actual hardware. What's often not taken into consideration when drawing graphics on the NES is what the end result looks like under NTSC on an actual TV. The difference can be substantial. The closest thing we can do (without an actual NES ROM of this) is to use blargg's ntsc filter library to see what the results "might" look like.

Are the above graphics available in any kind of format that's generally compatible with the NES, e.g. name table + attribute table + pattern table + palette data? If so, I can probably throw together a ROM of it. I can get video output from an actual NES as well. Tepples' Graphics Editor should be able to do all this with ease (and I'm happy to put in the time). In fact, since the source image is PNG, I think I can do it now... I'll give it a shot.

Blargg's NTSC filter covers the vast majority of "unexpected" changes from clean pixels to a real NES environment. The NTSC conversion creates several types of artifacts (most notably with 50% dither), but everything beyond this is really just things like colour gamut and scanlines, kinda superficial stuff.

If you're running windows, you can get a ready-made build of blargg's program here: viewtopic.php?f=21&t=11947

Here's what your last image looks like through the NTSC filter:

Thanks, rainwarrior -- I had no idea there were pre-built binaries for that (I dug around blargg's site first looking for 'em). I was getting no where with the Graphics Editor due to Python problems (guess tepples will have to work these out).

Thanks! I began in yy-chr, but i'm trying out shiru's NES screen tool at the moment. The tileset contains a fair amount of garbage, but i can export it in a minute to save you the hassle if you still want to test it on real hardware.

Just installed cc65 too, but haven't set it up yet. the .cfg gave me a slight headache but i've seen that topic answered eslewhere.

the ntsc thingy made the mountain reflection very teal. Maybe a bit weird?

_________________
http://www.frankengraphics.com - personal NES blog

No need to test on hardware given blargg's NTSC filter -- what you see above is pretty much what you'll see on actual hardware (hues/etc. are going to vary based on people's TV screens though).

As for the teal reflection: welcome to the NES's limited palette (and when drawing graphics in editors like YY-CHR, no palette there is ever going to match the NES perfectly, sorry to say) and NTSC (a.k.a. "Never The Same Colour"). This is one of several reasons why an artist seeing their work on real hardware (or as close as possible -- blargg's stuff is pretty damn accurate) is important.

The NTSC demo program lets you control contrast and sharpness with the mouse, I think I took the picture with high contrast. In general, though, this is to be expected when you go between different TVs and monitors, relative contrast of colours is going to vary a lot.

Brightness is consistent up and down a single hue column, but when you're mixing colours on the same row especially, different TVs will shift the brightness of various hues up and down. It won't be a robust relationship.

Ok, so nesst is repeatedly throwing me an access violation when i try to open my last session. At least i have the png, but this kind of blows. Anyone else get this error with this file?

https://sprend.com/download.htm?C=4c1e6fed65924ce3ba31749fdb72307b


Very valuable lesson! Was this ever in practice or was it avoided at all costs?

_________________
http://www.frankengraphics.com - personal NES blog

I don't think there's anything about it that warrants "avoid at all costs". I mean, most graphics will still look "fine" if you put them on different TVs, even though the balance of hues is different. The question is really how much worse it will look, which depends one how you use it.

The problem is when you spend a lot of time trying to get even colour balance on your personal version of the colours, you will end up making art that starts to look bad as soon as that subtle balance is disrupted.

A lot of games go with "monochromatic" palettes. Many Mega Man games tend to use only 1 hue column for a single tile or sprite (and/or black/white). This is very robust because you're avoiding the hue balance problem entirely. The tradeoff is obvious though: missing out on potentially interesting colour combinations.

If you go into it with the right expectations, mixing hues is not verboten. Just try to test it out in different environments sometimes. Stick it in an emulator that has hue/brightness/contrast/sharpness controls, for example, and see how it stands up.


NES music has a similar problem: if your mixing relies heavily on subtle balance of volume (especially with Famicom expansion sound), as soon as you take it to another machine with different balance, the mix falls apart. On the other hand, if you write in a way that can tolerate various channels being a little louder or softer, you get a result that will sound well on many machines. I think this is one of the reasons Bach's music turns up in video games so often; his style of contrapuntal writing doesn't rely on balance like that.

Like, I often see ZX Specrum art using rainbow colours, and I think the reason is basically that because it only has two brightness levels for any given colour, hue is being used as a substitute for finer brightness control.

The same phenomeon happens on the NES. The granularity of brightness is quite limiting, and it's tempting to use hue to compensate; but as just stated, this is unreliable. It's basically... the NES is a low precision machine in this respect. If you try to make distinctions that are smaller than its level of precision, they just aren't going to hold up well. Hue distinctions that are stronger than the basic granularity of precision will still work fine, if you understand what I mean.

• choosing three colours "vertically" so there is no change of hue: this works fine, the NES should always be consistent (i.e. monotonic brightness) within a column
• choosing three colours "horizontally" so there is no change of brightness: the imprecision of the system will cause different hues to stand out more depending on whose machine it is.
• choosing three colours "diagonally" so there is a change of hue and brightness at the same time: this usually works well because it is not relying on hue or brightness alone.

I think the worst problem is caused by semi-horizontal colours. Like, if you take two colours from row 1 and a third colour from row 2, and expecting one of those "hues" to be in between the other two in brightness. I see people try this a lot when they're given an "NES palette" and assume it's going to look the same everywhere.

Guilty as charged, the lake does precisely that! I suppose PAL has the same problems too for the same reasons. I could either make it black if i wanted it to be more sturdy, or experiment with wider/tigher hues, or come up with something different, but i'm stuck with the file problem atm.

I've tried a couple of things to get nesst to open the session now, but nothing gives so far. I call it a day. We'll see what happens tomorrow.

_________________
http://www.frankengraphics.com - personal NES blog

If you still have the palette data, and you are willing to install Python and Pillow (see Windows instructions) and learn to use the command prompt, you can use the savtool.py program that ships with my on-NES graphics editor to attempt to reconstitute the CHR and NAM from the PNG.


In Haunted: Halloween '85, whose backgrounds are dark in general because it takes place at nighttime, I tried to discourage the artist from using $06, $07, and $08 in close proximity because the result was muddy on my TV. But the artist insisted on grounds that the artist liked how it looked in the emulator-derived palette he was using, and the results were (barely) acceptable on his NES + PowerPak + TV.

Or one can't because Python strikes again. I look forward to knowing what the bug there is.

Does this exception clear up if you convert the PNG image to indexed format, as opposed to RGB? Where is test3-256x240.png with which to reproduce?

It was created using convert.exe -resize 256x240 in ImageMagick 6.9.2 for Windows. Original PNG is in this post, resized PNG attached. Still looking forward to knowing what the bug is. :-)

I reproduced the bug, and my suspicion was correct: savtool currently 1. does not support source images that are RGB as opposed to using a colormap, and 2. produces a traceback instead of a comprehensible warning if the user attempts to convert a file that is RGB.

I opened test3-256x240.png in GIMP and noticed that convert had scaled it down with anti-aliasing, which distorts colors on edges. When reversing magnification of pixel art, use point sampling, also called nearest neighbour. So I opened the original PNG in GIMP, converted it to indexed color, and scaled that down to 256x240 pixels with nearest neighbour.

Because I did not provide a 32-hex-digit palette string, it used the default (grayscale) palette.