For the Tech Guys: Planar vs Chunky Pixel organization

[tomaitheous]

I can see how LZ77/LZSS compression could help, but I barely understand the offset principle in the first place.

You know, I read quite a bit of tutorials/doc about LZ/SS and didn't quite follow along. Note with a solid understanding. I figured it out on my own because I was RE'ing a compression scheme I hadn't seen before (I was documenting it and wrote a decompressor). At some point in time (within a coupe of months), I realized that it was LZSS. Sometimes, when you don't have some sort of relative experience with a specific system or such - it's hard figure out/ get things to click. Once I understood how LZSS worked, it was easier going from there to learn others (huffman, gamma, etc).

The best analogy I can give you is this: The file is a book. The 'window' is a cache of pages. Pages you just read. But only recent ones. This 'window' lets you look back at these previous pages. But *only* up to say.. 5 pages back. As you progressive further in the book, so does the 'window' of pages you can look back upon. This is called a sliding window mechanism.

Now for LZ, you apply that same window, but with writing a book. Same concept, you can look back at 5 pages. So say you've written up to 29 pages, the furthest your 'sliding window' will allow you to look back on, is page 24. Now for the second part of LZ. There are control codes. In standard LZ there are two. One is for you to write unique/new words and sentences into your book. The other control code lets you copy any words (and whole strings of words <- that's important) from the previous pages you've already written (but remember, only up to 5 pages back from the current position). Obviously in English, there's going to be quite a bit of words you can copy (due to redundancy of words and strings of words). Lots of repetitive phrases or words (including spaces and periods. All of it). That's the basic principle of LZ/SS.

This next part is going to sound a little strange, but this is in relation to planar VS packed pixel. Think of packed pixels as whole letters. And think of planar as a letter broken up into 4 parts. Now, say you had a page with lots of text. On a Planar version of that page, there would be 4 pages. One page with each 1/4 part. Sounds kind of convoluted and complex, right? To your human mind, what do you think would be easier for you to compress into the smallest amount/space (via reference - sentences/words/etc)? A page with full letters or four pages with divided parts of letters? I think the obvious answer would be the whole letters >_>

Now, don't look too deep into that last analog because it's kind of flawed. But it gets the point across, I hope.

Tom that demo you linked to is pretty neat, I don't think I've seen transparency on the TG16 before. This is all possible just because of planar then?

Correct. The planar system of the tiles/sprites (no sprites in that demo though), is basically a hardware assist for that effect.

Is this something similar to what the SNES does, or is that more normal alpha channel stuff?

No, the snes does color match after it fetches the planes bits and assembles them into a single pixel.

Also, I am a bit worried that I am confusing linear packed pixels with linear pixel displays.

Yeah, that's a problem with this discussion (because it covers both and sometimes at the same time). One doesn't necessarily have to do with the other. Cell (tile/sprite) based display can be planar or packed pixel (linear). And line based display (linear display) can be planar or packed pixel (linear) as well. I think part of the discussion is whether planar or packed pixel on a cell based display, has any advantages of one over the other - if one is trying to do a make shift line based display out of this cell based display. And then how does each one relate to compression ratios. Follow?

My prior understanding was that all of these systems displayed in 8x8 tiles, though some had different tile sizes available, and they "packed" the tiles as efficiently as possible on the ROM.

That's the idea. But Amiga and ST were also brought into the conversation (at least I think, without looking back). They have line based displays (although software tile engines ). One would assume the pixel format the tile or cell was in, would be optimal for whatever compression for the time/era. But that's not necessarily true. Planar is more of a carry over from older tech. It had hardware advantages since pixels weren't even byte sized just yet (among some other advantages). I don't think it's any coincidence that Sega moved away from planar to packed pixel for the Genesis. It also lends it self better to certain types of manipulation - like scaling, rotation, distortion, etc. This is also why one of the SNES tile pixel format is not like the other modes. Mode 7 *is* packed pixel, not planar like mode 0-6. Sega arcade systems around the time of the Genesis, were also packed pixel. It's possible that they had additional features in mind for the Genesis VDP, that never made it into the design. One if the things with packed pixels sprites that Sega did, was give a terminator value for one of the colors. You lose one color, but you can both compression in vram as well as more sprite pixel bandwidth. If you have a 4x4 pixel bullet sprite, you still need 8x8 pixels in vram to define it (it wastes vram). It also wastes sprite pixel scanline limit, because the 4 invisible/transparent pixels on the horizontal row of pixels, still contributes to this limit. So a packed pixel display has the advantage off optimizing against this limit, in the context of these console type hardware systems.

Before I get too far off point here, packed pixel (linear) compresses better with LZ based compression than planar does. But you can convert between both formats. This means you can take your graphic data for the PCE/SNES, convert those to packed pixel (which doesn't take any more space, it's still 4 bit) and then send it through the compressor, and plop it in rom. On the game side though, you'll have to convert that packed pixel format back to planar before you can write it to the display. This process is too slow for realtime, thus why ram is important. The more ram you have, the more you can do this process in between areas (aka cart loading) and cache/buffer these converted tiles for later use. Thus, the Genesis/PCE/SNES now all have the same compression size capability, but with the PCE and SNES having additional over head in the cart loading sections/parts. And on the PCE hucard side, almost non existent because of the tiny ram. PCE CD games are like a PC, all ram mode - so it's not a problem (and in fact optimized games do just this).

The result always looked to me like a tile puzzle with Genesis games, and I assumed that basically everything would look as complicated.

Beside viewing them out of order, part of the mechanism of a cell and map based display, is to compress graphics by removing redundant graphic data and replace it with a reference. The down side is, you have artifacts of an 8x8 segmented system. To get around this, you create more unique cell data. But then your also decrease the benefits of the built in compression mechanism of a cell/map based display. Early on in the 16bit generation, this wasn't really an issue. But near the end, you really see games starting give the appearance as if on non tiled based display. Both Genesis and SNES (especially top tier SNES RPGs).

[kool kitty89]

Also, I am a bit worried that I am confusing linear packed pixels with linear pixel displays. If you don't have time to explain that further I understand. My prior understanding was that all of these systems displayed in 8x8 tiles, though some had different tile sizes available, and they "packed" the tiles as efficiently as possible on the ROM.

They should be the same thing, and no packed pixel format has nothing to do with tile graphics in general, it's just a type of bitmap data organization.
Linear/packed is just like it sounds you have one pixel and then the data for the next packed right next to it in one clump: ie for 4-bit pixels you'd have 4 bits for one then 4 bits for the next.
But for planar, all graphics are organized into 1-bit per pixel planes that then combine to provide higher bit-depths: in the simplest sense you have 2 bitplanes overlaid as such so you might think of it like this:
say you had a blank piece of paper and 2 translucent colored lenses (say red and blue), so each lens would be a bit in a bitplane to be turned on (1) or off (0), so if neither are on you get white, if only red is on you get red, if only blue you get blue and if both are turned on then they overlay and you'd get purple. That's opposed to packed pixels where it would be more like having 4 different color blocks to chose from directly (2 bits defines the 4 values) and you always have 2 bits per pixel. (in the planar case you could remove the entire 2nd plane and cut the memory use in 1/2 but only having use of white and one color)

The result always looked to me like a tile puzzle with Genesis games, and I assumed that basically everything would look as complicated. I do still intend to start farting around with graphic comparisons between systems, I just had some nonsense in the real world to deal with recently.

Yes, that's how tile or character based graphics work, but that's totally separate from chunk and planar bitmap organization. (and tiles/sprite cells ARE just small bitmaps)

The difference between a character or tile based display and framebuffer based display is another issue entirely and basically:
a framebuffer you have the whole screen as a single bitmap being drawn and you thus need enough RAM to be able to allow that. You're also limited to a single palette per screen, or per line if you use scanline tricks (amiga does that in hardware).
Tile/character displays build the display from individual cells stored either in RAM or pulled straight from ROM (most home computers, the 5200, and NES pulled straight from ROM while the ColecoVision, Master System, PCE, SNES, MD and such all had to load tiles into dedicated video RAM -the advantage being not having to share the main bus or not having to add the cost of a second ROM bus like the NES did with a bunch of added pins -many arcade boards did that too). With character based displays you map the characters/tiles in RAM as the tilemap with each tile mapped more or less like a pixel in a bitmap (so for the Master System it was normally a 32x24 grid of 8x8 pixel tiles). You can use any tile any number of times you want: so you could have a full screen mapped with 1 8x8 pattern, and smaller games (less ROM) have to work within limits and thus tend to use many fewer unique tiles than later games.
I think the tile map also controls the palette index chosen so you could also use different color choices for the same graphical tile without using more VRAM or ROM for tile data.

I also mentioned in terms of the Master System and NES (back with Double Dragon) that the SMS had things tighter if ROM sizes were equal due to the higher color depth, and that would apply here too: for the SMS you have 4-bit tiles stored in video RAM (and updated from ROM) vs 2-bit in ROM on the NES, so short of any compression the SMS would have to cut total tile/sprite count (including animation) by 1/2 compared to the NES and even with compression it would be just as limited as to what it could fit in video RAM and how frequent the updates would be. Uncompressed SMS tiles/sprites take up the same amount of space as uncompressed Genesis graphics (or SNES/PCE ones for the 4-bit modes) and the SMS didn't even have a 2bpp mode to address that either AFIK. (albeit then the graphics would be a lot closer to the NES in general color, though with the different master palette -generally weaker on the SMS)

(the VGA default palette is useless and i'm quite sure no game really uses it, unless its some shitty BASIC game)

Hmm, many games seem to from what I've seen.
Chilly Willy posted Wolf3D's palette and it matches exactly (albeit the image he provided had the colors organized differently than wiki's default palette image). One obvious givaway is the prominent inclusion of the CGA palette (EGA default palette) as well as a fair number of redundant entries in general. (many of the CGA colors plus several additional black entries)

It's the same palette as MS paint uses by default for creating GIF images and saving 256 color bitmaps: that's oen easy way I've been checking things too, taking unscaled/uncompressed (or lossless) screen rips or texture images and saving them as 256 color bitmaps in paint to see the results. (ie if no color loss then it's using the default palette)

Of the games I've tested positive there's: X-Wing, Tie Fighter, Wolf3D, Doom, Rebel Assault, and a few others iirc but I can't think of them. (there's a ton more I haven't tested but I think Lucas Arts in particular tended to opt for that palette for whatever reason)
Interestingly the Sega CD port of Rebel Assault seems to keep all of its colors within the VGA default palette as well, so it seems like they directly converted the VGA graphics to genesis rather than converting higher color versions more specifically to the palette. (that game also has the worst compression artifacting and worst tearing of any MCD game and wosr artifacting of any PC FMV I've ever seen either -they probably should have dropped the screen size and/or resolution to avoid that -especially if they used double wide pixels for the video layer and blitted full res 2D graphics on top of that)
Also interesting is that they made pretty much no use of sprites and only sparing use of dual BG layers in rebel assault (and pretty much only in cutscenes) with all the in-game stuff rendered to a single 16 color frame on the same plane as the streaming video.



And tomaitheous, you could do similar pseudo-transparency to that with any planar based system, right? (or at least planar bitmap ones) Though you'd have to cut the colors back and the amiga has EHB to do that with just 1 bitplane effecting the full palette.

[kool kitty89]

Oh, I meant to ask earlier: in the cases where lossless compression was used, was that normally only for data that was loaded into VRAM before a level or was it also done for on-the-fly updates? (I'd think the latter would eat up a lot of CPU time)

And were any lossy compression schemes ever used, particularly if they were less computationally intensive and facilitated on-the-fly decoding? (the only one at the time that would probably fit is cinepak-like vector quantization, which might have been OK for stuff at less than 3:1 compression, if it were indeed less intensive than LZ decoding)

[tomaitheous]

Hmm, for working with planar graphics in general, couldn't you work with rows of pixels at once rather than a pixel at a time to cut down on overhead? (ie write 8 bits to one plane -or whatever word size used, then the next, etc so it would be closer in speed to writing rows of packed pixels)

It would still be the same number of memory fetches (read/writes). Either 8 bytes for 8 1bit writes, or 8bytes in a row for packed pixel. Same either way. The only thing would be that you would need to mask out the bits if the line was anything less than 8 pixels from start to end, on a planar system. So more processor work. Where as byte packed pixel you could just technically just overlay the data (because of how it aligns on byte boundaries).

Yes, but even then, if you had to use full 8bpp tiles that still would exceed 32kB for one frame in the case of Dirt Trax's 216x176 window (all rendered on layer 1 in mode 3, no sprites, no other BG tiles -at least going by BSNES and SNES9x), so that's 27x22 8bpp tiles and would take up over 37 kB, so would not fit into one tile bank and could not be fully double buffered, though perhaps buffered enough to avoid tearing. (ie the unbuffered section could fit into one VDMA period) In the case of Doom, you've only got a 216x144 window, but still a 216x176 screen with the 16-color tile/sprite status bar. (so there would need to be room for those tiles/sprites -plus the hand/gun sprite overlay. (the posterization in the shading used for SNES doom also made me think less than the full 241 colors were being used, even with some compromises for the few 16-color tiles used -as it is, the PC's default VGA palette was used so not optimized for Doom specifically and thus limited as well -It's really odd how many games stuck to the default palette)

What does the vram buffer look like in bsnes debugger, for any one of those games? That would answer your question

1-bit graphics would be the same for planar and packed; there's only one plane either way so there's no distinction between packed and planar organization until you have at least 2bbp, right?

Correct. 1bit is just 1bit. Both and neither planar and packed pixel

Oh, I meant to ask earlier: in the cases where lossless compression was used, was that normally only for data that was loaded into VRAM before a level or was it also done for on-the-fly updates? (I'd think the latter would eat up a lot of CPU time)

I can't answer on the snes side, but given the amount of ram to cache/buffer tiles/cells - I would guess games wouldn't be doing much realtime decompression (maybe just tilemaps, but given 128k of ram no need even for that). On PCE, both. Realtime and downtimes. I've seen RLE schemes with control codes to pad missing bit planes on top of the RLE scheme (some do RLZ or RLC, variants of RLE. I've seen a few different types). It's quick enough that games did this in real time for sprites and such. Though some hucard games didn't even go that far, and just limited themselves to what was loaded into vram (all sprites and tiles) - hence the simplistic look of a lot of early games too.

And were any lossy compression schemes ever used, particularly if they were less computationally intensive and facilitated on-the-fly decoding? (the only one at the time that would probably fit is cinepak-like vector quantization, which might have been OK for stuff at less than 3:1 compression, if it were indeed less intensive than LZ decoding)

Other than the 4bit to 3bit, which is a form of lossy compression if they restrict themselves to that lower bit depth or reduce afterwards when cutting back for space, I don't know of any else that's lossy that I've run into.

[kool kitty89]

What does the vram buffer look like in bsnes debugger, for any one of those games? That would answer your question

I'll have to check that, but if it truly is nothing but 8bpp (which seems likely now that you explained it) that would make me really wonder why Mode 7 wasn't used as the super FX didn't do chunky to planar in hardware AFIK and the overhead should have been less for mode 7 as such, plus you get a full 256 color palette independent of sprite/tile entries and you'd eliminate any small overhead from rendering 2 pixels for each double wide pixel vs mode 7 stretching it in hardware.
a 104x144 mode 7 plane (13x18 tiles) shouldn't have taken up more VRAM or DMA bandwidth than the 216x144 mode 3 layer they used. (even with the large tilemap inflating that)
Actually it might have even been preferable to drop the resolution even further to allow a significantly higher framerate and even a larger screen size. (like the 112x96 window used by wolf3D with 2x2 scaled pixels, or push it a bit further than that, perhaps 120x96)
I think I'd have taken blocker graphics if it meant a realistically playable framerate, less lag, AND a larger gameplay window.

[awack]

I developed a program that allows compressed graphics to go from ROM straight to VRAM(it will uncompress everything in ROM) you have to have a flashcart of course...i call it, awack-unpack.

Is that even believable?


From my understanding, most snes games didn't use compression for graphics, i dont know if any one here knows if this is true or not.

[kool kitty89]

Straight to VRAM? You mean streaming compressed data to CPU work RAM, using the CPU to decompress it and then sending it to VRAM?

[tomaitheous]

Hehe, awack-unpack. That actually does sound like a real decompression/app name.

From my understanding, most snes games didn't use compression for graphics, i dont know if any one here knows if this is true or not.

Open up any SNES rom inside Tile Molester or other direct tile editor/app. You won't see the graphics, because they're compressed

NES on the other hand, had a lot of games that used VROM (and most with a mapper). There's no compression for VROM mode, and that makes hacking NES games fairly easy (which is why there are so many little GFX hacks for the system).

[TmEE]

Hmm, many games seem to from what I've seen.
Chilly Willy posted Wolf3D's palette and it matches exactly (albeit the image he provided had the colors organized differently than wiki's default palette image). One obvious givaway is the prominent inclusion of the CGA palette (EGA default palette) as well as a fair number of redundant entries in general. (many of the CGA colors plus several additional black entries)

I'd like to see the Wolf3D palette.... I see lot of colors there that are not in the VGA default palette...

Can you name me some games, so I can check them out ?

[kool kitty89]

I'd like to see the Wolf3D palette.... I see lot of colors there that are not in the VGA default palette...

Can you name me some games, so I can check them out ?

Was I correct in assuming that MS Paint saves GIF and 256 color bitmaps with the default VGA palette? (otherwise I'm off -I know that saving 16-color bitmaps defaults to RGB-I albeit not the CGA palette but the uglier true RGB-I)

I've taken 24-bit bitmap and PNG screen captures from Rebel Assault and X-Wing as well and both seem to comply with the default palette (ie no loss when saving in MS Paint), that's one interestign thing I found with Rebel Assault on the Sega CD too, all complying with MS Paint's default 256 color palette. (while Sewer Shark most definitely does not -and most others I've tried) Interestingly the colors used Virtua Racing on the Genesis seem to all fall withing the default palette as well. (I noticed that when there was no dithering or color loss when saving as GIF or 256 color BMP in paint -Star Fox dithers/posterizes significantly by comparison -even just the polygon layer)

And here's the palette that Chilly Willy posted for Wolf3D a while back:

[awack]

Straight to VRAM? You mean streaming compressed data to CPU work RAM, using the CPU to decompress it and then sending it to VRAM?

Thats the magic of awack-unpack it doesn't need the CPU to decompress graphics.

Open up any SNES rom inside Tile Molester or other direct tile editor/app. You won't see the graphics, because they're compressed

I did that a year ago with just one snes game and found that the graphics were compressed, but read recently from a romhacker that allot of games did not have compressed graphics,which is were my confusion comes from....i will have to try tile moletor out again sometime.

[kool kitty89]

Thats the magic of awack-unpack it doesn't need the CPU to decompress graphics.

Yeah, the joke went over my head the first time I read it.

For a second I thought you might have been talking about using the RAM in a flash cart to work in... but you'd only have the interface MCU on the cart to handle that, right? (and that's not really programmable as such)

[TmEE]

Was I correct in assuming that MS Paint saves GIF and 256 color bitmaps with the default VGA palette? (otherwise I'm off -I know that saving 16-color bitmaps defaults to RGB-I albeit not the CGA palette but the uglier true RGB-I)

I've taken 24-bit bitmap and PNG screen captures from Rebel Assault and X-Wing as well and both seem to comply with the default palette (ie no loss when saving in MS Paint), that's one interestign thing I found with Rebel Assault on the Sega CD too, all complying with MS Paint's default 256 color palette. (while Sewer Shark most definitely does not -and most others I've tried) Interestingly the colors used Virtua Racing on the Genesis seem to all fall withing the default palette as well. (I noticed that when there was no dithering or color loss when saving as GIF or 256 color BMP in paint -Star Fox dithers/posterizes significantly by comparison -even just the polygon layer)

on XP the MS-Paint palette is not VGA default, at least not in the right sequence. When I get home I'll see what 9x Paint does.

And here's the palette that Chilly Willy posted for Wolf3D a while back:

That is most definitely not VGA default palette there. The first entries are indeed, but the rest not.

[kool kitty89]

on XP the MS-Paint palette is not VGA default, at least not in the right sequence. When I get home I'll see what 9x Paint does.



That is most definitely not VGA default palette there. The first entries are indeed, but the rest not.

I know the sequence is different, the the values in general looked similar... I wasn't positive but the assumption about MS Paint's 256 color palette fit with that too. (no color loss when saved as a gif or 256 color bitmap -opposed to many 16-color indexed images which show significant color loss when converted -including screenshots of Sonic CD's intro)

Edit: OK, Wolf3D and several other games (including doom and X-Wing) oddly seem to use the default MS paint palette, but NOT the VGA palette given this reference: http://upload.wikimedia.org/wikipedi...alette.svg.png
That posterized horribly with off colors and long stretches of redundant colors when I saved as a 256 color bitmap, not even the grayscale row matched VGA's 16 shades of gray.

Oh, and on the topic of default palettes: is it true that EGA's 320x200 and 640x200 16-color modes were strictly limited to the CGA palette or was that simply the default to allow fully compatibility with 4-bit RGB-I monitors? (it would seem like a waste to limit the 6-bit RGB palette to only the high-res mode)