A.D.A. Amiga Demoscene Archive

        Welcome guest!

  

  

  

log in with SceneID

  

Demos Amiga Demoscene Archive Forum / Coding / OS Bitmaps' connected to a custom screen only update on Amiga-M

 

Author Message
rload
Member
#1 - Posted: 15 May 2010 00:27
Reply Quote
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 :)
rload
Member
#2 - Posted: 15 May 2010 00:59
Reply Quote
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 ;)
rload
Member
#3 - Posted: 15 May 2010 01:56
Reply Quote
success! never mind
Crumb
Member
#4 - Posted: 18 May 2010 19:17
Reply Quote
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)
dalton
Member
#5 - Posted: 18 May 2010 20:09
Reply Quote
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
Kalms
Member
#6 - Posted: 19 May 2010 03:51 - Edited
Reply Quote
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.
pmc
Member
#7 - Posted: 19 May 2010 08:19
Reply Quote
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.
Kalms
Member
#8 - Posted: 19 May 2010 16:53
Reply Quote
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.
Crumb
Member
#9 - Posted: 20 May 2010 11:34
Reply Quote
@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 :-)
ZEROblue
Member
#10 - Posted: 20 May 2010 12:21
Reply Quote
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.

 

  Please log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0