Planar mode, harder or easier for scrolling?
category: code [glöplog]
I was just reading here
I always thought that bitplanes are great for some scrolling and animation tricks. Ok, I think I have the answer, I gave it more thought. If you want to scroll pixel perfect, you are kinda screwed, because you have to rotate the bits and do it for each bitplane separately. Or save many versions of background screens with shifted bits and copy accordingly. That's definitely more tedious than move bytes in a chunky display.
But I thought the advantage of bitplanes was that. That you can choose to only move few bitplanes if you don't use all colors for the background. So you might only have to move 8kbs per plane, while on VGA all 64k no matter what. And even set colors and have blending and parallax in separate bitplanes, move only few of them but get multilayered effect.
And animation too, most Amiga stuff are flat polygons and single color animations.
Ok, it might be more tedious to scroll, but can be faster and with several layers cheaply.
So, if these are not the advantages of bitplanes, then what is it?
Also, the Amiga has some pixel hardware function? Is it just "scroll from 0 to 7 bits" and then make byte copy with CPU inside the bitplane? Or is it more powerful?
Quote:
A disadvantage of planar graphics is that more RAM address cycles are needed for scrolling and animations, although these operations can be made faster by dedicated hardware.
I always thought that bitplanes are great for some scrolling and animation tricks. Ok, I think I have the answer, I gave it more thought. If you want to scroll pixel perfect, you are kinda screwed, because you have to rotate the bits and do it for each bitplane separately. Or save many versions of background screens with shifted bits and copy accordingly. That's definitely more tedious than move bytes in a chunky display.
But I thought the advantage of bitplanes was that. That you can choose to only move few bitplanes if you don't use all colors for the background. So you might only have to move 8kbs per plane, while on VGA all 64k no matter what. And even set colors and have blending and parallax in separate bitplanes, move only few of them but get multilayered effect.
And animation too, most Amiga stuff are flat polygons and single color animations.
Ok, it might be more tedious to scroll, but can be faster and with several layers cheaply.
So, if these are not the advantages of bitplanes, then what is it?
Also, the Amiga has some pixel hardware function? Is it just "scroll from 0 to 7 bits" and then make byte copy with CPU inside the bitplane? Or is it more powerful?
with bitplanes you can of course make parallax, but you reduce the number of available colors (with 4 bitplanes you have 16 colors, if you use one bitplane as parallax in the background you have 1 color for it and 8 colors for the rest). and you can fake transparence (look at the first union-cracktros on the atari-st)
whats also easy: sort of fading-out-effects, you redraw 1 plane and make the other planes darker, only by setting new colors.
what is useful (and what is used in some 3d-routs on the atari) that you draw 3-colored objects in the first 2 planes in one frame, do another frame in the other 2 bitplanes and afterward do an movem-style clear of the whole screen, hence you have 1 clear pass each 2 frames and not for every frame.
regarding scrolling on the ste: you have a video start address (which you can set in 16 pixel steps), a finescroll register (scrolling 0-15) and a line-offset to each line (making a bigger virtual screen possible).
whats also easy: sort of fading-out-effects, you redraw 1 plane and make the other planes darker, only by setting new colors.
what is useful (and what is used in some 3d-routs on the atari) that you draw 3-colored objects in the first 2 planes in one frame, do another frame in the other 2 bitplanes and afterward do an movem-style clear of the whole screen, hence you have 1 clear pass each 2 frames and not for every frame.
regarding scrolling on the ste: you have a video start address (which you can set in 16 pixel steps), a finescroll register (scrolling 0-15) and a line-offset to each line (making a bigger virtual screen possible).
Well, I guess biggest advantage of planes are rather saving memory when, for example, an effect is using only 2 colors which gives the opportunity of just using 1 bitplane (and thats 10kb instead of 64kb).
Rather a disadvantage is the effort to convert colorful effects from chunky to planes... would be great to have the option to switch between plane and chunky mode on Amiga.. :)
Rather a disadvantage is the effort to convert colorful effects from chunky to planes... would be great to have the option to switch between plane and chunky mode on Amiga.. :)
They mention 'address cycles'... which is true in a way: you need to address different areas of memory to read/write a pixel, rather than just one word.
But the whole point of using bitplanes is exactly that: In the early days, memory access was slow. So by using different bitplanes in parallel you could have faster memory access, which meant higher resolutions and/or more colour. This is memory access as seen from the RAMDAC.
The CPU could not access memory in parallel, so for the CPU it would be a disadvantage. But that's why we have custom blitter chips, sprite overlays etc.
On Amiga you copy memory with the blitter of course. Scroll offsets are 0-15, because it's a 16-bit machine.
Although for simple scrolling you don't even need to move memory: For vertical scrolling you can just update the bitplane pointers every frame.
For horizontal scrolling, you can make the bitplanes a lot wider than your screen. So by using scroll offset and updating bitplane pointers, you can scroll your display window over the larger framebuffer.
But the whole point of using bitplanes is exactly that: In the early days, memory access was slow. So by using different bitplanes in parallel you could have faster memory access, which meant higher resolutions and/or more colour. This is memory access as seen from the RAMDAC.
The CPU could not access memory in parallel, so for the CPU it would be a disadvantage. But that's why we have custom blitter chips, sprite overlays etc.
On Amiga you copy memory with the blitter of course. Scroll offsets are 0-15, because it's a 16-bit machine.
Although for simple scrolling you don't even need to move memory: For vertical scrolling you can just update the bitplane pointers every frame.
For horizontal scrolling, you can make the bitplanes a lot wider than your screen. So by using scroll offset and updating bitplane pointers, you can scroll your display window over the larger framebuffer.
The trick of scrolling bitplanes independently was used in some PC Engine games to fake parallax (sadly I don't have any videos handy right now).
The biggest advantage of bitplanes is in hardware: it's much easier to do arbitrary color depths since you don't have to align pixels to specific memory boundaries. The downside is that it makes drawing routines more complex (and slower) =P
On the VGA, in mode X you can turn on all bitplanes to clear the screen quickly (you'd be drawing four times as fast). This isn't all that useful though outside that since you're drawing four consecutive pixels at the same time.
The biggest advantage of bitplanes is in hardware: it's much easier to do arbitrary color depths since you don't have to align pixels to specific memory boundaries. The downside is that it makes drawing routines more complex (and slower) =P
On the VGA, in mode X you can turn on all bitplanes to clear the screen quickly (you'd be drawing four times as fast). This isn't all that useful though outside that since you're drawing four consecutive pixels at the same time.
Quote:
This isn't all that useful though outside that since you're drawing four consecutive pixels at the same time.
Flatshaded polys obviously :)
Aside from that, a big advantage of mode X is that you can access all 256K of memory, allowing you to have larger framebuffers (which you can use with a 'scroll window' similar to what I described above for Amiga) and/or backbuffers in videomemory, allowing for fast page flipping when double-buffering.
I never understood why Chain-4 can't access 256k, since it's on 64k area and there are others left free. I recently read that it's a planar mode in disguise but I don't know exactly how, but still we only write to 64k area, so why isn't it possible to page flip to other 192k? Can someone explain?
Quote:
what is useful (and what is used in some 3d-routs on the atari) that you draw 3-colored objects in the first 2 planes in one frame, do another frame in the other 2 bitplanes and afterward do an movem-style clear of the whole screen, hence you have 1 clear pass each 2 frames and not for every frame.
Bang! Didn't knew this trick! *** blush ***
So simple, yet gaining so much time, thank you Questor!
Quote:
I never understood why Chain-4 can't access 256k, since it's on 64k area and there are others left free. I recently read that it's a planar mode in disguise but I don't know exactly how, but still we only write to 64k area, so why isn't it possible to page flip to other 192k? Can someone explain?
The memory is probably 'scattered', to get the access speed up (see above, about RAMDAC accessing multiple planes in parallel).
So it may actually be using the whole 256KB for the framebuffer, but in a sparse way, with unused memory in between.
In chunky paletted modes you can rotate the drawing colors of the object each frame and only need to clear 1/(256/3) of the screen for a 3-color piece :)
Quote:
Flatshaded polys obviously :)
You get screwed at the borders though :P
Regarding Chain-4: yeah, the pixels are scattered over the full 256KB. All four bitplanes are used: the bottom two bits of the address are used to select the bitplane. Supposedly this made the hardware design easier, but honestly I can't see how, especially since the CGA 2bpp modes are already mostly linear (lines are interleaved, but aside from that each byte contains four pixels in packed format).
Disabling Chain-4 (a requirement for mode X) effectively makes the addressing mode linear again. However, 8bpp output is hardwired for the memory layout used in Chain-4, which leads to pixels being scattered over all four pages.
I wonder if it has something to do with CPU addresses being 16-bit, when to address 256KB you need 18-bit? That'd be stupid though, bank switching would have been a much better option.
Quote:
You get screwed at the borders though :P
Not really. You can just set up a table to work out how many pixels at the borders. Then it's just a case of enabling the right planes and plotting 1 byte.
More details here.
Quote:
I wonder if it has something to do with CPU addresses being 16-bit, when to address 256KB you need 18-bit? That'd be stupid though, bank switching would have been a much better option.
Yes, I doubt that. They could either have mem-mapped more than one segment of videomemory, or allow some kind of paging scheme, so you can select which part of memory is visible.
But well, the only 'paging' scheme is the unchained mode... which is the same as EGA (4 bitplanes), except the bits are interpreted in a different way.
Quote:
In chunky paletted modes you can rotate the drawing colors of the object each frame and only need to clear 1/(256/3) of the screen for a 3-color piece :)
I was thinking about this trick, and I think it's something that the VGA has the advantage. What I was thinking is for dot effects for example, every frame you plot dots with color n (starting from 1), set color n(visible) to white and color n-1 to black(background), this way you don't have to erase previous dots till you reach 255 (or even better you can switch to next page after each 255 loop in Mode X or other mode that supports it and have 4*255 frames where you don't need to erase (at 70hz is around 14 seconds of effect, more than enough to effectively hide and then clear all and jump to the next part)).
My thought was that since you reach 255 for example, looping back to 1 would have problems because of old garbage not erased, just hidden with palette. But then I thought something similar to your trick. If during each frame you slowly erase 1/255 of the screen? But my problem is this, I continue plotting the n color and leaving the n-1 garbage hidden with palette, and the small fraction of lines erasing might not catch it. Don't know if this will work perfectly. You erase parts of the screen from up to down, but at later frame I might draw dots in the upper side, while the eraser is erasing the lower side. Or maybe it depends at which part of the screen your object is? Not sure if I explain correctly but this bugs me but maybe with some tries I might see that it works.