Bitplane: Difference between revisions
(clarification on bitplanes front/back) |
(why did the NES use bitplanes) |
||
| Line 2: | Line 2: | ||
=== Motivation === | === Motivation === | ||
The biggest reasons the SNES uses bitplanes is probably because the NES did.<sup>[1]</sup> | |||
The SNES' planar image format allows it to easily support a bit-depth (under compression, but not [[PPU]]-native) that is not a power of two: 3bpp. In a packed format, 3bpp images would either have to: | The SNES' planar image format allows it to easily support a bit-depth (under compression, but not [[PPU]]-native) that is not a power of two: 3bpp. In a packed format, 3bpp images would either have to: | ||
| Line 16: | Line 17: | ||
* 3d animation of stacked bitplanes: https://youtu.be/nk_TbDO5QpE | * 3d animation of stacked bitplanes: https://youtu.be/nk_TbDO5QpE | ||
* https://retrocomputing.stackexchange.com/questions/7459/why-arent-each-pixels-bits-stored-sequentially-on-the-snes | * https://retrocomputing.stackexchange.com/questions/7459/why-arent-each-pixels-bits-stored-sequentially-on-the-snes | ||
=== Reference === | |||
# https://forums.nesdev.org/viewtopic.php?p=166165#p166165 | |||
[[Category:Video]] | [[Category:Video]] | ||
Revision as of 01:06, 17 December 2023
A Bitplane is a 1bpp slice of an image. The bytes making up a bitplane are not stored contiguously in VRAM.
Motivation
The biggest reasons the SNES uses bitplanes is probably because the NES did.[1]
The SNES' planar image format allows it to easily support a bit-depth (under compression, but not PPU-native) that is not a power of two: 3bpp. In a packed format, 3bpp images would either have to:
- put two pixels into each byte (total of six bits) and waste the other two bits
- put five pixels into each 16-bit word, and waste the Bit-Of-Confusion (which is what CGRAM does)
- put eight pixels into each 24-bit word, which would be awkward considering the 65c816 is a 16-bit CPU and would require more code to manipulate
Bitplanes avoid these problems because adding or removing a bitplane always adds or removes exactly eight bytes, which fits nicely into an address space.
Adjacent bitplanes in a 3D stack of bitplanes (as in, bitplanes in front or in back of each other that belong to the same tile, not adjacent in the tilemap) are always stored in opposite VRAM chips (because one chip stores the low bytes and the other high). Reading/Writing to both chips in parallel is presumably faster than trying to use one chip serially.
External Links
- 3d animation of stacked bitplanes: https://youtu.be/nk_TbDO5QpE
- https://retrocomputing.stackexchange.com/questions/7459/why-arent-each-pixels-bits-stored-sequentially-on-the-snes