A.D.A. Amiga Demoscene Archive

I use ChangeVPBitmap to alternate between two OS bitmaps which contain 8 bitplane pointers each. These two bitmaps are simply used to implement double buffering.

... msgport based check to see if it is time to swap buffers ...
currBitmap = bitmap1 or bitmap2 depending on frame
ChangeVPBitmap( viewPort, currBitmap, doublebufferinfo )

Now if I manipulate the bitmap1 and 2's bitplane pointers each frame. I would expect the changes to be reflected on screen as I call ChangeVPBitmap.. However, the changes only happen if I do Amiga-M two times (swapping the demo screen out and back in again)..

Has anyone tried this using the OS before? What might be missing? I spent half of the outline party scratching my head over this. I have no hair left.

Thanks :)

It seems to work better if I change the bitmap after the "safe to change" message thingy has been received and not just change it somewhere in my code ;)

success! never mind

nice to see you fixed it!

Is ChangeVPBitmap() better/faster than intuition's ChangeScreenBuffer()?

Since you are around I'll take advantage of your copper master knowledge: may you please let me know if copper is fast enough to change display start address each 1-2 pixels? would I have to change bitplanes addresses in the bitplane registers? it's in the thread "coding tutorial: the copper" and the idea would be ultrafast table effects, a long copperlist with the offsets but I guess it's not possible (or would only be possible with just one bitplane and each too many pixels)

My guess is that bitplane data is fetched as words, so the amiga will only read the pointers every 16th pixel, no matter how fast you can write to them, unfortunately

Regarding "ultrafast table effects by having copper change bitplane pointers"

1. A copper MOVE instruction takes 8 LORES pixels to execute
2. You will need to do one or two copper MOVEs to change a bitplane pointer (one if you are only going to change the low-word of the bitplane pointer, two if you are also going to change the high-word)
3. If you need to change both the low-word and the high-word then the change will not be simultaneous; thus you will (for a period of 8 pixels) potentially have crap from somewhere else showing
4. If you want to change multiple bitplane pointers, you cannot change them simultaneously; again, the result will be crap during the period of time that you had changed some (but not all) bitplane pointers
5. If you run with >4bpl active, sometimes bitplane DMA steals memory slots from copper and then the 8 LORES pixels time will increase

To sum it up, using the copper to mangle the bitplane pointers during the visible display is not very useful.

It's useful for making at least one nice old skool demo effect. :-)

The sinewaving eagle picture from Phenomena's Flight Of Dreams II demo is done by changing bitplane pointers with the copper.

http://www.pouet.net/prod.php?which=9392

I have seen this same effect done in other demos but, in my opinion, it looks nicest in FODII.

Sure, but then you're changing the bitplane pointers only once per scanline, and outside of the visible display (during the border cycles).

That gives you enough time to change them all without strange glitches.

@Kalms&dalton

I asked because I read that on Brian the Lion they used copper to create the tunnel-like background effect but now I guess they used a lot of lines with different "zoom factor" to create the ilusion of bitmap deformation. Thanks for the reply :-)

There's also what you call the "$102 trick", where you change the horizontal scroll value repeatedly across the scanline to effectively stretch and/or shrink the line, but it takes a lot more time to get working and doesn't look as good as precomputed graphics. Never got it working myself.