calimero wrote:but Amiga have Copper processor for palette switching and on ST you would need sync coding for changing palette on fly!?
Depends what you want to do, though I think we understand different things by 'on the fly'.
First off, the ST has a raster-based interrupt that can be programmed to occur after a variable number of lines of the screen, and can be used to change palette settings. It's obviously not as versatile as a Copper list, and the main processor has to wait while the interrupt routine runs, but you can do semi-clever stuff like changing the background colour every 8 pixel rows for a pretty sky, then check one of the unused bits in the colour you've just copied, and if it's set, do a more significant palette swap on that particular row. That way it's sort of programmable. At least, that's from assembly. Not sure what STOS extensions there are to implement it.
What I really meant by 'on the fly' is if there are four colours that aren't going to appear on the background or foreground (or arise from a background colour in one bitplane merging with a foreground colour on another bitplane) then you're free to set them to whatever you need for sprites, and if you reserve a few just for enemy sprites, then you can re-allocate them depending on which enemy is about to appear.
Leander does this a lot, and just occasionally glitches as you see an enemy change colour just as it leaves the screen and a different object scrolls into view. I didn't necessarily mean change them for different rows of the screen.
The ST has one advantage over the Amiga though - you can end up with any colour as your background - it doesn't have to be 0. So you don't have to mess around trying to stop your colour bars extending into the border like a lot of Copper lists have to.
calimero wrote:beside planes on ST are interleave so I do not see how you can speed up graphics using only e.g. 2 instead of 4 bitplanes?
The bitplanes are still held in separate 16-bit words, though the words are then interleaved. Let's say you have a background and a foreground screen to copy from, each with two bitplanes. You copy two words from the foregrround source, then two words from the background source, then two more from the foreground, and two more from the background. Put together, they give you one 4-bitplane screen sourced from two 2-bitplane screens.
You simply change the address you start to copy from to shift either layer left or right by 16 pixels. If you're clever, you have a bit of self-modifying code in your line-copy routine to make it wrap-around at just the right moment. And for a finer scroll, you need to store the layers pre-shifted in 1,2, 4 or 8 pixel steps.
That's if you're using a buffered scroll. If you're re-drawing the entire screen from tiles then you need a different approach. But you can still just write to every fourth word to address one bitplane.
If you don't use bitplanes, then you have to mask off and merge everything that might pass in front of anything else. You end up treating the whole foreground scenic layer as one huge software sprite, which has to be AND-ed and then OR-ed into the four bitplanes. That slows your game down. But at least you can use all 16 colours.
