Missing 2 colors from NesMaker pallet

So i was working on some graphics assets and i needed to use 3 different gray tones and i noticed that the NesMaker pallet is missing a a few of colors.

zXVkb5n.jpg


This is the full pallet.

XSGoJnl.jpg


While all the black ones are just duplicates, there are 2 more tones of grey (2d and 3d) that you can use that are not included in NesMaker.
So i started experimenting and trying to figure out why they arent included, i made a simple color test screen and i temporary filled in the 2 missing tones of grey with other colors.

r2qgO6l.jpg


Than i hex edited the rom to replace the temporary colors with the missing colors and i got mixed results.

aEOb1LJ.jpg


While it worked fine on actual hardware, (3d and 10 looked more different on the screen than my phone camera captured it), on the emulator however it was a mess.

JxsJnGw.jpg


The emulator seems to not only display the grey tones wrong, it display all colors wrong in general, i have already ran into this issue before where my game
looks completely different in NesMaker than it does on the emulator, but looks fine on actual hardware.
r6i4n2a.jpg


So yeah, it look correct on actual hardware, the grey tones display correctly and colors in general look closer to nes maker than emulators.

I was thinking that maybe the reason the 2 grey tones werent included was because emulators cant display them right? but should that really matter since the program is for making
games that you can flash to a cartrige and run on a real NES? wouldnt it be better to just leave them in but put a warning up somewhere in the corner that these particular tones dont
look right on emulators? or maybe some kind of a checkbox with a warning in program settings to enable them?

Also on a side note, why were all the duplicate colors left in? like 2 whites and all the blacks on the side, they all look identical both on consoles and emulators so what is their purpose?
 

darkhog

New member
Afaik this is because these two tones can mess up fades, but even if, as I've said in another thread about the same thing in the beta forums:

1d is a must IMO as you may want to do certain elements black. As ford 2d/3d is the only explanation is that "it messes up fades", then a) if you want use fades, then just don't use the colors mentioned, and b) this is completely up to the dev and if he/she still want to use fades anyway, with these colors, it's always possible to create lookup tables for fades. like following (used 0x hex notation because I'm too lazy to press shift each time to get dollar sign):

Code:
;greys
0x1d,0x2d,0x00,0x10,0x3d,0x20,0x30
;blues1
0x1d,0x02,0x01,0x11,0x21,0x31,0x30
;blues2
0x1d,0x02,0x01,0x12,0x22,0x31,0x30
;purples
0x1d,0x04,0x14,0x24,0x24,0x34,0x30
;violets
0x1d,0x05,0x15,0x25,0x25,0x35,0x30
;reds
0x1d,0x06,0x16,0x26,0x26,0x36,0x30
;browns/oranges
0x1d,0x07,0x17,0x27,,0x27,0x37,0x30
;yellows
0x1d,0x08,0x18,0x28,0x28,0x38,0x30
;greens
0x1d,0x09,0x19,0x29,0x29,0x39,0x30
;greens2
0x1d,0x0a,0x1a,0x2a,0x2a,0x3a,0x30
;greens3
0x1d,0x0b,0x1b,0x2b,0x2b,0x3b,0x30
;cyan
0x1d,0x0c,0x1c,0x2c,0x2c,0x3c,0x30

Ordered from black to white for the each hue. Not to mention such lookup table makes easier to fade from a specific color to another as it's a basically a 2d LUT.
 

RadJunk

Administrator
Staff member
Chiming in here. It's more than mess up fades...its that fades going to some of those values can cause conflicts in other parts of the software. Some of those in those rows are "unused" and those unused can cause issues.

As for the looking different on emulators, understand the NES has no real palette. Much of the NES color was completely dependent on the TV, not the hardware of the NES itself, and so games looked dramatically different from experience to experience. That's why emulators can load different palettes...but none of them is "correct"...that's just not the way the NES worked. So be prepared for on some emulators your red to look pink, and on others for it to look more brown. It's just the nature of these approximations!
 
So can we maybe have an option to not use fades in exchange for having those extra colors? or do they mess things up in general even without using fades?
 

darkhog

New member
TheNew8bitHeroes said:
Chiming in here. It's more than mess up fades...its that fades going to some of those values can cause conflicts in other parts of the software. Some of those in those rows are "unused" and those unused can cause issues.

What issues? As people have said, the colors display correctly when hacked in and fade thing can be worked around by using a lookup table as I've shown above (with added benefit of fading from any color to another by interpolating x/y values of palette) instead of dumbly add/subtract 0x10. As for 0x?E column, no one is saying it should be there. In fact, it'd be dumb since that column is black anyways and even if it wouldn't make issues, it's redundant.
 
Top Bottom