Tile maps and dual playfield mode

[nirvan75]

Hi guys,

I am wondering if somewhere is an example about loading and scrolling tiles in a foreground and background (a map for each) in a dual playfield mode.
Even a very basic one would be enough.

I have found some tile map source but I am too noob to be able to adapt it to my source
(Tiles can be loaded from a map file previously created for example with the RedMapEditor).

Note:
Since my game will be for OCS/ECS I think I will use Slice as reference source instead of Display library because the manual says that Initcoplist can accept only #fmode0 and #lowressprite parameters, but not #dualplayfield, on non-AGA machines.

[Daedalus]

The Display Library should work fine on OCS/ECS machines with dual playfield displays. Some flags are only available on AGA machines, but dual playfield isn't one of them. The limited flags are purely because of hardware limitations (e.g. highres sprites and fetchmodes > 0).

As for an example, I don't have one to hand but there should be plenty around. Dual playfield displays aren't really that special, you just have two bitmaps to scroll instead of one. Just use any example of tile scrolling and duplicate it for both playfields. Just remember the front playfield needs some colour 0 (transparent) to be able to see the rear playfield.

[nirvan75]

Thanks Daedalus.

I have already converted everything using the Display lib. instead of Slice and it's great.
Parallax is very smooth now.

[nirvan75]

I have already a new question about the dual playfield

Until now I have used 2 playfields of 3 bitplanes each , obtaining a total of 6 bitplanes display.
Do you think it is possible to further split the background playfield in two playfields?

In this way:

- one foreground playfield (still 3 bitplanes)
- one background playfield with 2 bitplanes + one background playfield with 1 bitplane.

I know they used this setup in some amiga game, but the programming language was ASM, so I am not sure if it is possible in Blitz, using the display library.

[Daedalus]

Not directly, but that's a limitation of the hardware rather than Blitz - Amigas only have two layers in their hardware. Other layers have to be simulated, either by manually blitting the two "virtual" layers together as one with stencils or masks, or by using sprites as a third layer.

[roondar]

Originally Posted by Daedalus

Not directly, but that's a limitation of the hardware rather than Blitz - Amigas only have two layers in their hardware. Other layers have to be simulated, either by manually blitting the two "virtual" layers together as one with stencils or masks, or by using sprites as a third layer.

It may be an option to do something like Agony: http://francksauer.com/index.php/gam...games/10-agony (the interesting bit starts under 'background')

This does run in standard dual playfield mode, the third monochrome layer is added using an interesting technique. Basically, they split the background layer into two by doubling a bunch of colours. This makes it so that they can just have the 1 bitplane background layer and not worry about changing the 2 other bitplanes.

Now, I'm not certain how they actually implemented the third layer staying static all the time, but I see two basic options:

1. use the blitter to blit the background shifted at the right offset. This costs some blitter time, but it's only one bitplane and the background layer doesn't scroll every frame so that's probably doable without spending too much blitter time*.
2. for a static background layer, you can also store all required shifted versions in memory. That would take a lot of chipmemory though.

At any rate this technique does mean the background layers can only use 4 colours in total + transparent, so it's a tradeoff. But it sure looks nice in action!

*) one 288x192 pixel bitplane is 3.456 words and would take 6.912 colour clocks to draw using the blitter. Which is about 12% of the DMA time the game should have left for running in Dual Playfields @304*192.

[Daedalus]

Yeah, it's an interesting technique alright, and looks impressive! My guess is that it's blitted too, as you say with only one bitplane it's doable with still enough time left to do other graphical operations. You'd really need to know what you're doing to get away with it, but it's possible.

[nirvan75]

This is very interesting!
That particular effect of Agony is exactly what I was thinking about when I wrote this post.

So let's try to replicate this nice effect.
I have started from a very basic blitz example about dual playfields and I have added a copperbar. The code it's very rough but it should be enough to be used as a test.
We could try to split the background layer as said, and add a static (non-scrolling) background picture of 2 colors (see iff file) which I just draw and included in the .lha file.
Anyone want to try? :P

[ReadOnlyCat]

Originally Posted by roondar

Now, I'm not certain how they actually implemented the third layer staying static all the time, but I see two basic options:

1. use the blitter to blit the background shifted at the right offset. This costs some blitter time, but it's only one bitplane and the background layer doesn't scroll every frame so that's probably doable without spending too much blitter time*.

[...]
*) one 288x192 pixel bitplane is 3.456 words and would take 6.912 colour clocks to draw using the blitter. Which is about 12% of the DMA time the game should have left for running in Dual Playfields @304*192.

Originally Posted by Daedalus

Yeah, it's an interesting technique alright, and looks impressive! My guess is that it's blitted too, as you say with only one bitplane it's doable with still enough time left to do other graphical operations. You'd really need to know what you're doing to get away with it, but it's possible.

I also think this must be blitted and if roondar's figures are correct this still leaves quite a few DMA cycles available for other things (I would expect this technique to have a higher cost though given how few cycles are available with 6 bitplanes dual playfield mode).

Also note that the background plane they use has a lot of uniform areas so if they are smart enough, they are moving only the non-uniform areas, saving quite a bit of Blitter time in the process.

[roondar]

Originally Posted by ReadOnlyCat

I also think this must be blitted and if roondar's figures are correct this still leaves quite a few DMA cycles available for other things (I would expect this technique to have a higher cost though given how few cycles are available with 6 bitplanes dual playfield mode).

Also note that the background plane they use has a lot of uniform areas so if they are smart enough, they are moving only the non-uniform areas, saving quite a bit of Blitter time in the process.

Well, it's always good to have your math checked and it did turn out I miscalculated, so here is take two complete with hopefully accurate numbers this time...

Here are all the numbers:

Agony uses a 288x192 screenmode, plus 16 pixels for scrolling, resulting in bitplane DMA for 304x192. It uses 6 bitplanes. This costs (304/16)*192*6 colour clocks, or 21.888 colour clocks total for bitplane DMA.

The Amiga has 226x313 colour clocks available per PAL frame, or 70.738 in total.
Memory refresh costs 4 colour clocks per scanline: 313x4 = 1.252.
Audio costs up to 4 colour clocks per scanline: 313x4 = 1.252.
Sprites cost up to 2 colour clocks per channel per scanline: 192x2x8 = 3.072.

So, Agony should have 70.738 - 1.252 - 1.252 - 3.072 - 21.888 = 43.274 colour clocks left.

The blit costs (288/16)x192x2 colour clocks = 6.912 colour clocks.
Which is ~16% of DMA time left, not the ~12% I posted last time.

[ReadOnlyCat]

It still leaves the game plenty of time to blit enemies as well as some background animations apparently. I watched a longplay of it this afternoon and was really surprised at the large number of moving objects on the screen. It is a shame that the game's gameplay and level design are so bad because graphically and technically it is otherwise really impressive (putting aside the inefficient tilemap).

[roondar]

Yeah, Agony is very impressive graphically! And yet it also shows the Amiga Dual Playfield limits quite well, enemies are almost invisible at times due to lack of colours.

Like you said though, it's the level design/gameplay that's at fault. I never really liked it as a game, enemies where far too hard to kill even if you had massive bullets and the player sprite is just too big to properly avoid bullets and the like.

I guess they put too much time into making it pretty as opposed to making it play nice. Same problem as Shadow of the Beast.

[nirvan75]

Thanks guys for all your answers and comments. I have started few weeks ago with blitz2 and i didn't understand all you suggested me to do, but I am quickly learning a lot of useful things.

So I am trying to find the right way to split the background as discussed.
I guess it could be done initializing the dual playfield bitmaps 0 and 1 where the first has 3 bitplanes and the other just 2, instead of 3 as usually. I put there my graphics (tiles, iff picture or just circle and boxes like in the attached example of my previous post) and then I could create a third bitmap (of 1 bitplane) for the third layer and load into it a .iff picture with 2 colors.
The initcoplist is like this:
initicoplist 0,44,256,$36,8,16,-1 (the -1 is for displayrainbow command using ecs)

I move the 2 main layers with displaybitmap 0,0,x,0,1,x1,0
Anyway, should I use a separated displaybitmap command for the third layer in order to get a static layer? Otherwise it will scroll with the other layers.

[Daedalus]

No, there is still a limit of two physical layers so any third layer has to be simulated another way. The displaybitmap command will replace the currently displayed bitmap with the third one. You need to combine the second and third bitmaps one way or another and then use displaybitmap to put the resulting combined image on the screen.

[LuMan]

In line with Daedalus' comment, the only way I could see this working is to have a Shape, that is the same size as your screen, for the static layer and Block it to the background bitmap before stamping the remaining background graphics onto it.

However.... although Block is the quickest way of doing this (natively in Blitz), you will still get 2 major issues:
1. Speed - you may pull it off on an accelerated A1200, but anything else will slow your frame-rate down a fair bit - particularly if you're also hanging on for VWaits, too.
2. Block can only work in multiples of 16, so you will have to re-think how you want to add the base level of your background before adding the other stuff on top, as you need the base to be static while scrolling the background with the DisplayBitmap command.
Mind you, if it is only a 2-colour bitmap, you could have 16 of them, each offset by 0 to 15 pixels and Block them in turn. Then, when you show the bitmap with its offset, the static image will remain static... So, make that an A1200 with an 040/25 and a load of extra RAM!

Seriously, though, good luck with it. I hope you manage to come up with something, as there's plenty of us here enjoying this Blitz learning process

[nirvan75]

Yes, shapes seem to be the a good way.
Since I am thinking about to a horizontal scrolling game, I am populating both the bitmaps with 16*16 tiles (using block command), all at the once, before the game starts and then scroll them independently to give the illusion of parallax.

But right now I am reading another thread about tiling and I am a bit worried that maybe my bitmaps should be too large to allow some minutes of continuos scrolling.
Do you think I should consider some of the technic described in the the following thread instead?
http://eab.abime.net/showthread.php?t=81044
In that case the dual playfield advantages of hardware scrolling would be not so useful since the bitmaps are not scrolling and they just scroll the tiles inside of it. And also I would need a double buffer. In the other side I wouldn't have such strict colors limitations due to the dual playf.
Mhh, I have to evaluate if it's better (or not) to change completely my current technic..

[idrougge]

Dual playfield doesn't matter; it's still the same scrolling techniques used, just on one or two playfields.

[Samurai_Crow]

Originally Posted by idrougge

Dual playfield doesn't matter; it's still the same scrolling techniques used, just on one or two playfields.

That's right. The only thing is that if you can't use the modulo trick for some reason, the bitplane pointer updates might take too many DMA slots when the seams overlap.