View Single Post
Old 25 October 2015, 06:51   #18
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 630
Think "Defender". (This is only about horizontal scrolling.)

That world just goes round and round horizontally. What do you do when you are at the rightmost end of it and want to scroll further to show what is on the far left side?
You can't just keep increasing the bitplane pointers as you will show the left hand side one line higher than it should be. So you build a scrolling engine to dynamically update the screen.
Nothing wrong with that. You _will_ require at least two buffers (one to look at and one to build so you can switch to it), two more if you double-buffer, and one more if you want an untouched repair buffer.

If possible you could of course just make the game world wider and paste a whole screenful of pixels at the right hand side of the bitmap so it seems like you are wrapping around to the beginning and then jump to the left again when you have scrolled so far that you see all the pasted-in pixels.
If you change parts of your world then that gets tricky as both the true and faked parts must be updated.

Scrolling the other way is ofc the same problem again so you need to apply the same solutions in reverse.

If your world has a beginning and an end (be it horizontally or vertically) it is so much simpler. You just stop scrolling when you reach an end. The number of buffers needed are just one/two/three (single/double/repair) and not so much memory.


The alternative would be to have some hw support to be able to adjust the bitplane pointers midway through a line. From what Toni Wilen (the go-to man for things really technical) has described the display logic basically does this after every fetch of bitplane data:
Have we reached DDFSTOP?
-Yes: Add modulos
-No: Add 2 (or 4 or 8 depending on FMODE)
If we could turn back the clock (hey, it is Back To The Future time after all! Oh, and Wintertime - I just turned back the clock for reals) then we could add a DDFCHNG register and two CHANGE1 and CHANGE2 registers that are basically identical to the modulo registers. You would then have the logic go
Have we reached DDFSTOP?
-Yes: Add modulos
-No: Have we reached DDFCHNG?
- - No: Add 2 (or 4 or 8 depending on FMODE)
- - Yes: Add CHANGEs

That would give you hw support to let the display show the end of the game world and then start drawing it correctly from the beginning again without any complex checks and updates. You would of course have to clip blits against the wrap, but that should be worth it and possibly something you need anyway.
The memory needed for this would be static, and you now only need one buffer for single-buffer and two/three for double/repair.

This annoyed me no end. After some Deep Thoughts and learning a bit about AGA I realized that with 4x FMODE you have 6 copper instructions between each memory fetch (if using 8 bitplanes). That is enough time to update the low 16 bits of the bitplane pointers for 6 bitplanes. If you organize the memory layout so that the upper 16 bits of a bitplane pointer will always be static then you get a clean change of bitplane display midway through the line as it is being drawn. You use the copper to do that for every line of the bitmap.
IIRC the first horizontal copper cycles available after fetch are (decimal) 27, 43, 59, 75, 91. Probably shift left once.

I have just tested it with 4 dual-playfield bitplanes (the other 4 I'm not scrolling anyway).
And as I said, this Just Works for vertical scrolling as you have all the time in the world to have the copper do a single update of all the bitplane pointers per frame.
(I was going to have it easy with the Gauntlet levels I were testing until I realized that the map was not a multiple of 64 pixels and so I have to build a full scroll engine as 528 pixels doesn't fit 4x FMODE well.)
NorthWay is offline  
Page generated in 0.04213 seconds with 11 queries