For the Tech Guys: Planar vs Chunky Pixel organization

Printable View

11-28-2009, 03:18 AM
kool kitty89

For the Tech Guys: Planar vs Chunky Pixel organization

Ok, I understand the genral differences between planar and chunky display organization, but wat are the real advantages of using a planar display and which platforms used them? I know bitplans allow rather arbitrary bit depths that don't work for packed pixels (ie 3,5,6,7-bit pixels -or any that can't be packed into a byte or aren't multiples of a byte)

But there are a number of cases where planar displays are used with depths all convienient for packed pixel displays. (2,4 bpp) Like the NES or Atari ST. The Amiga makes sense with the 32-color display -plus 64-color and HAM, likewise EGA's 640x350 planar mode makes sense as it can use 1 to 4 bitplanes for varying color depths. (higher depts possible with expanded memory)

I assume the TMS9918 series use chunky displays (given the descendant in the SMS does), I understand Atari's GTIA also used (2/4-bit) chunky organization, but did the Commodore 64?

I also know that some some early consoles like the VCS didn't use any type of bitmap organization at all, but a single scanline display, I think the 7800 worked that way as well, and CTIA/GTIA, but in the latter case the display is being driven by ANTIC which does use a bimapped display. (although even with a single scanline there'd still either be planar or chunky organization for the pixels -other than 1-bit monochrome, so I'd guess that TIA and MARIA both use chunky pixel organization)
11-28-2009, 10:17 AM
TmEE

Planar stuff allows for some nice things (such as transparencies at cost of some things) but its pain in the ass to manage on many aspects.
SMS and GG used planar format, MD works on packed pixel

Tomaitheous probably loves planar format and can tell more things about how great it is and whatnot :P
11-28-2009, 02:12 PM
Chilly Willy

Planar is good because it can be an easy form of compression. Say your game is using 6 bitplanes for the display (64 colors) - with planar organization, you don't HAVE to have all the planes... you could only have 3 for your images (8 colors). With chunky, you either need to keep the same size as the display, or convert from one format to the other when drawing. Games that use 256 color chunky graphics (VGA mode x) keep all the images in that format, whether they need to be or not.

Not only do you not need all the planes for planar, you get to choose which planes to draw into. So you can change the colors merely by drawing the same planes into different planes of the display.

Planar format allows more efficient storage of different numbers of colors than chunky. Chunky really only supports what fits EVENLY into a byte - 1, 2, 4, or 8 bits (2, 4, 16, or 256 colors). Planar handles any power of two - 1, 2, 3, 4, 5, 6, 7, or 8 bits. Just add another bitplane. You want 32 colors with chunky? You have to store it as 8 bit. Period. You want 32 colors with planar? Just storage five planes.
11-28-2009, 02:13 PM
tomaitheous

Quote:

Originally Posted by kool kitty89

Ok, I understand the genral differences between planar and chunky display organization, but wat are the real advantages of using a planar display and which platforms used them? I know bitplans allow rather arbitrary bit depths that don't work for packed pixels (ie 3,5,6,7-bit pixels -or any that can't be packed into a byte or aren't multiples of a byte)

But there are a number of cases where planar displays are used with depths all convienient for packed pixel displays. (2,4 bpp) Like the NES or Atari ST. The Amiga makes sense with the 32-color display -plus 64-color and HAM, likewise EGA's 640x350 planar mode makes sense as it can use 1 to 4 bitplanes for varying color depths. (higher depts possible with expanded memory)

Well, you've pretty much answered what the advantages are. Have a display mode color requirement that doesn't fit evenly into odd bit sizes. In that case, it makes efficient use of memory (because working with packed linear pixels would be a pain on the hardware and software side).

There are some tricks you can do like transparency, but I don't think that's what the hardware designers really had in mind when they designed/used a planar system.

Planar on the PCE has some advantages. Since the sprites are 16pixels, if I setup the display correctly (the correct vram incrementor value, sprites cells arranged in vram in the right positions, etc), I can simulate a bitmap display and write a single scanline of pixels to the VDC before repositioning the vram pointer. And if I use tiles, I can a similar advantage - add tilemap repositioning and I can set large linear sections of the bitmap that I can keep writing in a linear fashion (pixel=((Y*256)+(x++); //x=char value). That really isn't an advantage per se of planar, just that it happen to work out on the PCE because tiles are 8x8 (and in planar, writing a word to the VDC means I just wrote 8 pixels @ 2bpp. It requires a second pass for the second half of 2bpp data. Sprite method is similar. I get to write 16pixels at a time, but only at 1bpp at a time. Still, the linear access makes it faster. I can render out stuff on a scanline basis and avoid any math involved for bitmap to tile coord conversion). On the Genesis, I couldn't do this because the 8x8 tiles/sprite cells are 4bit packed pixel. On the PCE, I can also transparency effects like on the Amiga/ST. I set all tiles to 8 colors. All my sixteen BG subpalettes (or less if I don't need them all) are setup with 8 normal colors for the associated tile, then an alternate 8 colors. The alternate 8 colors can be darker or lighter, or some sort of color/tint calculated result. The result is 3bit tiles and 1bit transparency object. You have to setup the tilemap system in a totally different non traditional way - but still manageable/doable for in game stuff. You can also do 2bpp tiles and 2bpp (3 colors for detail, 1 color is completely see through) transparency object. 4 colors for a tile doesn't sound like much or pretty limited, but coupled with 8x8 tiles, up to 16 subpalettes, and 512 color master palette - you can do some cool looking things. If you interlace the PCE tilemaps, you can cut the color requirements down from 4 colors per 8x8 tile, to 4 colors in 8x4 or 8x2 or even 8x1. That makes even more flexible. Anyway, all possible because of the planar format.

What sucks about the planar format: it compresses poorly. For pucrunch (LZSS based) it's sometimes as much as 50% more compression for the same tilesets in 4bit packed linear pixel format. So for some pics, I tend to store them as linear, and on depacking 32bytes - convert back to planar format (and usually immediately upload to vram). I uses a circular buffer system instead of decompressing *everything* to ram first (most of the time), which is convenient for this task.

I heard there was an advantage in some 3D process that's done on the Amiga because of the planar format. But heard of no details. Without looking into it, and since the Amiga can already use a native bitmap system without hackery like on consoles, I doubt the positives out weigh the positives of an 8bit linear pixel format. Sure, you can write up to 32 pixels in a single opcode store (render) for a straight line, but you have to do this X amount of more times/passes. X being the number of planes the system is using. Maybe they are using only like 3 planes and dithering to render flat shaded polygons. And so dropping 3 planes gives it a speed advantage without losing too much detail for a flat shaded polygon system. That's the only thing I can think of. Linear format doesn't have this luxury.
12-10-2009, 02:58 PM
kool kitty89

I forgot to ask: does the SNES use chunky or planar organization?
12-10-2009, 03:07 PM
dragonboy

Snes uses planar, except for mode-7 which uses chunky.
12-10-2009, 07:59 PM
kool kitty89

Quote:

Originally Posted by dragonboy

Snes uses planar, except for mode-7 which uses chunky.

So the other 256 color modes are planar as well? (modes 3 and 4)
10-10-2010, 11:58 AM
sheath

Okay, wrapping my head around this topic while having a head cold (and subsequent hot toddies) is probably a bad idea. At any rate, I am having a hard time with the topic and can't find any resources to delve into. I did find this, but it assumes too much prior knowledge to be readable.

I see Chilly saying that planar was good for compression and Tomaitheous saying it was bad for the same. I can only suppose that you are both talking about different aspects of compression and I missed it.

Tomaitheous also seems to be almost exclusively talking about simulating a bitmap display. Does that mean that the advantages you were talking about were limited to static screens, or are there gameplay examples? I also see a confirmation that the PCE uses 16 pixel wide sprites exclusively. Does that in fact limit the PCE's sprites per scanline to eight as Malle's pce_doc suggests?

I also see a lot of comments about planar being useful for 256 color displays. How does that affect the sub palette advantages of the PCE and SNES? Also prior to Genesis games jumping to 8mbit in general there are a lot of PR statements about Sega and their licensees focusing on compression for 4mbit games. What do we think about these comments having to do with the difference between planar versus packed pixels?
10-10-2010, 02:26 PM
Chilly Willy

I didn't say planar was good FOR compression, I said it was an easy FORM OF compression ITSELF. If your objects only use four colors, you can use two bitplanes for storing the object regardless of the display mode. In chunky mode, you must always store in the display mode regardless of how few colors the object actually takes.
10-10-2010, 03:12 PM
tomaitheous

I'll answer best I can from my experience.

Quote:

I see Chilly saying that planar was good for compression and Tomaitheous saying it was bad for the same. I can only suppose that you are both talking about different aspects of compression and I missed it.

Chilly Willy made the point that planar works for easy compression. If you're not using all the colors required for the display, for a certain block of graphic, it's possible just to drop 'planes' and padded them in later on. This was a very popular technique with early to mid hucard games. The down side is, you need to cut color count by powers of 2. In his example, six 1bit (6bit) would 64 colors. But if you only used 32 colors, then you could get away with only needing five 1bit planes. 6=64, 5=32, 4=16, 3=8, 2=4, 1=2. Since you mention PCE, if you had a sprite or tile and only used 8 colors, you could store it as three 1bit planes instead of four. That's 75% of the original size. If you have fonts, you can store them 1bit with 25% of the original size. Of course you need to pad these images back up to 4bit before sending off to the display controller vram. But it's very easy to do. Usually involves just writing a zero in place of the padded plane.

That's software compression. For hardware compression (or just display), that works out to be something entirely different. Linear pixel displays are 99.9999% 2bit, 4bit, or 8bit. Or even higher. That because a pixel fits neatly into evenly divided and accessible memory configuration. You could do 6bit packed pixel, but it would be pretty convoluted and overly complex to do any sort of pixel manipulation (and even fetching for that matter). Fetching pixels from ram and sending them to the DAC is done at a pretty fast rate. Especially back then (relative to speed of other things). Hardware needs to be as fast as it can and don't want to bulk it up (which directly corresponds to cost of hardware) with additional logic to decode such odd ball schemes. Not to mention the programmer side that has to interface with this type of pixel format (lets assume bitmap display here). When you program low level, you start to see how aligned formats like 1,2,4,8bit, etc lend themselves to logical operations more quickly and manageable than sizes like 3,5,7,9bit etc.

Planar solves the problem. Somewhat. It also adds draw backs. Since planar stores pixels in a series of 1bit planes, you can easily have 1bit up to 16bit or more. So 3bit, 5bit, 6bit, 7bit (all the values in between the linear pixel format up to 8bit) are easily doable on the hardware side. You have the added benefit that any one of those takes less storage than a single 8bit pixel format. So you have a nice trade off between space and max color value per pixel. The down side of planar, on a bitmap display system, is single pixel manipulation is a little bit more work/overhead. Compared to something like 8bit (single byte access, which is nice and clean). Because you basically have multiple 1bit planes. And anyone who's worked with 1bit graphics on a byte based (smallest memory size for cpu), knows the pain of having to shift the image to do 0-7 pixel offset (or a DMA device that's planar friendly). Better hope you have a cpu with a 32bit shift register too (even then. If your blitted object is wider than 32pixels - have fun ;) ), if you have a lot of bitplanes (that, or you store them preshifted horizontally in 8 frames per 'frame').

The above is mostly for computers and not PCE/SNES (which are the planar systems you're talking about). I say mostly because you're rarely going to be doing pixel based stuff on these old systems. That's what the sprites and tilemaps are for. Video acceleration so you don't have to do such manual work on the cpu side.

For more serious compression schemes, planar tiles/sprites of consoles don't compress as well as linear packed pixels. It probably doesn't help that PCE and SNES use composite planar format, too. Linear packed pixels in this context would be 4bit (Genesis). And this is evident, not just by my own experiences and results with LZSS and planar tiles/sprites, but also evident in later SNES/PCE games. SNES even had hardware packed pixel to planar converters in the decompression chips (and other addon chips too). Sometimes the savings is as much as 30% or more over LZSS compressed planar graphics. It all depends on the graphics being compressed, but I've never seen 4bit planar compress better than 4bit packed pixel (yet) on such LZ variants.

The reason why SNES uses planar format (and it's composite planar like PCE, not linear planar), is that there are 2bit tile modes for some graphic layers in quite a few graphic modes. Circuitry wise, it's easy to adapt a downgrade system that only fetches half the needed planes (you reuse existing logic on the IC). It also makes it more simple in that there aren't two different pixel formats to store.

The PCE probably has some other reasons. The system was designed and developer solely by software developers, not hardware developers. The original creators were on the record for stating they wanted to design a powerful setup but easy to program for/approach. Planar format was fairly popular when the PCE was being designed (from home systems to arcade systems) and that probably played an influencing factor. That probably extends to graphics tools too and familiarity. The other factor, which is little known to most, is that the PCE has 2bit planar modes. You can independently select whether the BG or Sprite plane is 2bit or 4bit. And there's actually a game that runs sprites in 2bit mode (Fighting Run). The video chip in the PCE was also designed to run in other setups besides the PC-Engine, so it makes sense to give that as an option (it has a whole setup up and registers for running without the second 16bit chip in the PCE). A fun note, you can select between 2 and 4bit for whatever layer, on any scanline with Hsync interrupt. Cool for demo effects, never exploited in game though (that I know of).

Quote:

Tomaitheous also seems to be almost exclusively talking about simulating a bitmap display.

I was talking about some serious/advance level exploits of the video hardwares. And yeah, mostly stuff more relative to bitmap display stuff. But no static screens. Any sort of rendering and even transparency effects: http://www.pcedev.net/demos/transparency/test0.zip

Quote:

I also see a confirmation that the PCE uses 16 pixel wide sprites exclusively. Does that in fact limit the PCE's sprites per scanline to eight as Malle's pce_doc suggests?

Which doc would that be? PCE sprites used 16x16 cells. The 16 sprites per scanline is kind of a simplistic explanation (and inaccurate in most situations). A sprite can be 16x16 up to 32x64. It's 16 cells per scanline (which adds up to 256 pixels which is the internal buffer that the VDC fills up with sprite fetchs during hblank). If all you used were 32 wide (two cells wide) sprites, then you could say 8 per scanline (for that programmers configuration).

Quote:

I also see a lot of comments about planar being useful for 256 color displays.

Against a single byte (8bit) setup? I see no advantages.

Quote:

How does that affect the sub palette advantages of the PCE and SNES?

It doesn't. How the pixels are stored, is irrelevant to how they are applied to subpalettes.

Quote:

Also prior to Genesis games jumping to 8mbit in general there are a lot of PR statements about Sega and their licensees focusing on compression for 4mbit games. What do we think about these comments having to do with the difference between planar versus packed pixels?

AFAIK, Genesis games were using LZ based compression fairly early on. Given the Genesis nice chunk of 64k of ram, it makes decompressing graphic stuff for use where ever in a level (like animation, etc) - much much more applicable. You decompress some tiles/sprite, stick them in vram. Then decompress some more tile/sprites for use through out the level. Then start the level. The compression scheme might be kind of slow, but it compresses better. And since it's at the start of the level/area/dividing part/whatever, it's not noticeable. Compare that with compression schemes that limit colors (like 3bit storage tiles/sprites for planar stuff) and simplistic compression like RLE that's much more realtime friendly, all in which still don't have as good as savings - and you can see the obvious advantages. But, I don't remember seeing advertisements about this for Genesis games. Heh. Look at Parodius for SNES and PCE. Both are 8megabit carts IIRC. But the PCE one has limited compression scheme because of the 8k of ram, while the SNES has 128k of ram for a better compression scheme. The PCE game is missing two levels.

Also, I should note something about the PCE. The tiles are in composite planar format, while the sprites are in linear planar format. The reason for this, is that the VDC is a 16bit device. Everything is 16bit (it's the smallest sized memory element): all addressing is done in words not bytes, all vram reads/writes are done in words not bytes, etc. This also means it fetches only words from vram for building out the display. The sprite cells are fixed at 16 pixels wide. And one WORD of a 1bit plane is 16pixels (it fetches one WORD from each of the four bitplanes). But tiles are 8pixel wide. It would be a waste to throw away a BYTE in a WORD read. So the VDC reads in a WORD for tile data, but that WORD is 8pixels from plane 0 and 8 pixels from plane 1. Tile planes 2 and 3 are stored 8 WORDs further down and the VDC fetches those last two planes on the next access/read. Hence, tiles are stored in composite planar (a pair of 2bit tiles) and sprites are stored in linear planar ( four 16x16 1bit planes in full sequential order).
10-11-2010, 12:45 AM
kool kitty89

Quote:

Originally Posted by tomaitheous

Chilly Willy made the point that planar works for easy compression.

And that's lossy compression (if you intentionally cut back to fewer colors), of course, but was better than nothing (ie cutting out graphics/animation entirely)... actually that wouldn't be too bad for FMV either for SNES (hypothetically) or PCECD prior to proper lossy schemes being applied (opposed to plain uncompressed 4bpp stuff like early MD FMV did), with PCE you'd have more subpalettes facilitating that but SNES with the larger palette. (and you'd have other trade-offs like using a low-res scaled mode7 plane for FMV or goign the other direction and using 4 color tiles maybe in some cases -probably not though)

Quote:

Of course you need to pad these images back up to 4bit before sending off to the display controller vram. But it's very easy to do. Usually involves just writing a zero in place of the padded plane.

OH... so you wouldn't save any VDMA bandwidth or VRAM space by doing that for the SNES, PCE, NES, SMS, etc... I was thinking you could fir more graphics in VRAM that way too, and save bandwidth.
Is that the same for the 8bpp modes on the SNES: tiles are stored as full 8bpp? (that would make the screen size for Doom and Dirt Trax using mode 3 considerably more odd, especially dirt trax's 216x176 window... which would use more than one full 32k VRAM bank and be impossible to double buffer -yet it doesn't tear)

Quote:

Originally Posted by tomaitheous

The PCE probably has some other reasons. The system was designed and developer solely by software developers, not hardware developers. The original creators were on the record for stating they wanted to design a powerful setup but easy to program for/approach. Planar format was fairly popular when the PCE was being designed (from home systems to arcade systems) and that probably played an influencing factor. That probably extends to graphics tools too and familiarity.

That's interesting and seems like a pretty good idea (if not engineered by experienced game/software designers, at least collaborated with them)... I wonder how some other systems would have turned out had that been the case, or how many other cases were actually like that. (Sega/Sony supposedly tried to do that around 1993, at least according to Kalinske)

Hmm, the 7800 would actually fit there, but the context it was developed was rather different than the market in ended up in in the late 80s, so it's hard to tell.

Quote:

The other factor, which is little known to most, is that the PCE has 2bit planar modes. You can independently select whether the BG or Sprite plane is 2bit or 4bit. And there's actually a game that runs sprites in 2bit mode (Fighting Run). The video chip in the PCE was also designed to run in other setups besides the PC-Engine, so it makes sense to give that as an option (it has a whole setup up and registers for running without the second 16bit chip in the PCE). A fun note, you can select between 2 and 4bit for whatever layer, on any scanline with Hsync interrupt. Cool for demo effects, never exploited in game though (that I know of).

That's still only for 1 sprite layer and 1 BG layer, right? (not dual playfield like the Amiga allowed with split bitplane groups) Did it increase the sprite/line limit at all and were the palette entries any different? (ie for 2bpp mode, did it break the 256 entries into 64 palettes instead of 16?)

Quote:

Originally Posted by tomaitheous

Against a single byte (8bit) setup? I see no advantages.

Wouldn't it have similar advantages as 2bpp or 4bpp stuff, if not more so in terms of purely saving space sans proper lossless compression? (and in the case of the AGA chipset, the added 2 bitplanes extend much of the flexibility of the previous 6 plane system -dual 16+15 color playfields being possible for one, or other things like a 7bpp single playfield when 128 colors was fine, or other depths)

And in the context of compression: you mentioned 4-bit packed tends to be about 30% more efficient with LZ type compression than with 4-bit planar graphics, but what about using lossless compression in combination of cutting to 3 or 2 (or even 1) bitplanes when appropriate?
Or would 4bit packed stuff compress similarly to (or better than) that as well for tiles limited to similar color counts. (ie tiles with 7/8, 3/4 or even 1/2 colors -and with the MD's palette limitations, it wouldn't be too uncommon to have some fairly low-color tiles)
10-11-2010, 12:41 PM
tomaitheous

Quote:

And that's lossy compression (if you intentionally cut back to fewer colors)

Correct. And for most graphics, it probably was a cut (maybe a few tiles/sprites it wasn't).

Quote:

OH... so you wouldn't save any VDMA bandwidth or VRAM space by doing that for the SNES, PCE, NES, SMS, etc... I was thinking you could fir more graphics in VRAM that way too, and save bandwidth.

Nope. I had originally read that the SNES local to vram DMA had an option to pad the last plane (read this way back), but I've not found any dma register info that refers to this.

Quote:

Is that the same for the 8bpp modes on the SNES: tiles are stored as full 8bpp? (that would make the screen size for Doom and Dirt Trax using mode 3 considerably more odd, especially dirt trax's 216x176 window... which would use more than one full 32k VRAM bank and be impossible to double buffer -yet it doesn't tear)

Mode 7 interleaves a large tilemap with the tile data. The other 8pp direct pixel modes do not AFAIK. I'm guessing that the other modes aren't limited to 256 8bit tiles like mode 7 (you have up to 32k still for tiles, and the tilemap configuration is programmable like normal - not fixed/interleaved. Thus allowing more room for unique 8pp tiles than mode 7 allows).

Quote:

That's still only for 1 sprite layer and 1 BG layer, right? (not dual playfield like the Amiga allowed with split bitplane groups) Did it increase the sprite/line limit at all and were the palette entries any different? (ie for 2bpp mode, did it break the 256 entries into 64 palettes instead of 16?)

Yes, still same layer setup. And no, it doesn't increase the sprite bandwidth (although that could have been very possible). And no, it doesn't break the palette entry down into 64 palettes. But (it's been a while), from what I remember from testing the modes out, is that BG mode have a bitplane select bit in one of the registers. And that tells the VDC which bitplane to use. So it pads it full 4bit and IIRC that means 32 four color segments for the BG layer... well more like two sets of 16 four color segments since the bit in the register acts more like a bank switch (which limits with bitplanes are show on a single scanline, nothing finer). Sprites use the lowest bit of the starting cell number (normally ignored or set to zero) as to chose with 2bit 16x16 cell to use, but I don't remember off hand if it pads the second 2bit (all sprite cells offsets with bit #0 = 1) to 4bit on the upper side or not. If so, then that would divide the sprite palette block also into two 16 four color segments. It get's complicated ;)

An interesting note. There are two missing registers in the set of the VDC. Registers 3 and 4. They are reserved. If you mess with them during active display and under certain conditions, it messes up the tilemap reading logic of the VDC for that frame. Coincidentally, I found what appeared to be a re-read of the tilemap entry in a given 8 pixel dot clock timing chart for the VDC (the official document has a mysterious VDC read cycle in the chart) - from a demo I was writing (racing the VDC output screen while writing to tilemap data in vram). So, it looks like at one time there might have been working on setting up 2 BG layer 2bit mode. Speculation of course, but it looks might suspicious ;)

Quote:

Wouldn't it have similar advantages as 2bpp or 4bpp stuff, if not more so in terms of purely saving space sans proper lossless compression? (and in the case of the AGA chipset, the added 2 bitplanes extend much of the flexibility of the previous 6 plane system -dual 16+15 color playfields being possible for one, or other things like a 7bpp single playfield when 128 colors was fine, or other depths)

In the context of the Amiga and if it extended the existing features to more bit planes, then sure. I was thinking more about 3D stuff and engines that require pixel based plotting/rendering (not hardware accelerated BG planes).

Quote:

And in the context of compression: you mentioned 4-bit packed tends to be about 30% more efficient with LZ type compression than with 4-bit planar graphics, but what about using lossless compression in combination of cutting to 3 or 2 (or even 1) bitplanes when appropriate?
Or would 4bit packed stuff compress similarly to (or better than) that as well for tiles limited to similar color counts. (ie tiles with 7/8, 3/4 or even 1/2 colors -and with the MD's palette limitations, it wouldn't be too uncommon to have some fairly low-color tiles)

Your mileage will always vary, but I've yet to see 2bit or 1bit.. bloat under LZ variants in packed pixel mode VS planar. It's possible when it gets that low in pixel values, but I haven't seen it. I should note, that I'm using pucrunch for my compression needs - so it's a little more efficient than stock LZSS. (I haven't had a need for stock LZSS yet, 'though it is an option as it's bit faster than Pucrunch).
10-11-2010, 01:24 PM
sheath

Thanks guys for the feedback. I hope its just because I'm sick but I'm still not getting the picture. What I think I'm seeing is some kind of significant difference in ROM storage between the Genesis and the PCE/SNES. I'm not getting the full picture though.

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

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? Is this something similar to what the SNES does, or is that more normal alpha channel stuff?

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.

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.
10-11-2010, 04:56 PM
kool kitty89

Quote:

Originally Posted by tomaitheous

Mode 7 interleaves a large tilemap with the tile data. The other 8pp direct pixel modes do not AFAIK. I'm guessing that the other modes aren't limited to 256 8bit tiles like mode 7 (you have up to 32k still for tiles, and the tilemap configuration is programmable like normal - not fixed/interleaved. Thus allowing more room for unique 8pp tiles than mode 7 allows).

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)

In that context though, (pseudo)bitmap/framebuffer rendered games using full frame paired tilemap shadow on the MD (31 colors -or is it 32?- effectively 8bpp) stuff would be no more limited VRAM/DMA wise than the mode 3 Super FX games on the SNES (probably much less so due to the MD's lack of VRAM bank limits and higher DMA bandwidth -much more so in H40), though with the SNES you get a lot more color obviously, but it would still be an attractive option vs plain 15/16 color rendering and you go beyond the 9-bit RGB palette limits too.
And for 15/16 color frambuffer rendered games the Genesis would generally have the advantage save for the 9-bit RGB limit (but with only 15/16 colors 9-bit RGB is OK and for Star Fox or Vortex's polygons it probably wouldn't be a big detriment -the 2D BG stuff might be more of an issue though much of that doesn't seem very high-color either as far as SNES games go -and all the textures/scaling objects in those games are on the main pseudo framebuffer layer like BC Racers -though that even does the scrolling BG layer that way oddly enough, so no advantage of added subpalettes -opposed Yoshi's Island renders to sprite tiles for many effects)

Quote:

In the context of the Amiga and if it extended the existing features to more bit planes, then sure. I was thinking more about 3D stuff and engines that require pixel based plotting/rendering (not hardware accelerated BG planes).

Hmm, I'd also gotten the impression that even for blitters using planar graphics could be slower in that sense than a similarly engineered (with similar amount of logic/cost) coprocessor managing packed pixels. One thing that was mentioned in particular was using page mode with DRAM (obviosuly FPM or later) wouldn't be possible with planar as each write had to be a random access and not sequential (with page mode only useful for sequential accesses) so with packed pixels you could have considerably more peak bandwidth using page mode accessing. (like the Lynx did with 125 ns accesses vs over 200 ns for a full random access cycle -in the Amiga's case it's 280 ns to complete a random access but had page mode been possible it could have been 160 ns -as that's the CAS time for the DRAM used -most significant once you start eating into 68k time as you still wouldn't be able to interleave more than 1 access per 68k access otherwise; in the Lynx's case the whole design was oriented around serial accessing of the bus rather than interleaving, so that was more important -the 65C02 tied into that too though it wasn't fast enough to need page mode; the same thing with the Jaguar as it has no cache and avoiding interleaved accesses was critical for good performance using page mode -the 68k was too slow to take advantage of it though- albeit they did have provisions for 2 bank interleaving which wasn't used due to cost -double the number of RAM chips needed and more traces on the board)

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)

Quote:

Your mileage will always vary, but I've yet to see 2bit or 1bit.. bloat under LZ variants in packed pixel mode VS planar. It's possible when it gets that low in pixel values, but I haven't seen it. I should note, that I'm using pucrunch for my compression needs - so it's a little more efficient than stock LZSS. (I haven't had a need for stock LZSS yet, 'though it is an option as it's bit faster than Pucrunch).

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?
10-11-2010, 05:06 PM
TmEE

(the VGA default palette is useless and i'm quite sure no game really uses it, unless its some shitty BASIC game)
10-11-2010, 05:07 PM
tomaitheous

Quote:

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.

Quote:

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.

Quote:

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.

Quote:

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?

Quote:

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

Quote:

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).
10-11-2010, 05:31 PM
kool kitty89

Quote:

Originally Posted by sheath

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)

Quote:

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)

Quote:

Originally Posted by TmEE

(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.
10-11-2010, 10:46 PM
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)
10-12-2010, 12:27 AM
tomaitheous

Quote:

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

Quote:

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

Quote:

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

Quote:

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.

Quote:

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.
10-13-2010, 05:26 AM
kool kitty89

Quote:

Originally Posted by tomaitheous

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.
10-13-2010, 10:13 PM
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.
10-14-2010, 01:58 AM
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?
10-14-2010, 04:14 AM
tomaitheous

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

Quote:

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).
10-14-2010, 05:05 AM
TmEE

Quote:

Originally Posted by kool kitty89

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 ?
10-14-2010, 05:40 PM
kool kitty89

Quote:

Originally Posted by TmEE

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:
10-14-2010, 09:01 PM
awack

Quote:

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.

Quote:

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.
10-15-2010, 05:00 AM
kool kitty89

Quote:

Originally Posted by awack

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. :p

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)
10-15-2010, 06:30 AM
TmEE

Quote:

Originally Posted by kool kitty89

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.

Quote:

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.
10-15-2010, 11:18 PM
kool kitty89

Quote:

Originally Posted by TmEE

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)