Coders, how was [this] done in [this] game?

[lionagony]

Playing so many Amiga games these days I often have technical questions about them and thought maybe this could be a good thread for me or any others that have questions about how certain things were done in certain games. I'll start with these 3:

Elfmania - how are they able to do line scrolling on the floors when it's not in dual playfield mode? [ Show youtube player ] If that was always possible why wasn't it used more? Maybe the first level of T-Racer is also done that way. [ Show youtube player ]

Apocalypse - at 8:02 in this video [ Show youtube player ] how were they able to get so many colors on screen if it was in 7+8 color dual playfield mode? Or maybe it wasn't. In the Youtube comments the developer says "I think for that game we managed to exploit a Denise-chip hack where an extra parallax layer was achieved by redefining sprites in the split-second that the raster scan goes from the right of the screen to the left. It was actually a small set of sprites that were continually redefined ahead of the raster scan to create the illusion of a parallax layer." Someone comments on that "so the skyline layer were achieved with sprites.. I always though it were using another bitplane.." and he responds "Yes, I think so. It's hard to remember now if it was that game or another. There was a maximum number of bitplanes and it was possible to squeeze one more out of the system with a sprite hack. I feel pretty sure I used it on Apocalypse, but it was a million years ago." Can someone explain that Denise hack he's mentioning?

Cool Spot - the backgrounds in Cool Spot have always mystified me, I think it's in dual playfield mode but then why are the backgrounds in only one color like at 48:34 here [ Show youtube player ] with the shelves just done by the copper? Or do they somehow have the dual playfield using 3 bitplanes in the foreground and just one bitplane in the background for more speed? Is that possible and would it be faster? Also how in the same video above at 16:16 do they make the boat appear to go up and down in the background?

Thanks for any explanations.

[AestheticDebris]

I think Apocalypse is just a case of using repeating sprites to create the background layer rather than Dual Playfield.

For Cool Spot, no you can't choose the distribution of playfield layers on the Amiga. The backgrounds do just look like a single bitplanes with some copper colours though. My guess is that layer is just being scrolled manually with the blitter. The boat going up and down is just scrolling that layer, you just have to keep track of the fact you want it to move independently as well as relative to the player so you're moving things the correct amount depending on on-screen action.

[Codetapper]

Apocalypse is not using dual playfield at all.

It's basically a 4 bitplane game for the main area, and a 5th bitplane for the single colour parallax mountains in the far background and the single colour black shrubs at the very bottom of the screen.

The game duplicates the first 16 colour palette entries (0-15) into the second set of palette entries (16-31, which are also shared with the sprites) and then it changes colour 15 and 31 all down the screen to create the mountain behind or the shrubs in front of the main area.

Sprites are only used for the status icons and number of rescued hostages etc. I didn't see any complicated multiplexing of sprites, except for the very top row of numbers at the top of the screen (it uses sprite 0, then 1, then 0 again) in my brief look.

[jotd]

to figure it out, run it with WinUAE, then shift+F12, then "e"

check value of BPLCON0.

4200: 4 planes
5200: 5 planes
6600: dual playfield

[Codetapper]

Originally Posted by jotd

to figure it out, run it with WinUAE, then shift+F12, then "e"

check value of BPLCON0.

4200: 4 planes
5200: 5 planes
6600: dual playfield

Copperlist tricks don't always make things that easy when the game changes modes down the screen.

Elfmania is 32 colours and I assume it just copies the relevant strips a line at a time from a larger image to simulate the moving floor effect. It can't just shear the strips sideways because the player characters would also end up moving, unless you also drew the characters a step at a time. In other words, not likely!

[Codetapper]

Cool Spot is simply 4 bitplane 16 colour mode, and it draws the parallax background into the screen. The parallax is always just a single colour (with some palette tricks to make it look more) but the game sucks imho. It only updates the screen every 3 frames, so we're talking about 16-17fps. Because of this, the scrolling is really jerky and isn't impressive at all.

[rothers]

The only one I find hard to figure out is Elfmania, I've always been fascinated by all the tricks going on in that.

[Photon]

Just had a quick look. Generally, the thing that makes it look like "triple playfield" is the reuse of sprites.

Perspective floor is made by scrolling each pixel line individually at different speeds. The pier stumps in front are sprites just like the main characters (Elfmania).

Background or foreground sprite layers can be built by spamming SPRxDAT, or repeating patterns in more colors by spamming SPRxPOS. Multiple sprite layers can scroll at different speeds as long as they don't overlap vertically (black stuff in Apocalypse at top and bottom).

[lionagony]

Thanks guys for all the great info. This got me reading these links in the Hardware Reference Manual and had a couple more questions. Here http://amigadev.elowar.com/read/ADCD.../node0078.html it says that there are up to 7 colors in each playfield. Previously I've heard many times that it can be 8 colors in one playfield and 7 colors plus transparency in the other. So is the correct way to think of it that if you're in dual playfield mode (and want graphics from both playfields to be seen) that you can have max 7 colors + transparency in the foreground and then max 7 colors + transparency in the background if you want the copper to shine through but 8 colors max in the background if you don't want the copper to shine through?

Also this page http://amigadev.elowar.com/read/ADCD.../node0079.html makes it seem like you can split the dual playfield bitplanes in other number combinations other than 3 + 3. It gives examples of 1 + 1, 2 + 1, 2 + 2 and 3 + 2. I know you can split the bitplanes and scroll some of them with the blitter but if you want to use hardware scrolling could you really do a 2 + 2 for example where the foreground is 3 colors and the background is 3 colors and they both hardware scroll? How much faster would a 3 + 2 split be than a 3 + 3 split for example?

Last question what about where Codetapper says "Apocalypse is basically a 4 bitplane game for the main area, and a 5th bitplane for the single colour parallax mountains in the far background and the single colour black shrubs at the very bottom of the screen. The game duplicates the first 16 colour palette entries (0-15) into the second set of palette entries (16-31, which are also shared with the sprites) and then it changes colour 15 and 31 all down the screen to create the mountain behind or the shrubs in front of the main area." Would this be possible using 6 bitplanes? Like could you have a 5 bitplane game with the palettes duplicated and then 1 extra bitplane for 1 color parallax? This way you wouldn't be using more than the 32 color registers and you could have a 32 color game like Superfrog with a parallax layer in single playfield. Is there a reason why this wouldn't be possible or would it be possible and just slow? Thanks again for any explanations.

[Codetapper]

Yes you could go with 6 bitplanes if you really wanted, but there's drawbacks with everything.

6 bitplanes (halfbrite mode) doesn't exist on some early Amiga 1000s.

6 bitplanes takes more DMA time, so the game might end up running slower.

Some repeated sprite tricks wouldn't work because you can't update the sprites fast enough.

You can draw into the 6th bitplane fine but you can't fine-scroll it. You can only set the fine-scroll value for all odd, and all even planes. So you would basically have to update that 6th bitplane everytime you wanted the screen to scroll. The only other trick you could try is to use a repeated background pattern that has all 16 pixel indent combinations in it and you'd have to choose the right offset to make it look like it was scrolling by one pixel each time. (Consider a repeating pattern of say 17 pixels wide, each time you offset by 2 bytes (16 pixels) it would look like you had fine scrolled it by 1 pixel). However you'd get a very boring background, not some nice tall mountain range.

[Galahad/FLT]

I'm assuming just by guessing that the game switches bitplane priority and the bottom parallax layer and the upper one are the same, and when the upper layer is no longer visible, priority is switched so that background layer is now a foreground layer.

[lionagony]

Originally Posted by Codetapper

Yes you could go with 6 bitplanes if you really wanted, but there's drawbacks with everything.

6 bitplanes (halfbrite mode) doesn't exist on some early Amiga 1000s.

6 bitplanes takes more DMA time, so the game might end up running slower.

Some repeated sprite tricks wouldn't work because you can't update the sprites fast enough.

You can draw into the 6th bitplane fine but you can't fine-scroll it. You can only set the fine-scroll value for all odd, and all even planes. So you would basically have to update that 6th bitplane everytime you wanted the screen to scroll. The only other trick you could try is to use a repeated background pattern that has all 16 pixel indent combinations in it and you'd have to choose the right offset to make it look like it was scrolling by one pixel each time. (Consider a repeating pattern of say 17 pixels wide, each time you offset by 2 bytes (16 pixels) it would look like you had fine scrolled it by 1 pixel). However you'd get a very boring background, not some nice tall mountain range.

Fascinating, that would be very interesting to see someone come up with a game or even just a small example of that running as I don't think it's ever been tried before.

[AestheticDebris]

Originally Posted by lionagony

it says that there are up to 7 colors in each playfield. Previously I've heard many times that it can be 8 colors in one playfield and 7 colors plus transparency in the other.

OK, so this is mostly semantics. Strictly speaking, there are 7 colours + transparent in the foreground layer, 7 colours + transparent in the background layer and then a final colour that shows through otherwise. But, in practice, that's exactly the same thing as having 7+8 colours, so that's the way everyone (except the RKRM) tends to describe it.

Originally Posted by lionagony

Last question what about where Codetapper says "Apocalypse is basically a 4 bitplane game for the main area, and a 5th bitplane for the single colour parallax mountains in the far background and the single colour black shrubs at the very bottom of the screen. The game duplicates the first 16 colour palette entries (0-15) into the second set of palette entries (16-31, which are also shared with the sprites) and then it changes colour 15 and 31 all down the screen to create the mountain behind or the shrubs in front of the main area." Would this be possible using 6 bitplanes? Like could you have a 5 bitplane game with the palettes duplicated and then 1 extra bitplane for 1 color parallax? This way you wouldn't be using more than the 32 color registers and you could have a 32 color game like Superfrog with a parallax layer in single playfield. Is there a reason why this wouldn't be possible or would it be possible and just slow? Thanks again for any explanations.

Not with OCS/ECS, because you need as many palette registers as there are bitplanes colours for the trick to work. You have to sacrifice half of the palette registers by setting them to match specific other entries.You can't just freely choose how bitplanes map onto palette registers.

[Codetapper]

Originally Posted by Galahad/FLT

I'm assuming just by guessing that the game switches bitplane priority and the bottom parallax layer and the upper one are the same, and when the upper layer is no longer visible, priority is switched so that background layer is now a foreground layer.

With a 5 bitplane game you can't just switch the priority of a bitplane around like that (unlike dual playfield) unfortunately - if only it were that simple! Instead the game waits for the relevant line to appear then sets all colours in the palette from 16-31 to black at the bottom of the screen. And you're right that the same bitplane holds the mountains and shrub graphics.

Because the shrub pixel graphics are set, colours 16-31 take effect and draw those set pixels as black. Anything not set will still display the graphics behind it. And because the game is setting all sprite colours to black at the same time, no sprites can be drawn at the very bottom of the screen which is why the weapon counter sprites are further up the screen.