Horizontal vs vertical scrolling

[Amiga1992]

I was wondering what it's "easier" to do for the Amiga, a horizontal or a vertical smooth scrolling? What would consume the least computer power? Which one would be easier to code?
Let's assume I have 2 or 3 layers of parallax, too.

[NorthWay]

Vertical.

Does not eat sprite cycles.
You can wrap the screen leisurely at the end of any line you want.
If you restrict your parallax to full bitplanes then you don't have to worry about having to blit them around to shift differently from the other bitplanes. (I think Banshee used 1 or 2 bitplanes for some weather effects.)

[Amiga1992]

Thanks for that info. For some reason I thought the AMiga was wired for doing super easy horizontal scrolling!

[ReadOnlyCat]

Originally Posted by NorthWay

Vertical.

Does not eat sprite cycles.
You can wrap the screen leisurely at the end of any line you want.
If you restrict your parallax to full bitplanes then you don't have to worry about having to blit them around to shift differently from the other bitplanes. (I think Banshee used 1 or 2 bitplanes for some weather effects.)

You can simply push the screen 12 pixels to the right to avoid losing one sprite and many games did just that.
Being able to display the same landscape several times on the same screen is nice but this is so rarely needed or used that this is not a practical advantage, just a theoretical one.

If you limit yourself to the lowest common set of features, then the cost is the same.
If you consider parallax a necessity then horizontal wins hands down. It makes it a bit harder to compute the copperlist and blits but much less so than for vertical.

Originally Posted by Akira

Thanks for that info. For some reason I thought the AMiga was wired for doing super easy horizontal scrolling!

Both directions come with their set of advantages and issues.

Parallax is easy for horizontal, quite hard for vertical.
Wrapping is easy for vertical, quite hard for horizontal.

Choose your way, choose your pain.

[Codetapper]

Originally Posted by Akira

I was wondering what it's "easier" to do for the Amiga, a horizontal or a vertical smooth scrolling? What would consume the least computer power? Which one would be easier to code?
Let's assume I have 2 or 3 layers of parallax, too.

I would say horizontal is easier. If your map is say 20 screens wide, all you need to do is interleaved bitplanes and an extra 20 x 40 bytes = 800 bytes additional to scroll the entire map.

Vertical scrolling means you often need double the height of the screen or have to use a split, which then complicates drawing objects onto it because they have to be drawn in pieces.

[ReadOnlyCat]

Originally Posted by Codetapper

I would say horizontal is easier. If your map is say 20 screens wide, all you need to do is interleaved bitplanes and an extra 20 x 40 bytes = 800 bytes additional to scroll the entire map.

Vertical scrolling means you often need double the height of the screen or have to use a split, which then complicates drawing objects onto it because they have to be drawn in pieces.

Ohhhh, this is so neat.

I never gave a deep thought to pure horizontal scrolling because for some reason I am more interested in 8 ways but just having to point the "exhausted" pointer to the top of the memory after one full screen scrolled is indeed really simple and cheap. Thanks for enlightening this kitten too!

[Amiga1992]

I actually am interested in making something that would scroll horizontally so this is good to hear.
Thanks, guys!
I need to learn so much more though.

[ReadOnlyCat]

Originally Posted by Akira

I actually am interested in making something that would scroll horizontally so this is good to hear.
Thanks, guys!
I need to learn so much more though.

An added advantage of CodeTapper's method is that interleaved bitplanes can also simplify blits: you can blit all bitplanes in a single operation when adding new tiles. For cookie cuts you need masks n times bigger if you want to do a single operation though but you could simply opt for a two times bigger mask and blit two planes at once depending on memory pressure at that particular moment (*). For small blits this is interesting since their setup time overhead is relatively higher.

Also I realize now that I completely miscalculated the bitplane pointer update for his technique: there is no need to reset any "exhausted" pointer at all because there is no "exhaustion": only 800 additional bytes are needed for the last bitplane while the others simply recycle existing bytes. Silly kitty.

This said, if you wanted to scroll say 400 screens, then instead of allocating 400x40 bytes you could simply allocate one additional bitplane (256x40) and do the reset of the exhausted pointer I suggested. This will require reordering bob data in memory though but only if you want to keep factorizing blits.

(*) note that blitting several planes requires that the planes to blit are separated by the same number (can be zero) of non blit planes (quite hard to picture I must admit) which can require an even number of planes. A bonus of the additional bitplane allocation suggested in the third paragraph is that it can transform an odd number of bitplanes into an even one and thus allow more viable combinations of bitplanes to blit.

[Codetapper]

400 screens x 40 bytes is still only 16kb. It may well be worth losing that memory for the simplification you get using this method.

[8bitbubsy]

Originally Posted by ReadOnlyCat

Thanks for enlightening this kitten too!

Yeah we get it! You're probably one of those furries. In a lot of your posts, you mention things like "you humans" and other indications, is it really necessary? It's just absurdly weird to read things like that in rather serious posts about Amigas... It would be more understandable if it was in a furry community or something.

[Leffmann]

So what... you're just a bit young and intolerant to people who you perceive as different. It'll get better eventually

[ReadOnlyCat]

Originally Posted by 8bitbubsy

Yeah we get it! You're probably one of those furries. In a lot of your posts, you mention things like "you humans" and other indications, is it really necessary? It's just absurdly weird to read things like that in rather serious posts about Amigas... It would be more understandable if it was in a furry community or something.

Reading too much into things is a sure recipe for confusion don't you think?

Also your picture is offensive, makes me hungry and is absurdly weird in a rather serious community about the Amiga.
(I am joking, I find it really fun and cute.)

But hey, back to scrolling!

[8bitbubsy]

Why do I even argue with a cat, I should've known. But yeah, back on-topic. :P
EDIT: I'm sorry, I just realized how unnecessary it was of me to pick on you in the first place. Leffmann is right...

[Amiga1992]

Originally Posted by 8bitbubsy

Yeah we get it! You're probably one of those furries. In a lot of your posts, you mention things like "you humans" and other indications, is it really necessary? It's just absurdly weird to read things like that in rather serious posts about Amigas... It would be more understandable if it was in a furry community or something.

Jesus, tolerance people, tolerance please!
Let's get back to topic

[NorthWay]

/topic
Unfortunately the Amiga can't wrap the display address halfway through a line; looking at how the hw is implemented that would have been a no-brainer if they had thought of it or deemed it interesting.

With AGA you can play games with re-setting the (low 16-bit) address pointers when you use 4x FMODE as you get more time between fetches to make it wrap midline. I'm toying with that for a Gauntlet thing I put time into at random intervals.
(I do have my logic off by one line for some reason I can't wrap my head around though, but the effect of seeing your bitmap starting from the beginning again when you get midway through the screen is so cool. IMO!)

[Amiga1992]

What is this effect you describe? Can you illustrate with an example?

[ReadOnlyCat]

Northway is referring to the update of bitplane pointers in the middle of a scan line as discussed in this thread: http://eab.abime.net/showthread.php?t=79776.

On AGA it is possible to update all bitplane pointers with the copper between subsequent bitplane DMA fetches when in 4x mode, so if one resets the pointers to the value they had at the beginning of the line then the rest of the line displays the beginning again, thus wrapping horizontally.

On ECS, this is doable but with two bitplanes only. Above that, updating the bitplane pointers will not happen fast enough before the data is fetched again and there will be some graphical glitches.

It is a pretty cool technique and that thread is definitely worth a read for whoever likes Amiga hardware details.

[NorthWay]

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.)

[Toni Wilen]

Originally Posted by ReadOnlyCat

On ECS, this is doable but with two bitplanes only. Above that, updating the bitplane pointers will not happen fast enough before the data is fetched again and there will be some graphical glitches.

3 planes should be possible, for example:

---2-3-1 ---2-3-1
--C-2-C- 3-C-1---

First line is bitplane DMA sequence, second is copper (C=copper instruction read, number = copper bitplane pointer write).

Unfortunately it looks like 4 planes is possible by using similar interleaving but you'll hit hardware limit: write to any DMA pointer 1 cycle before same DMA pointer is used for DMA access: write does nothing..

[ReadOnlyCat]

Originally Posted by Toni Wilen

3 planes should be possible, for example:

---2-3-1 ---2-3-1
--C-2-C- 3-C-1---

First line is bitplane DMA sequence, second is copper (C=copper instruction read, number = copper bitplane pointer write).

Damn, indeed. I should have known because when I worked out this sequence (on paper) for 5 bitplanes I took advantage of the fact that certain orderings produce less visual side effects because they occur at the right moment.

Originally Posted by Toni Wilen

Unfortunately it looks like 4 planes is possible by using similar interleaving but you'll hit hardware limit: write to any DMA pointer 1 cycle before same DMA pointer is used for DMA access: write does nothing..

Argh. This means I have to go over sequences I came up with.
Does the write really do nothing or is the written value only available after the DMA fetch?

If that's the latter then there is still hope.