Palettes
Moderator: Moderators
Re: NES Styled Pixel Art
So wait, it's a TMS9918 derivative just because it can display that stuff with more pixels, which is something that would have happened anyway just by technology getting better over time? =|
Also I imagine that with the C64 sprite there was 1) the fact it eats into the sprite limit (not sure how bad it is in this case, although I'm not sure if the resolution could be set per sprite, and even then how it'd affect the programming) and 2) back then porting a game wasn't exactly easy either due to the massive amounts of mismanagement so developers usually would not get time to get anything fancy either (not like today is much better, but at least it's not anywhere as horrible as at that time).
Also I imagine that with the C64 sprite there was 1) the fact it eats into the sprite limit (not sure how bad it is in this case, although I'm not sure if the resolution could be set per sprite, and even then how it'd affect the programming) and 2) back then porting a game wasn't exactly easy either due to the massive amounts of mismanagement so developers usually would not get time to get anything fancy either (not like today is much better, but at least it's not anywhere as horrible as at that time).
Re: NES Styled Pixel Art
The C64 limit is eight 24-pixel sprites, but apparently those can be repositioned mid-screen, so it's in effect eight sprites per scanline at the cost of some slowdown due to raster interrupt processing.Sik wrote:Also I imagine that with the C64 sprite there was 1) the fact it eats into the sprite limit (not sure how bad it is in this case
Multicolor can be turned on per sprite.although I'm not sure if the resolution could be set per sprite
The later C64 game Mayhem in Monsterland appears to have pulled it off, but only for the Bub/Sonic-looking main character, not the Yoshi-looking enemies.and even then how it'd affect the programming
Mayhem in Monsterland (C64) screenshot
Re: NES Styled Pixel Art
I had completely forgotten about Monsterland when trying to remember if it was possible to mix sprite types x_X
And huh, until now I had assumed it was just three sprites (since after all you can have eight on a line and there aren't many overlaps in that game), but that makes sense I guess. And yeah only the player gets this treatment, every other sprite that's multicolor is lo-res.
And huh, until now I had assumed it was just three sprites (since after all you can have eight on a line and there aren't many overlaps in that game), but that makes sense I guess. And yeah only the player gets this treatment, every other sprite that's multicolor is lo-res.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES Styled Pixel Art
I don't think I ever encountered that until the mid/late 90s with "web safe" palettes for GIFs and other images that might need to be displayed in a low-colour mode.Sik wrote:Also while we're talking about random palettes, one thing that annoyed me was when trying to cram non-paletted RGB into 8-bit, it was usually 3 bits for red and green and only 2 for blue... which leaves blue with very few shades in comparison (the steps are still too big to not matter), not to mention making it impossible to make a convincing gray. I was messing around and making red and blue share the LSB would have been a much better idea (I should make an image of that palette again, the one I have is in the old Win98 machine). I wonder why nobody came up with it back then.
With the exception of VGA Mode 13h all of the old video systems I can think of used planar memory organization rather than byte-packing, so number of bits per pixel could easily match the hardware needs (at the price of making single pixel writes much more expensive). The Amiga even had a configurable number of bitplanes, depending on how much memory you wanted to dedicate to it. Of course, these were usually palette indices, and the palette itself was usually written separately, but I don't remember any that tried to pack an RGB palette entry into a single byte.
Re: NES Styled Pixel Art
I first saw the web-safe palette in the shareware paint program GraphicConverter for Mac OS (classic). The default 8-bit palette on Mac OS was a 6x6x6 RGB cube followed by 16-step red, green, blue, and gray ramps. Also:
Sources: EGA, SMS
Code: Select all
76543210 EGA palette entry format
|||||+- Blue bit 1
||||+-- Green bit 1
|||+--- Red bit 1
||+---- Blue bit 0
|+----- Green bit 0
+------ Red bit 0
76543210 SMS palette entry format
||||++- Red
||++--- Green
++----- Blue
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES Styled Pixel Art
Oh, yeah obviously 222 or 111 is fine to be packed into a byte.
Did the Macintosh LC II have an 8-bit chunky format?
Did the Macintosh LC II have an 8-bit chunky format?
Last edited by rainwarrior on Wed Dec 17, 2014 9:50 am, edited 2 times in total.
Re: NES Styled Pixel Art
Yes.
All Macs with color screens have had chunky pixels. This includes every Mac II, every LC, the Color Classic, every Quadra, and every Power Mac.
(The list of 68000 machines with chunky pixels also includes the Sega Genesis, which has been made to run System 7, but I don't think it's in color because Color QuickDraw was never backported to the 68000.)
All Macs with color screens have had chunky pixels. This includes every Mac II, every LC, the Color Classic, every Quadra, and every Power Mac.
(The list of 68000 machines with chunky pixels also includes the Sega Genesis, which has been made to run System 7, but I don't think it's in color because Color QuickDraw was never backported to the 68000.)
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES Styled Pixel Art
The other place I've run into an uneven RGB bandwidth was in DXT compression, which uses 5:6:5. Not a big deal most of the time, but as Sik mentioned earlier, it's problematic for greys, especially if there is a gamma curve in effect or anything else that can magnify the colour disparity. This is a very commonly used format in games today, but it didn't really see widespread use until it became a standard graphics card feature sometime in the 2000s.
It's also a little bit weird, because the 5:6:5 isn't the resolution of the output colour; DXT compression represents a 4x4 block as two 5:6:5 colours and a 2-bit interpolation between them, so there are 2 interpolated colours that aren't strictly bound to 5:6:5 (usually it's expanded to 8:8:8 before interpolation), so a clever DXT compressor can take advantage of this for slightly improved colour quantization.
It's also a little bit weird, because the 5:6:5 isn't the resolution of the output colour; DXT compression represents a 4x4 block as two 5:6:5 colours and a 2-bit interpolation between them, so there are 2 interpolated colours that aren't strictly bound to 5:6:5 (usually it's expanded to 8:8:8 before interpolation), so a clever DXT compressor can take advantage of this for slightly improved colour quantization.
Re: NES Styled Pixel Art
Yeah, but 5.6.5 is not as problematic since it's 64 vs 32 shades. At that point the eye starts having difficulty telling apart the levels (it still can, especially in non-dithered gradients, but the difference is small enough to not make it so obvious). With 3.3.2 it's much worse since it's 8 vs 4. To put into context: with 5.6.5 it may be at worst ~1.56% off from the intended color, with 3.3.2 it would be 12.5%. (btw, 5.6.5 was the most common format for 16bpp on PC)
And yeah, on PC you're unlikely to find 3.3.2 RGB, since programs were either fullscreen programs that were already designed around the concept of a palette (thereby not using any scheme like that) or Windows programs that couldn't use the full 256 palette in the first place. The most notorious offender that comes to my mind right now is the late MSX models, which had a mode where each pixel was one byte and the format was 3.3.2 RGB. Also the SNES in direct color mode (or whatever it's called) is like this, if you ignore the extra LSB (since that one can only be set per tile and not per pixel, making it not that useful). Also on the newer end there's one of those new consoles made for retro-looking games that uses 8-bit pixels, and the format is 3.3.2 RGB x_x (nope, not paletted, WTF?)
And yeah, on PC you're unlikely to find 3.3.2 RGB, since programs were either fullscreen programs that were already designed around the concept of a palette (thereby not using any scheme like that) or Windows programs that couldn't use the full 256 palette in the first place. The most notorious offender that comes to my mind right now is the late MSX models, which had a mode where each pixel was one byte and the format was 3.3.2 RGB. Also the SNES in direct color mode (or whatever it's called) is like this, if you ignore the extra LSB (since that one can only be set per tile and not per pixel, making it not that useful). Also on the newer end there's one of those new consoles made for retro-looking games that uses 8-bit pixels, and the format is 3.3.2 RGB x_x (nope, not paletted, WTF?)
Re: NES Styled Pixel Art
If you're referring to Uzebox and friends, that's because a 3-bit resistor ladder DAC is easy to build.
The Allegro library has a built-in 332 palette, which I assume is for use with dithering unknown photographs to 256 colors.
One workaround for proper gray temperature is to make full scale blue slightly weaker, such that 2 red or green steps equal one blue step. White would be (6, 6, 3).
The Allegro library has a built-in 332 palette, which I assume is for use with dithering unknown photographs to 256 colors.
One workaround for proper gray temperature is to make full scale blue slightly weaker, such that 2 red or green steps equal one blue step. White would be (6, 6, 3).
Re: NES Styled Pixel Art
And ironically white would not be white =P So you replaced one issue with another.
And yeah, was talking about Uzebox, I just forgot the name XD I'm aware of the DAC thing, although the idea of sharing the LSB of red and blue would still have worked just fine in that case (I'm not even sure if it'd have needed another resistor or if the same could be reused).
And yeah, was talking about Uzebox, I just forgot the name XD I'm aware of the DAC thing, although the idea of sharing the LSB of red and blue would still have worked just fine in that case (I'm not even sure if it'd have needed another resistor or if the same could be reused).
Re: NES Styled Pixel Art
Yeah, for the UzeBox one would need to convert the blue DAC to a 3-bit DAC also. Not hard ...
RRGGGBBV does seem like one of the less awkward compromises.
The other way you can "fix" RRRGGGBB is to duplicate the blue MSB to make a 3-bit DAC again, expanding {0,1,2,3} to {0,2,5,7}.
RRGGGBBV does seem like one of the less awkward compromises.
The other way you can "fix" RRRGGGBB is to duplicate the blue MSB to make a 3-bit DAC again, expanding {0,1,2,3} to {0,2,5,7}.
Re: NES Styled Pixel Art
Would it be worthwhile to explore a system of variable 2-bit -> 3-bit mapping? For instance:
RrGgBbyy
R, G, and B are all 2-bit (C, c), but y determines how they map to a 3-bit dac:
y = 0: {C, c, C} ; Normal
y = 1: {1, C, c} ; Light color
y = 2: {0, C, c} ; Dark color
y = 3: ?
RrGgBbyy
R, G, and B are all 2-bit (C, c), but y determines how they map to a 3-bit dac:
y = 0: {C, c, C} ; Normal
y = 1: {1, C, c} ; Light color
y = 2: {0, C, c} ; Dark color
y = 3: ?
Re: NES Styled Pixel Art
That would basically work out to the three color cubes of {0,2,4,7; 0,1,2,3; 4,5,6,7}.
EtA: Braino. That should be {0,2,5,7}; the image is still of {0,2,4,7}
Of those nominal 192, there are several duplicates, with only 176 unique shades.EtA: Braino. That should be {0,2,5,7}; the image is still of {0,2,4,7}
Last edited by lidnariq on Wed Dec 17, 2014 6:21 pm, edited 1 time in total.
Re: NES Styled Pixel Art
Not as colorful as RGB332, but has RGB222's advantage of R, G, and B all being mapped the same way, plus extra colors. A disadvantage is that it's no longer a continuous color space, so color fades would take a bit more logic to perform, but you'd also get that with shared-bit schemes (to a lesser extent though).
It seems like this could be useful though, and it'd be simple to implement in hardware. I was thinking {2, 3, 4, 5} would be useful to add as the unused y setting. The mapping for that would be {C, !C, c}. This way, you have one cube for saturated colors, and three cubes for less-saturated colors in the dark, medium, and light range.Unfortunately, this doesn't create any unique colors; it just provides a way to access colors you wouldn't be able to otherwise. My mistake, this would add a few extra hues to the palette.
I noticed that this is similar to ADPCM, where you have a fixed precision, but you can specify the range the precision covers, giving you more flexibility.
It seems like this could be useful though, and it'd be simple to implement in hardware. I was thinking {2, 3, 4, 5} would be useful to add as the unused y setting. The mapping for that would be {C, !C, c}. This way, you have one cube for saturated colors, and three cubes for less-saturated colors in the dark, medium, and light range.
I noticed that this is similar to ADPCM, where you have a fixed precision, but you can specify the range the precision covers, giving you more flexibility.