Talk:Planar (computer graphics)

message: I don't understand the current planar data example at all. --Abdull 15:59, 27 October 2007 (UTC)
replies: text: The previous edit did not help at all! I have rewritten and I hope you will find the page clearer now. Cuddlyable3 (talk) 10:17, 2 May 2008 (UTC)
thread_title:  Example 

message: The YUV page describes a "planar format" which is quite different from the description here.  There is an apparent relationship, in that a single pixel is split across several areas of memory, but it's working in byte-planes and the planes are different sizes, rather than regularly-sized bitplanes.  It probably warrants separate discussion. --212.44.20.129 (talk) 14:26, 1 April 2009 (UTC)
replies: text: I too read the YUV planar format, and from I understand represents a single color basis, instead of encoding an entire pixel and all of its channels in consecutive bits. Since that's considered a byteplane, a bit plane would conveniently analogous with equal-sized planes? For example, 4 green/green/blue/red pixels in a 8 bits per channel RGB format stored 32 bits per pixel in this easy-to-read C code:
unsigned int [4] {
    0x00FF00, //1st pixel: Red (0), Green (255), Blue (0)
    0x00FF00, //2nd pixel: Red (0), Green (255), Blue (0)
    0x0000FF, //3rd pixel: Red (0), Green (0), Blue (255)
    0xFF0000, //4th pixel: Red (255), Green (0), Blue (0)
}
Where as a planar format, representing 8 bits per channel would spread the colors on a 32-bit bitplane instead:
unsigned int [3] {
   0x000000FF, //Red  : 1st pixel (0  ), 2nd pixel (0  ), 3rd pixel (0  ), 4th pixel (255)
   0xFFFF0000, //Green: 1st pixel (255), 2nd pixel (255), 3rd pixel (0  ), 4th pixel (0  )
   0x0000FF00, //Blue : 1st pixel (0  ), 2nd pixel (0  ), 3rd pixel (255), 4th pixel (0  )
}
If these examples are even remotely close, please create a better one!
ChazZeromus (talk) 19:11, 7 March 2013 (UTC)
thread_title:  Contrasting definition 

message: I have added a "citation needed" at the moment, because maybe I am missing something (not an Amiga/AtariST coder). But I thought Planar can be superior in some aspects for scrolling if not the same, even if doing it without a hardware chip. It has to do with the fact that you have individual bitplanes, so you can select to scroll only few of the bitplanes if your background is not using all available colors. You can even have parallax and transparent layers for free. Say for example that you have 320*200 8bit color. In a chunky display, you would have to move 64k per frame, no matter how many colors you are using. But say you are in a bitplane system and you only use 16 colors (4bits) for the background. Each bitplane is 320*200*1bpp = 8k. You can move 32k with memcopy and have a whole background moving with half the data required to move. You can have 1bit or 2bit or 3bit backgrounds, requiring nbits * 8k data to move and you can even have parallax or translucent layers by defining the palette in specific ways. Planar is powerful for that stuff. Even for simple animation with few colors (cartoonish stuff or flat polygons) planar can be much faster because you can write a single byte in one bitplane and have filled 8 single color pixels at once. That's why a lot of the Amiga demos where flat polygons, flat dancing figures animation and many scroll layers. Now, if you had to do individual pixel manipulation like texture mapping reading from a full 8bit texture bitmap, then on chunky surface you would require to read a byte from the bitmap and then write a byte to the vram, but in planar you'd have to either read 1 chunky byte from texture or 8 bits from texture stored in bitplane format, break it in individual bits and write each of the bits in it's corresponding bitplane, which is 1 read, lot's of work to break bits or 8 reads alternatively and eight individual writes, also you have to OR it with the already existing bits of the other pixels in the bitplane, a lot of work.
So, I think that statement should be exactly the opposite. And also add some information about disadvantages on individual pixel manipulation.  — Preceding unsigned comment added by Optimus6128 (talk • contribs) 13:44, 24 June 2014 (UTC)
replies: text: I've removed the cite needed. The claim doesn't say if it's "superior" or not. The claim is that it takes more memory address cycles. You can't equate superior or inferior to that. Like many thing I suspect it's a trade off, simpler X at the cost of Y. 81.108.53.238 (talk) 21:24, 30 August 2019 (UTC)

text: Related question: How can a picture element (pixel) store (1 of many colors) and quickly display onscreen? (maybe offtopic) Rico001979 (talk) 19:20, 25 May 2024 (UTC)
thread_title:  Planar mode worse for scrolling/animation? 

message: It's not obvious to me how the BBC Micro had a planar arrangement when using its RAM for pixels.  A reference should be given to back up the statement. Ralph Corderoy (talk) 11:08, 21 June 2023 (UTC)
thread_title:  BBC Micro needs further reference