Talk:Planar (computer graphics)

Images

Perhaps some drawn images would better show how planar graphics are stored in ram 134.173.56.219 (talk) at 17:10, 26 September 2004

Explain better

Can someone explain why planar images are easier to scroll in hardware? It's not obvious to me. Mr2001 12:50, 16 July 2005 (UTC)

Agreed, outside of being more space efficient in most cases of the time, therefore requiring less data moving, it doesn't seem to make sense. In fact having eight pixels partially represented in one byte would make horizontal scrolling somewhat nightmarish in software. In hardware the Amiga had support for scrolling, which outside for what I imagine to be a complexity boost in hardware support for that, has no appreciable effect on ease of pointer-adjusting-based scrolling versus chunky representations.

05:26, 24 October 2005 64.81.58.56 (talk)

Being a former Amiga programmer myself (although not a very good one), the only reason I can see why planar is better than chunky is that it allows for any number of colours that is a power of 2: 2, 4, 8, 16, 32, 64, 128, 256, etc., not just 256 or 65536. In the days of the Amiga and the Atari ST this was very important, as the colour of a pixel was usually only an index to a palette which included RGB information, and did not contain the RGB information in itself. Currently the vast amounts of computer memory available seem to have made this concern obsolete. JIP | Talk 22:15, 23 January 2006 (UTC)

I imagine that planar images are easier to scroll because you can simply apply a rotate operation on the screen data, and that will scroll the screen by x pixels horizontally. I believe that this operation is free using the Amiga's clever chipset. The Mekon 03:00, 29 January 2006 (UTC)

Um, could not hardware do the same for chunky data? Loris 20:55, 9 January 2007 (UTC)

Disingenious

"This wastes RAM in cases where fewer bits are needed than are provided. If you only need to display 8 colours, you can use 3 bitplanes, and each pixel only has 3 bits assigned to it instead of 8 (reducing memory and bandwidth requirements by 62.5%)."

This seems a bit disingenious, since a chunky format could use a nibble rather than a byte per pixel. Using bitplanes would save 25% against this more likely case. Loris 20:55, 9 January 2007 (UTC)

Good questions. Bear in mind that the first bitmapped graphics would have been monochrome, 1 bit/pixel, with graphics memory written directly by applications to a defined memory-mapped address space. Planar graphics would have allowed old software to work unmodified for the same resolution as new bit planes were added in later hardware. This backward compatibility would have been possible with palette-based chunky data only if bits were reserved in each chunk for future expansion, which was wasteful of memory and not done. Even a 25% memory saving was substantial in the 1980's when RAM was expensive and limited. Secondly, as graphics memory requirements increased, the original allocated address space for memory-mapped graphics would have become inadequate. You may recall this happened with MS-DOS. By using bank-switching with planar data, you could access an entire bit plane at once through a limited address space. Although you could use bank-switching to access various portions of a chunky screen too, this could require multiple bank switches when copying data between different parts of the screen. Thirdly, depending on the specific colour change, you may not need access to all bit planes, thus speeding up memory access compared with chunky data. This scenario used to happen more often than now, since with only 4,8 or 16 colours, you are talking business software & primitive games rather than photorealism & texture mapping.

To the specific question of why not use sub-byte chunks, remember that standard processor command modes typically support 1-bit, 8-bit, 16-bit, 32-bit and/or 64-bit memory accesses and operations. They are not optimised for sub-byte chunks such as nybbles, which would require additional software overhead. As for scrolling, planar has no advantages for pointer-adjustment scrolling. But this type of scrolling wasn't always available, and when it was, it scrolled the whole screen not just a portion. Planar has advantages for the horizontal component (only) of hardware scrolling because it lets you use the fast shift/rotate standard processor commands to scroll multiple pixels for each read/write access. Yes, you could have hardware scrolling support for chunky data, but it wouldn't reduce the number of memory accesses per scrolled pixel, which is where the bottleneck lies.210.84.60.22 10:37, 3 February 2007 (UTC)

What about 8k tv's? --Size vs. Speed. Maybe explain Digital vs Mechanical camera. Would a TV specialist know? Rico001979 (talk) 19:16, 25 May 2024 (UTC)

Example

I don't understand the current planar data example at all. --Abdull 15:59, 27 October 2007 (UTC)

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)

Contrasting definition

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)

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)

Planar mode worse for scrolling/animation?

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)

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)

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)

BBC Micro needs further reference

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)