6

Back in my early Amiga days (A500), I remember coding simple demos that would use the dual-playfield mode and scroll them around (at a sweet 60FPS). It was pretty trivial to do with languages like Blitz Basic and AMOS. My knowledge back then was pretty limited as to what the Amiga could really do.

Later on in life, I learn that games like Agony used tricks like putting a static 1-bit bit plane and simply altering the background color of that bit plane with a copper list. Then, it would use the dual-playfield as normal with the exception that the background would now only have 2 planes instead of 3. This effect gives the illusion of three layers of scrolling with little CPU overhead.

This is amazing!

So my question is, how were the individual bit planes controlled like that? I originally thought that the grouped planes had to "stick together" when they move around. But I was wrong.

Thanks.

cbmeeks
  • 8,531
  • 3
  • 25
  • 97
  • 3
    No doubt someone will give you a detailed answer, but if you want to do some reading, I would recommend checking out the Amiga System Programmer's Guide by Abacus, section 1.5.5 does a detailed dive into playfields, scrolling, copper lists, etc. I used this book back in the day as my go-to resource for puzzling this stuff out. https://archive.org/details/Amiga_System_Programmers_Guide_1988_Abacus – Geo... Jul 20 '18 at 15:50
  • https://www.facebook.com/koney.industrial/videos/amiga-blitter-tests-scrolling-4-separate-bitplanes/1318398995175124/ Don't know if it helps ??? I weird try I would say ;-) – sodapop Jul 16 '23 at 11:50

2 Answers2

9

Individual bitplanes can only be scrolled by 16 pixels at a time, because the bitplane start address is word aligned. To scroll less than 16 pixels, the scroll register must be used, but it applies to all bitplanes on a playfield equally. The maximum number of playfields is two in dual playfield mode.

Agony uses a different technique. First, it uses dual playfield so that there are three playfields for the front scrolling layer and three for the back layer. That gives you two layers of parallax.

Then it splits the back playfield into two layers, using a trick that keeps one of the three bitplanes stationary while scrolling the other two with the scroll reigster. To stop the stationary layer from moving due to the scroll register, the blitter is used to shift it back in the opposite direction. This results in around 4k/frame of data copying, which is not too bad. To understand how this works, you need to understand bitplanes and how a kind of fake parallax can be created with duplicate colours.

A fourth layer of parallax is added with the rain effect that is created with sprites alone. Some games use sprites for background layers too by repeating them over a single line (Risky Woods is a good example).

On top of all that, the game uses the Amiga's co-processor (copper) to alter the colour palette at different vertical positions on the screen, and then alternates between two palettes at 50Hz as well to produce a display with dozens of colours.

It really is a masterpiece of Amiga programming.

hippietrail
  • 6,646
  • 2
  • 21
  • 60
user
  • 15,213
  • 3
  • 35
  • 69
  • That's what I was wondering. I didn't realize the blitter was moving that much data in the background layer. So, it's basically doing a soft scroll then? (of the background layer). – cbmeeks Jul 23 '18 at 15:35
  • @cbmeeks yeah, soft scroll. It actually splits it over two frames as well so the scrolling is only 25 fps, meaning that the amount of data shifted on each frame is very small. – user Jul 23 '18 at 15:51
  • 2
    @cbmeeks it's a soft scroll of one bitplane and a hard scroll of the other two. – Tommy Jul 23 '18 at 21:37
  • To be precise, the two scroll registers control the even planes and odd planes, regardless of whether the dual playfield mode has been actually activated. While the original intention is the use with dual playfield, it could be used for other effects too. – Holger Aug 31 '18 at 08:22
6

It's as simple as you'd think; the individual bit planes have individual start addresses, set from DFF0E0 upwards, though the seventh and eighth planes listed there don't exist on the OCS or ECS Amigas, such as the A500 (OCS) or A500+ (ECS).

So they don't need to stick together at all, they're all set individually.

For scrolling finer than a word boundary (i.e. 16px), the Amiga offers two playfields. One is comprised of the even bit planes, the other of the odd. Each playfield can be hardware scrolled independently at pixel resolution.

Agony squeezes a third layer of scrolling by shifting one bitplane in the opposite direction to its playfield, so that it remains static. This is achieved via the blitter. The affected playfield ordinarily scrolls at only 25fps so less than 10% of blitter bandwidth is used up.

Tommy
  • 36,843
  • 2
  • 124
  • 171
  • 1
    Changing start address would only give 16-pixels-at-once horizontal scroll (while of course the finest 1 pixel vertical scroll). – lvd Jul 22 '18 at 18:15
  • 1
    @lvd you're right; I had strongly under-read the question. Updated to comment on playfields and how Agony as a specific title works. – Tommy Jul 23 '18 at 14:16
  • 2
    Standard request after anonymous negative voting: please also comment. Otherwise I don't get the opportunity to learn how to improve. – Tommy Jul 23 '18 at 21:38
  • @Tommy it's probably because you copied my answer after I posted it. – user Jul 24 '18 at 08:59
  • @user on the contrary, yours is wrong unless you already know the answer. I quote: "Then it splits the back playfield into two layers using a trick that keeps one of the three bitplanes stationary while scrolling the other two with the blitter." Maybe you're not a native spraker, and the text is ambiguous, but the thing that most strongly says is that the blitter scrolls two planes, which it doesn't. Luckily I have a long history here and have frequently originated community wiki answers when dealing with shared contributions, so your paranoia is easy to laugh off. – Tommy Jul 24 '18 at 13:00
  • And, yes, that's exactly why I added a comment in clarification after your misleading answer was accepted. With no intention of doing anything more. But direct personal attacks deserve a response, I think. Otherwise cf. https://retrocomputing.stackexchange.com/questions/4802/what-is-this-extra-lead-in-my-monitor-cable/4803#4803 https://retrocomputing.stackexchange.com/questions/5622/where-was-the-willowsoft-overture-file-system-ofs1-used/5626#5626 https://retrocomputing.stackexchange.com/questions/4984/how-was-the-traf-o-data-8008-simulator-developed/4985#4985 and many more. – Tommy Jul 24 '18 at 13:49
  • I updated my answer to clarify, you are right that it didn't read right. Anyway, my point is that the down vote is most likely because your initial answer was wrong, then I posted the correct answer with a link that explains it in detail, and then you posted the same thing. But of course I can't say for sure, I'm just speculating. – user Jul 24 '18 at 15:23
  • @user as per your admission, you didn't post the correct answer. Yours read as two bitplanes being blitter scrolled, which is distinct from my answer that one is. Per your allegation that we "posted the same thing", it'd also be interesting to know which part of your text is sufficiently close to "The affected playfield ordinarily scrolls at only 25fps so less than 10% of blitter bandwidth is used up." to justify the charge of copying. Of course, if it wasn't your vote, and you're just reasoning as to why it might have been made, you probably don't have direct answers. C'est la vie. – Tommy Jul 24 '18 at 15:31
  • oh god why do i even try to help people – user Jul 24 '18 at 15:32
  • @user "c'est la vie" was a pretty clear indicator of tone, I thought. Sorry that it flew over your head. – Tommy Jul 24 '18 at 15:37
  • Try Googling's "Poe's law" – user Jul 24 '18 at 15:42
  • @user fair comment. My previous big long comment was more intended to be outrage followed by resignation than parody but I guess sometimes one becomes a self-parody. Plagiarism is a fairly serious accusation, etc, so it got my heckles up. I shall try to be clearer in the future, and thanks for trying to help. – Tommy Jul 24 '18 at 15:45
  • @Tommy I'm curious where you got the < 10% bandwidth used from the blitter. I'm not saying you're wrong...I just don't know what the formula is. Thanks. – cbmeeks Dec 11 '18 at 20:52
  • @cbmeeks admittedly it was real back-of-an-envelope stuff: I used the broad approximate figure of ~70,000 chip memory access cycles per frame (from 224 per line) and worked from there, assuming a 320x256 frame, one bit per pixel, 16 bits per memory window, 25fps motion so two frames for each update. – Tommy Dec 13 '18 at 09:43