Quantcast

Page 1 of 2 12 LastLast
Results 1 to 15 of 29

Thread: For the Tech Guys: Planar vs Chunky Pixel organization

  1. #1
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    31
    Posts
    9,725
    Rep Power
    64

    Default 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)
    Last edited by kool kitty89; 11-28-2009 at 02:25 AM.
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  2. #2
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    30
    Posts
    10,095
    Rep Power
    110

    Default

    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
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

  3. #3
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    78

    Default

    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.

  4. #4
    ding-doaw Raging in the Streets tomaitheous's Avatar
    Join Date
    Sep 2007
    Location
    Sonoran Desert
    Age
    44
    Posts
    3,981
    Rep Power
    77

    Default

    Quote Originally Posted by kool kitty89 View Post
    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.

  5. #5
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    31
    Posts
    9,725
    Rep Power
    64

    Default

    I forgot to ask: does the SNES use chunky or planar organization?
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  6. #6
    Banned by Administrators dragonboy's Avatar
    Join Date
    Mar 2008
    Age
    29
    Posts
    891
    Rep Power
    0

    Default

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

  7. #7
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    31
    Posts
    9,725
    Rep Power
    64

    Default

    Quote Originally Posted by dragonboy View Post
    Snes uses planar, except for mode-7 which uses chunky.
    So the other 256 color modes are planar as well? (modes 3 and 4)
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  8. #8
    I remain nonsequitur Shining Hero sheath's Avatar
    Join Date
    Jul 2010
    Location
    Texas
    Age
    43
    Posts
    13,313
    Rep Power
    131

    Default

    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?

  9. #9
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    78

    Default

    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
    ding-doaw Raging in the Streets tomaitheous's Avatar
    Join Date
    Sep 2007
    Location
    Sonoran Desert
    Age
    44
    Posts
    3,981
    Rep Power
    77

    Default

    I'll answer best I can from my experience.



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


    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

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


    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.

    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.

    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).
    Last edited by tomaitheous; 10-11-2010 at 01:26 AM.

  11. #11
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    31
    Posts
    9,725
    Rep Power
    64

    Default

    Quote Originally Posted by tomaitheous View Post
    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)

    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 View Post
    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.

    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 View Post
    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)
    Last edited by kool kitty89; 10-11-2010 at 12:16 AM.
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  12. #12
    ding-doaw Raging in the Streets tomaitheous's Avatar
    Join Date
    Sep 2007
    Location
    Sonoran Desert
    Age
    44
    Posts
    3,981
    Rep Power
    77

    Default

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

    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.

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

    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

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


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

  13. #13
    I remain nonsequitur Shining Hero sheath's Avatar
    Join Date
    Jul 2010
    Location
    Texas
    Age
    43
    Posts
    13,313
    Rep Power
    131

    Default

    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.

  14. #14
    Hero of Algol kool kitty89's Avatar
    Join Date
    Mar 2009
    Location
    San Jose, CA
    Age
    31
    Posts
    9,725
    Rep Power
    64

    Default

    Quote Originally Posted by tomaitheous View Post
    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)

    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)


    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?
    6 days older than SEGA Genesis
    -------------
    Quote Originally Posted by evilevoix View Post
    Dude it’s the bios that marries the 16 bit and the 8 bit that makes it 24 bit. If SNK released their double speed bios revision SNK would have had the world’s first 48 bit machine, IDK how you keep ignoring this.
    Quote Originally Posted by evilevoix View Post
    the PCE, that system has no extra silicone for music, how many resources are used to make music and it has less sprites than the MD on screen at once but a larger sprite area?

  15. #15
    Mastering your Systems Shining Hero TmEE's Avatar
    Join Date
    Oct 2007
    Location
    Estonia, Rapla City
    Age
    30
    Posts
    10,095
    Rep Power
    110

    Default

    (the VGA default palette is useless and i'm quite sure no game really uses it, unless its some shitty BASIC game)
    Death To MP3, :3
    Mida sa loed ? Nagunii aru ei saa "Gnirts test is a shit" New and growing website of total jawusumness !
    If any of my images in my posts no longer work you can find them in "FileDen Dump" on my site ^

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •