Dual Playfield - Was it avoided because of speed or colors or something else?

[lionagony]

I finished Leander for the first time tonight and was reading about it afterwards and saw this video by the coder Jon Burton [ Show youtube player ] where he talks about using dual playfield for pixel perfect collision detection. The weird thing about Leander is that although it's in dual playfield it doesn't really use a back playfield, instead it uses copper bars and multiplexed sprites for the background. I found this odd because why go for reduced colors and just use dual playfield for collision detection instead of having a full scrolling background? However, in the video he mentions that one of the drawbacks of dual playfield is that it quote "slows down the main processor meaning you'd get less done each frame"

As a non coder but an avid gamer I know that most of the Amiga's most visually impressive OCS/ECS games are in dual playfield, SOTB, Agony, Lionheart, Jim Power, Kid Chaos, Mr Nutz, Elfmania etc. and none of them are slow. Is it really the case that dual playfield slows things down considerably? I know it uses 6 bitplanes but only the color depth of 4.

Then you have other OCS/ECS games like Zool, Bubble and Squeak, Battle Squadron, Global Gladiators, Wiz N Liz etc. where the Amiga version doesn't use dual playfield but the console versions do. So do you think that having to reduce the colors to 7 for each playfield was the determining factor in these decisions or was it the lack of speed in that mode or maybe some other reason?

[Tigerskunk]

It depends. As always with the Amiga.

Using 6 Bitplanes takes a lot of DMA time. But you have to blit less planes.
I guess most devs avoided it because it is difficult to get it right from the aesthetics side.

[Galahad/FLT]

I suspect other than collision detection, he had all animated objects and enemies on one playfield and the level graphics on another, which saves lots of extra time, because what you draw on the top playfield doesn't affect what is on the other playfield, so less effort and more objects.

Dual playfield is fine, but it doesn't work well for all games.

Jim Power is dual playfield, but with extensive pallete reloading, obviously looks far better than the 8 colour per playfield limit, but that is made possible because the game only scrolls left to right in those stages, so the colour reloading is on fixed horizontal lines.

Something like Leander is 8 way scrolling and the pallete would have to be dynamically altered whenever the playfield scrolled up and down, and that could be a lot of colours to reload , and then how much time do you have left for an actual game?

[lionagony]

Originally Posted by Tigerskunk

It depends. As always with the Amiga.

Using 6 Bitplanes takes a lot of DMA time. But you have to blit less planes.
I guess most devs avoided it because it is difficult to get it right from the aesthetics side.

Yeah it takes a really skilled artist. I was asking Tsak about how they copperise background colours in Metro Siege like in Agony and whether that would be able to be done to make the backgrounds and enemies stand out more in Turrican 3 for example and he said possibly but it would be very complicated. Lionheart uses the copper gradient on the foreground but even they didn't go as far as I guess it could be taken with an 8 way scroller in dual playfield. So it might be theoretically possible but would take more time and effort then devs had back then.

For the games like Zool that eschewed dual playfield maybe they had porting in mind from the start and were thinking it would be easier to port if they concentrated on a 16 colour front layer. Then that could be directly ported anywhere and the other systems could worry about their own backgrounds.

[lionagony]

Originally Posted by Galahad/FLT

I suspect other than collision detection, he had all animated objects and enemies on one playfield and the level graphics on another, which saves lots of extra time, because what you draw on the top playfield doesn't affect what is on the other playfield, so less effort and more objects.

Yeah it's an interesting decision they made with Leander, I'd never heard of choosing dual playfield in part because of collison detection before. And if he was concerned about speed to then have the sprite mulitplexing on top which is also taxing to the system you'd think that might negate the benefits of dual playfield. They might have been able to do a bigger sprite layer in the background without it and 16 or 32 colours in the foreground. I guess he made all these calculations and figured his decision was best for the game and it's a great game so no complaints here.

Jim Power is dual playfield, but with extensive pallete reloading, obviously looks far better than the 8 colour per playfield limit, but that is made possible because the game only scrolls left to right in those stages, so the colour reloading is on fixed horizontal lines.

Something like Leander is 8 way scrolling and the pallete would have to be dynamically altered whenever the playfield scrolled up and down, and that could be a lot of colours to reload , and then how much time do you have left for an actual game?

True. I was saying to Tigerskunk above something like that might be possible but would be extremely tricky to implement. Using the copper like the attached picture but with an 8 way scroller in dual playfield would be a massive headache and as you say might be hard processor wise too but I'd sure love to see someone try it!

[Galahad/FLT]

I think Jon Burton actually used the Amigas built in collision detection using the hardware which is quite a bit faster than doing lots of coordinate checking using the CPU

[Photon]

Lowest Common Denominator = create 1 buffer and draw objects in it.

Screenshots sell = don't reduce colors to make the game play twice as fast, and no need to worry about choppy scrolling.

The answer is rather constant for not taking advantage of Amiga-specific features: The publishers didn't know what the Amiga could do, and they'd only seen early efforts (e.g. games for NTSC A1000), and so didn't hire programmers-skilled-on-the-platform like they did for the C64, Spectrum, etc.

As for Dual Playfield, I think a lot of the Amiga originals did use it where applicable. It's not (necessarily) applicable for games that have no use for scrolling or other scrolling of course, like 3D/2D/1D "scrolling direction into the screen" as it's called in the HOL. E.g. flight sims and racers.

It will halve the number of colors, but ST ports had no problem doing that... including sloppy & dark palette conversion, since we're talking color...

And for flipscreen or similar e.g. puzzle games, Boulder Dash/Joust/Spectrum pixel platformer type ports, or arcadey 1 screen=1 level like Bombjack, Bubble Bobble etc, the games were designed to, or the game ideas themselves were adapted to hardware available at the time which had no playfields, sprites, or scrolling.

There were quite a few RTS games that were laggy and could have benefitted greatly from Dual Playfield... all the famous sims and god games... a qualified programmer could easily make a Lemmings game full framerate on NTSC...

In the right hands it's a very good option to have and use playfields and sprites, and scrolling if your game needs it. So from your questions why they didn't have it, my answer is that in the right hands, they did.

[rothers]

I think the best setup for dual playfield is to have the bobs on the back layer, this way you can get 8 colours for the foreground and 8 colours for the bobs (and for a background) and then still have a further palette for your sprites (player).

Only a few games did it like that, but it is the best set up for maximum colours, that is you don't get sad looking 'brown' sprites on the front layer.

You can also throw in some rainbow settings too.

[lionagony]

Originally Posted by rothers

I think the best setup for dual playfield is to have the bobs on the back layer, this way you can get 8 colours for the foreground and 8 colours for the bobs (and for a background) and then still have a further palette for your sprites (player).

Only a few games did it like that, but it is the best set up for maximum colours, that is you don't get sad looking 'brown' sprites on the front layer.

You can also throw in some rainbow settings too.

That does seem like a good idea as a background of only a few colors still usually looks pretty good and we have the copper. Would you happen to know a list of Amiga games that did use that technique and maybe why it wasn't used more often?

[rothers]

Originally Posted by lionagony

That does seem like a good idea as a background of only a few colors still usually looks pretty good and we have the copper. Would you happen to know a list of Amiga games that did use that technique and maybe why it wasn't used more often?

I think chuck rock 2 and shadow of the beast 3 (or 2?) use it.


I guess it was not immediately obvious to use it like that.


It absolutely gives the best results in terms of colour, however it means the bobs will be behind the foreground, which you will have to work around in some cases. If you allow your player to walk through solid walls, for example the bob's can't be there (in front), you'll have to use the front palette for those.

I still think this is the best set up, you can use all 16 colours for the bobs if you use them on the front and back layer. It's fast to write to each layer. It's the most colourful approach. It uses less memory for graphics storage (8 colours vs 16). etc. etc.

If Commodore had spent time giving us proper libraries to code with the above should have been a pre-setup option imo. Much more console like result.

[DanScott]

Yep, i used that method in Chuck Rock 2 (and Wonderdog)

We had all sprites available for Chuck Jnr, and his club... plus 2 free sprites were used for rain and snow effects on a few levels (could have used them more in other places if we'd had time)

Also, some levels only 6 colours were used for the bobs, with the 7th colour used for gradients on the background (could have made much better use of this too if more thought and time given)

[Tigerskunk]

When Inviyya was still dual playfield I did that. And thought I had the most clever idea ever that no one else ever thought about before..

You can even see this in action in this video:
[ Show youtube player ]

The blue enemies are in the background layer.

[saimon69]

Originally Posted by DanScott

Yep, i used that method in Chuck Rock 2 (and Wonderdog)

We had all sprites available for Chuck Jnr, and his club... plus 2 free sprites were used for rain and snow effects on a few levels (could have used them more in other places if we'd had time)

Also, some levels only 6 colours were used for the bobs, with the 7th colour used for gradients on the background (could have made much better use of this too if more thought and time given)

Chuck Rock II had this feeling it could have been a megadrive game, if was not for the (needed) dithering, was a very well done job and also had a killer funky soundtrack by nuke!

[sokolovic]

It is a Megadrive game ! I would'nt be surprised that the MD version is the originam one and the Amiga a port.

[saimon69]

Originally Posted by sokolovic

It is a Megadrive game ! I would'nt be surprised that the MD version is the originam one and the Amiga a port.

You are kinda missing the point, most amiga games did NOT felt like they were trying to impress and play like console games - or even arcade - at the time, rather were like an afterthought, a "take this and shut up" - and is one of the reason a lot of people went console, so Chuck Rock 2 was a good thing

[lionagony]

Originally Posted by saimon69

You are kinda missing the point, most amiga games did NOT felt like they were trying to impress and play like console games - or even arcade - at the time, rather were like an afterthought, a "take this and shut up" - and is one of the reason a lot of people went console, so Chuck Rock 2 was a good thing

I would definitely argue that. Chuck Rock 2 came out in 1993 and some people would say that was the best year for Amiga gaming. (I personally think 92-94 was the sustained peak) In 1993 you had Amiga originals like Chaos Engine, Lemmings 2, Goal!, Sink or Swim converted to MD/SNES, Soccer Kid (converted to SNES, Jaguar, 3DO) and Brutal Sports Football and Zool 2 to Jaguar. Not to mention 1993 was when Lionheart came out which I'll always maintain is better than the consoles could do for that style of game and Stardust which used 3D modelling a whole year before the world was blown away by Donkey Kong Country.

[Tsak]

Definitely Dual Playfield stresses a lot the art workload. Especially in regards to color usage and palettes. Other than 7 colors per layer being indeed quite restrictive, I think choosing the colors extremely carefully in the first place can make all the difference. For example while many of the Amiga titles using it have absolutely superb pixel art, they often fall into the trap of going with mono-color ramps and very muted colors, while they could do proper hue-shifting instead. Interesting case studies for this are Lionheart and Agony, where (inevitably) a lot of enemies end up monochrome and often very close to the foreground.

Speaking of which I was looking today at a longplay of Agony and noticed some things in regards to how they use copper in an attempt to overcome this issue. F.e. in level 1, apart from the obvious copper use in the back layer where they change colors at the lower part for the sea and upper part depending on the used gfx there, I noticed a lot of dynamic copper trickery in the front (bobs) layer as well. Like they have this wave of weird red enemies appearing at specific points, but if you notice these tend either to fly at the very top of the screen (when there's no foreground gfx at the top), or later move vertically across the screen (when there's no foreground at all either). Similar story with the purple sharks which appear strictly at the bottom.

[lionagony]

Originally Posted by Tsak

Definitely Dual Playfield stresses a lot the art workload. Especially in regards to color usage and palettes. Other than 7 colors per layer being indeed quite restrictive, I think choosing the colors extremely carefully in the first place can make all the difference. For example while many of the Amiga titles using it have absolutely superb pixel art, they often fall into the trap of going with mono-color ramps and very muted colors, while they could do proper hue-shifting instead. Interesting case studies for this are Lionheart and Agony, where (inevitably) a lot of enemies end up monochrome and often very close to the foreground.

Speaking of which I was looking today at a longplay of Agony and noticed some things in regards to how they use copper in an attempt to overcome this issue. F.e. in level 1, apart from the obvious copper use in the back layer where they change colors at the lower part for the sea and upper part depending on the used gfx there, I noticed a lot of dynamic copper trickery in the front (bobs) layer as well. Like they have this wave of weird red enemies appearing at specific points, but if you notice these tend either to fly at the very top of the screen (when there's no foreground gfx at the top), or later move vertically across the screen (when there's no foreground at all either). Similar story with the purple sharks which appear strictly at the bottom.

Yeah and there are a few quirks in Agony in regards to this, such as in Level 3 at 12:23 the bottom enemies turn from green to grey when they move downwards and in level 6 at 24:40 the skulls go from red to grey when they pass a certain line. [ Show youtube player ]

I'm also not sure how they get the extra colours for some of the powerups. Still such an amazing, beautiful game to me. Just as an aside I thought I'd rank my favourite levels visually after going through that longplay again. My absolute favourite is level 4, then level 2, 1, 6, 5, and 3 in that order. Would love to hear other people's rankings.

While we're discussing dual playfield does anyone know what's going on in Cool Spot? Say at 18:46 [ Show youtube player ] it's in dual playfield but the background doesn't look to be 7 colours and at say 42:54 it's definitely not 7. Do you think they just used 1 or 2 bitplanes for the back layer instead of 3 just to try to speed things up as the scrolling isn't very smooth or is there another reason? Always interested in an explanation for that one.

[Tsak]

Originally Posted by lionagony

I'm also not sure how they get the extra colours for some of the powerups.

These are most definitely sprites. If I had to guess, they use:
- 4 sprites for the player and swords (that is 2 attached to access all 15 colors and be 32px wide).
- 1 sprite for the player projectile.
- 1 sprite for the enemy yellow projectiles (which they multiplex the heck out of them - if you notice these also flicker when they overlap horizontally).
- And lastly 2 more sprites (again attached) for the powerups.

They most probably use sprites for the entire powerup selection menu as well. And also to do some other effects. F.e. the rain at the start must also be a multiplexed sprite. Interestingly it stops immediately once the first powerup appears which suggests they might have been using the same sprite channels for both.

[lionagony]

Originally Posted by Tsak

These are most definitely sprites. If I had to guess, they use:
- 4 sprites for the player and swords (that is 2 attached to access all 15 colors and be 32px wide).
- 1 sprite for the player projectile.
- 1 sprite for the enemy yellow projectiles (which they multiplex the heck out of them - if you notice these also flicker when they overlap horizontally).
- And lastly 2 more sprites (again attached) for the powerups.

They most probably use sprites for the entire powerup selection menu as well.

That's right, from Codetapper's article https://codetapper.com/amiga/sprite-tricks/agony/ he says:

Sprites are used in the following manner:

Sprites 0-1 (attached) form the left part of the owl, as well as the sword above the owl when activated. Since they are attached, they are 16 colour sprites.
Sprites 2-3 (attached) form the right part of the owl.
Sprites 4-5 form the owl's bullets.
Sprites 6-7 are used for the rain effect, by displaying the rain graphic twice on each line of the display. By moving the sprites to a different location each update, the rain looks very realistic!

And on the artist Frank Sauer's blog https://francksauer.com/index.php/ga...ublished-games he says similar:

On top of the bitmap layers came the hardware sprites. We used two sprites for extra rain effect. Note there's always a maximum of two sprites for each raster line:

Another sprite was used for the enemies bullets. It was multiplexed so that only one bullet could be on a given scanline.

Finally, the rest of the hardware sprites was used for the owl and the owl projectiles and shield.

Interestingly neither site mentions the powerups but yeah I'm sure you're right, they must be sprites.

And also to do some other effects. F.e. the rain at the start must also be a multiplexed sprite. Interestingly it stops immediately once the first powerup appears which suggests they might have been using the same sprite channels for both.

Nice catch!