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

[Photon]

Originally Posted by rothers

Leaving it for coders to figure out was a shame.

Well here, Commodore-Amiga cannot be blamed, for there is an entire example (illustrated with pictures no less!) in HRM on how to construct a game with playfields and sprites.

[JudasEZT]

What I had understood that, and in fact is happening in a project of mine, that in Dual Playfield mode you lose a channel of sprites. Channels 6 and 7.

There are ways to not lose them??

[jotd]

I used DPF on AGA on Xevious, and used all sprites at some point, and never got that dreaded sprite bug (I heard that the 7th sprite could be hidden because of the bug). I guess it happens in some particular cases.

[ross]

This has been discussed in many many threads

It has nothing to do with dual playfield and depends exclusively on the value used in DDFSTRT.
The lower the value, the more slots are subtracted for the sprites fetching.
In the HRM there is a diagram of the DMA slots which gives a rough idea of the situation.

In addition to this there is a HW bug in OCS that prevents the use of the last sprite slot when it is back-to-back with the start of the bitplanes first fetch block.

[aros-sg]

Originally Posted by ross

Yep, this works

But at the 'wrap' you need an already fully built backbuffer (basically you must have a double image in memory).

I'm not sure what you mean, but you only have 3 normal sized buffers. 1 for display, one for backbuffer rendering and one for restoring. After bob restoring you have 2 clean buffers and for the next frame depending on the next y scroll position you choose which one of this 2 buffers will become the next display buffer (= current backbuffer where to paint bobs) (the one which does not wrap). The other becomes the restore buffer for restoring job in the frame after.


The precaution I mentioned, that is necessary, is that the scroll position between current frame and next frame must not be too hugely different
(unless you had huge safety gaps) because the 3 buffers share the same available ~memory/~area in the ~"master buffer" and must not trash each other. During scrolling both in x and in y direction the buffers move around in this ~memory/~area.


For example at scroll y position 0, buffer #1 may live here:

1111
1111
1111
1111
####
####
####
####
####
####
####
####

While, after scrolling half a screen up it will live here:

####
####
1111
1111
1111
1111
####
####
####
####
####
####

Buffers 2 and 3 need to always live somewhere else in the # area. There must be some saftey space/gap between buffers such that scrolling one buffer (if you scroll them individually, and not all 3 at the same time) does not overlap/Trash into the other nearby one.

[ross]

Originally Posted by aros-sg

After bob restoring you have 2 clean buffers and for the next frame depending on the next y scroll position you choose which one of this 2 buffers will become the next display buffer (= current backbuffer where to paint bobs) (the one which does not wrap). The other becomes the restore buffer for restoring job in the frame after.

I was referring to this.

Of course it's not a bad thing per se, on the contrary!
It is simply because you are forced to use this technique and not others, this could be more expensive in certain situations/conditions.

If in any case that was the main rendering choice, nothing would change in terms of speed