Bitplane graphics advantages?
category: gfx [glöplog]
I think that as the system's CPU gets more powerful in relation to the number of pixels on the screen, from some point on, any meaningful speed advantage bitplane modes could possibly give over chunky modes, becomes insignificant. Whatever the bitplane hardware might be doing, it can be simulated on the CPU side with negligible cost.
yzi: bitplane gfx take less ram if you don't require to use all colours. You can store more gfx ready to use in gfx ram without having to move them through the gfx bus. Of course, you could use planar graphics and do a planar2chunky to show them on chunky hardware but you would require a faster gfx bus.
My point was, if the system has enough computation power per displayed screen pixel, having dedicated hardware support for bitplane modes cannot give much of an advantage over chunky modes. Which should be quite obvious anyway. How much is enough? I don't know. But AGA + 060 is a pretty nonsensical, disproportionate combination for realtime graphics output, mostly because of chip RAM slowness. At least if most capacity is used to try and squeeze out chunky mode kind of stuff onto the screen. Intuitively I would think that a category of effects should be possible, where the 060's capacity is used for something actually meaningful, without doing c2p at all. Maybe calculate the most incredibly awesome RGB color values for your copper bars... Well no, but maybe you get the idea. There should also be a size limitation to rule out animation players.
Crumb nails it I think. If there is scarcity in memory bandwidth or memory, then bitplanes can be an advantage. Otherwise it sucks!
In hardware there is always the balancing of fixed function units, programmable/general units, memory hierarchy, bandwidth/bus architecture. They all impose different limits and given the right usecase they each turn into bottlenecks. The Amiga's mix of the former is not designed for 32-bit ARGB 3D graphics, but it's units are quite good for 2D sprites /scrolling etc.
Maybe a good compo limits would simply be all effects should be more than X fps and shouldn't use more than Y of memory and Z of diskspace. But then you'd still be able to precalc an anim while watching another anim.
In hardware there is always the balancing of fixed function units, programmable/general units, memory hierarchy, bandwidth/bus architecture. They all impose different limits and given the right usecase they each turn into bottlenecks. The Amiga's mix of the former is not designed for 32-bit ARGB 3D graphics, but it's units are quite good for 2D sprites /scrolling etc.
Maybe a good compo limits would simply be all effects should be more than X fps and shouldn't use more than Y of memory and Z of diskspace. But then you'd still be able to precalc an anim while watching another anim.
Quote:
The dithered planes could also animate faster than the foreground effect possibly reducing the impact of Amiga new school 8 fps a little.
Yupp. You are Lucy has a few frames of 2bpl 50 fps animation looping on top of 16-25 fps effects in 6bpl throughout most of the demo.
The beauty of Shadebobs! (advantage!)
Errmm.. shadebobs are easier on chunky :)
But also look different via chunky (no overflow), unless you explicitly redesign em to look like bitplane-shadebobs!
what do you mean by "no overflow"?
Hardy is in beyond chunky land now! Possibly some SIMD unit with saturated adds or even a GPU with saturated outputs.
Quote:
Hardy is in beyond chunky land now! Possibly some SIMD unit with saturated adds or even a GPU with saturated outputs.
...where shadebobs still are considered beautiful...
Quote:
Intuitively I would think that a category of effects should be possible, where the 060's capacity is used for something actually meaningful, without doing c2p at all.
The c2p computation itself (without the chip memory writes) only takes about 20-25% of a 50fps frame. And if you have something sensible to do in between the writes, you are not wasting that much time all in all. This could be the effect itself, or it could be post-processing, such as blur, dithering and saturation.
Some variation of this scheme is used in most Loonies AGA productions since 1999. ;)
What's your intuition, is it possible to anything very impressive that utilizes the 060's power, but doesn't need chunky processing internally? Something that could be classified as a true AGA+060 effect.
wow, only 20-25%... old music routines eat that much on c64...
If I understood correctly, after spending the 20-25%, you still have to do the worst part, upload all the stuff into chip RAM. The important thing is to interleave the uploading instructions with something else, so it's not just useless waiting. To me this sounds like convoluted trickery, but then again I also think that's in many ways exactly what demo coding should be about. Tricks and magic.
yzi: "impressive" is a subjective term. I have almost no experience coding bitplane stuff on Amiga so I'm probably wrong but I think that if you don't use texturemapping/gouraud/pong shading you don't really need c2p. You could use bitmaps & flat/cell shading-alike and still make an impressive (at least from a design perspective) production. 060 could help to add more vertex and points and to show detailed objects and in case you need it you could rotate and/or zoom bitmaps using Blitter, without c2p.
I would be happy to see how much 2d stuff could be drawn by AGA+060... there are some 2D-like ASD demos that overlap many 2d like objects and elements and something like that could be done on Amiga. Maybe it would be harder without c2p, I don't know, but you could do like Slummy and use 6bitplanes and overlap some nice effects with the other 2 like lights, smoke... or copy one of the existing fields pointer and increase/decrease it a little to shake the screen.
BTW, for me it would be quite impressive if Doom/Iris released a demo/intro/whatever with his fpu based c2p even if it's wasn't faster than existing integer based c2ps :-)
I would be happy to see how much 2d stuff could be drawn by AGA+060... there are some 2D-like ASD demos that overlap many 2d like objects and elements and something like that could be done on Amiga. Maybe it would be harder without c2p, I don't know, but you could do like Slummy and use 6bitplanes and overlap some nice effects with the other 2 like lights, smoke... or copy one of the existing fields pointer and increase/decrease it a little to shake the screen.
BTW, for me it would be quite impressive if Doom/Iris released a demo/intro/whatever with his fpu based c2p even if it's wasn't faster than existing integer based c2ps :-)
When bitplanes are interleaved (Atari ST) and you use only half of them (2bp=4colors), i've discovered quite recently the trick of clearing two buffers with longword adressing. This suppose to have another buffer displaying.
With 24bpp you can have a bitplane lookalike effect. I saw it first in an Amiga 1200 demo.
With 24bpp you can have a bitplane lookalike effect. I saw it first in an Amiga 1200 demo.
baah: The move.l trick to clear the word (16 pixels ) on the 4th bit plane and the next word on the 1st bpl is a classic trick for dots records and co where the effect uses a single color. You can clear 32pixels spans in a single move.l
Thanks poï.
I was thinking of what Questor wrote here, better than me: Planar mode, harder or easier for scrolling?
I should have written movem.l adressing instead of longword adressing.
I was thinking of what Questor wrote here, better than me: Planar mode, harder or easier for scrolling?
I should have written movem.l adressing instead of longword adressing.
Ah! Interesting, although it might still require double buffering or precise timing ( and smaller rendering area ) to use a single buffer.
I've been thinking of using a single line of overscan to shift the bit planes every second frame so that the move.l trick to clear 32px at once works for every frame. That would allow to use a single screen buffer in low memory.
I've been thinking of using a single line of overscan to shift the bit planes every second frame so that the move.l trick to clear 32px at once works for every frame. That would allow to use a single screen buffer in low memory.
Speaking with the Amiga in mind, bitplanes are a powerful concept.
They are independent "layers" for graphics, so that for example only drawing on a foreground bitplane doesn' t modify / affect the background bitplane.
They are independent "layers" for graphics, so that for example only drawing on a foreground bitplane doesn' t modify / affect the background bitplane.
Quote:
They are independent "layers" for graphics, so that for example only drawing on a foreground bitplane doesn' t modify / affect the background bitplane.
The Plantronics ColorPlus adapter for PC also marketed this feature.
It was a CGA-compatible graphics card, but it had support for 16-colour modes, which it did by overlaying two 4-bit CGA 'bitplanes'.
One of the features they marketed was that you could display (text) overlays on your graphics screens. That was done by using the first bitplane as regular CGA, and using the second bitplane to display text or other 'HUD' graphics stuff.
4 bit bitplanes? Aehmmm if you say so :)
What a sad attempt at dual playfields that sounds like.
Quote:
4 bit bitplanes? Aehmmm if you say so :)
Two 2-bit bitplanes obviously :)