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).

Author:

tepples [ Tue Dec 16, 2014 10:11 am ]

Post subject:

Re: NES Styled Pixel Art

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

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.

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.Mayhem in Monsterland (C64) screenshot

Author:

Sik [ Tue Dec 16, 2014 11:07 am ]

Post subject:

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.

Author:

rainwarrior [ Wed Dec 17, 2014 9:04 am ]

Post subject:

Re: NES Styled Pixel Art

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.

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.

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.

Author:

tepples [ Wed Dec 17, 2014 9:20 am ]

Post subject:

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:

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.)

Author:

rainwarrior [ Wed Dec 17, 2014 9:51 am ]

Post subject:

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.

Author:

Sik [ Wed Dec 17, 2014 11:25 am ]

Post subject:

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?)

Author:

tepples [ Wed Dec 17, 2014 11:35 am ]

Post subject:

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).

Author:

Sik [ Wed Dec 17, 2014 1:04 pm ]

Post subject:

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).

Author:

lidnariq [ Wed Dec 17, 2014 2:12 pm ]

Post subject:

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}.

Author:

Drag [ Wed Dec 17, 2014 3:41 pm ]

Post subject:

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:

That would basically work out to the three color cubes of {0,2,4,7; 0,1,2,3; 4,5,6,7}.

Attachment:

vary.png [ 1.21 KiB | Viewed 2027 times ]

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}

Author:

Drag [ Wed Dec 17, 2014 5:30 pm ]

Post subject:

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.