pouët.net

I've been discussing with ZX guys about advantages and disadvantages of bitplane based graphics. Not speaking about Amiga, but in general. The V6Z80P computer offers something like it. What is the pro of this style of graphics data storing and manipulating? What scene effects can be done better with bitplanes on these systems?

Transparency effects like glenzvectors and interference-effects are easier to do with bitplanes compared to chunky modes.

Hardwarely speaking, it limits the memory footprint & bandwith to what is strictly necessary. Take the Amiga, for example... oh, wait.

* Cheap "motion blur" by drawing each frame onto the next bitplane.

* If your effect uses half or less of the bitplanes, you can use them for your double buffering thus saving memory ( also that might allow you to use a faster/shorter addressing mode if your screen is low in memory )

Generating a Mask over an CPU-Generated effect that does not abide addressing or byte-exact conventions, which is generally costly and reduces overall color depth. But then, you don't need to mask out a Circle by Hand.

The mask idea can be used to add some color/shades to the effect going on in the other bitplanes.

On the ZX the real disadvantage of bitplanes would be the amount of memory required.. and the added CPU manipulation required to drive that extra memory. The Speccy essentially has a single bitplane screen (256*192=49152bits=6144bytes) with a clever colour "overlay" (32*24=768bytes) that lets you display 16 colours (ignoring flash) with just 6.75k. To show that many colours with bitplanes you'd need 5 of them... that's 30k of display data! Sure, you get per-pixel colour and some cheap tricks, but the Speccy wouldn't have enough CPU power to drive it.

Forget biplanes though... what I always wanted on the ZX was a Blitter!

For 16 colors? I don't think so ;)

Maths fail! Yes! 4 bitplanes, not 5 :D

And 24k of memory needed, not 30k

With bitplane modes you can do Chunky To Planar effects!!! Which the coolest thing ever, if you ask Amiga sceners. ;)

What exactly is a "chunky to planar effect"?

noise under picture by your left foot :)

Crossfading between effects running on single or multiple bitmaps, XOR filling and logical operations in general, plus platform-specific tricks like clearing multiple bitplanes with one write (EGA/VGA).

I would consider speccy vram bitplaned, the Mode 2 of CPC would be bitplaned, it just happens to have 2 colors to look like a single bitplane.

the-then. And if it was bitplaned then mode 1 or 0 would be like separate bitplanes, but no, it's just one byte holding bits of four or two pixels.

Arghh, I wouldn't

I wouldn't consider speccy vram bitplaned, then Mode 2 of CPC would be bitplaned, it just happens to have 2 colors to look like a single bitplane.

xor filling works on chunky gfx aswell, most c64 'filled' 3d is made of 2 bits/wide pixel monoplane mode.

anyway in general I think bitplanes are terrible, even for a starfield, many bytes to change instead of one, when setting a pixel. Amiga would have been better with 4/8 bit modes fex. imho. or atleast c2p HW on AGA. in 4/8 bit modes one could set many pixels in one mov, instead of many mov / pixel,.

glenz, transparency, 'motion blur' stuff was nice, but not in the long run, and I see ne benefit of bitplanes in real world GUI / Game context. Horrible bitplane tearing coz of slow aga even on 060 machines when scrolling a webpage. urgh.

The main advantage of bitplanes is it makes it easy to get several colour depths with the same addressing. 1 bitplane for 2 colors, 2 bitplanes for 4 colors, 3 bitplanes for 8 colors, etc. One pixel on the screen is always mapped to the same bit-offset in each bitplane.

This means you have to write your pixel plotter or text driver once for all video modes. In chunky systems, you have to write one routine for each video mode. This is a problem for example on the Thomson machines, where not all video modes can be used to print text from the BASIC because they were too lazy to write all the code to handle text output in all modes (or maybe they lacked ROM space to do so).

On the hardware side, implementing bitplane modes is a bit more complicated, because you have to fetch data from several places in RAM before you can display even a single pixel. In chunky modes you fetch just one byte and you can display 1, 2, 4 or 8 pixels (depending on the colordepth). Then you only need to fetch the next byte and start over. But, the bitplane way is more scalable: you can keep adding bitplanes until you run out of memory bandwidth without major changes to the pixel outputting system. So it is easy to have 2,4,8,16,32,64,128,256,512, etc color modes. In chunky hardware you only get 2,4,8,16,256,65536,etc, and for each mode implemented the pixel shifting hardware will be quite different and so will be the timing (either you change the display resolution to match your memory access rate like the CPC does, or you change the speed of RAM accesses).

iirc. saw some plasmas in bitplane mode(s) back in the days. sine distortion on each plane. if it looks good or not is another story.

A very simple technique which I think enrich the visuals a lot is to just layer a random dithered animated hue gradient in 3 bitplanes and then do effects in 5 planes of luminance on top of this. The dithering is free and reduce the banding in the foreground effect. The dithered planes could also animate faster than the foreground effect possibly reducing the impact of Amiga new school 8 fps a little. And the c2p becomes marginally faster because 3 less planes to write. And you don't have to use shade tables for all your effects.

See "Software Make the Dance Foam Oil" by my group or "Norwegian Kindness" by Spaceballs for an example.

It is very important to remember that you must care about how your color palette is organized.

You can only achieve the kind of effects that loaderror points out in his post (while avoiding the horrible things that rudi warns you about) if you think about palettes and how to take advantage of the fact that each bitplane (or some bitplane group) can define some information about some particular aspect of the color of all pixels.

One way to think about it is that planes+palette let you define any binary combination of bits like a truth table. First two planes anded together, the next orred and the fourth xors everything, no problem.

I have been wondering, is there anything cool you can do with bitmap graphics modes if you have a rediculous amount of CPU power like in an Amiga 68060 turbo card. Something where you don't do everything in chunky pixel and try to c2p the life out of the bitplane graphics.

In Amiga I guess that CPU power won't help very much because bitplanes reside in Chip RAM which is hogged by the chipset. Unless you render in Fast RAM and copy the bitplanes to Chip, which in turn is like trying to p2p the life out of it (expensive).

There's a cool hack for Amiga called "fscreen" which basically does what I described above. Along with "fblit" it moves screenspace to Fast RAM and patches many of the graphics.library functions so they are performed by the CPU in Fast RAM instead of Chip RAM and the Blitter. There's a huge rendering speedup on fast CPUs, but the copy-to-chip part, even though assisted by the MMU (only changed parts of the screenspace are copied) spoils much of the fun.