Talk:Planar (computer graphics)

From Wikipedia, the free encyclopedia

Perhaps some drawn images would better show how planar graphics are stored in ram

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.

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)

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

[edit] 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)