Re-using AGA sprites on the same scanline?

[mcgeezer]

Hi,

In this post here Toni references that AGA sprites can be re-used on the same scan line.

"Sprite can appear twice in same horizontal scanline without using copper tricks. (Side-effect of a bit hacky scan doubling implementation, very limited but can be used for some background sprite effects)"

Does anyone (including Toni) have any further info on how to exploit this as I'm keen on using some sprites for a background effect.

Geezer

[ross]

Hi Graeme, you need to set SSCAN2 (bit 15) on FMODE.
Then when you set SH10 (bit7) in SPRxPOS, horizontal coincidence detection is for both x positions (SH10 = 0 or 1).

[mcgeezer]

Originally Posted by ross

Hi Graeme, you need to set SSCAN2 (bit 15) on FMODE.
Then when you set SH10 (bit7) in SPRxPOS, horizontal coincidence detection is for both x positions (SH10 = 0 or 1).

Thanks Ross, I'll give it a shot tonight.

[timg]

Interesting... am I reading this correctly in that SH10 would effectively be both on and off at the same time? If so I guess the sprites are always going to be a set distance apart?

[Tigerskunk]

Yeah, keep us updated...

[ross]

I give an example, I probably answered hastily.

Suppose you set a sprite with SPRxPOS=$2c40 in a default DIW value low-res screen.
A sprite at top/left corner appear.
If you also set FMODE=$800x then sprite is doubled, on the same lines, at $40+$80 (so spaced away by 256 pixels).

And if you set SPRxPOS>=$2c80?
Well, test for yourself, but the effect is interesting

[timg]

If it's 256 pixels apart that could work for me... going to have a play with that!

[timg]

It works!

Not the most exciting example, but the white lines here are 64px wide sprites, which are then duplicated in the purple border off to the right.

[mcgeezer]

Same here...

Although I'm getting some strange results when I play with the upper sprites....

Sprites 1+2 are attached and repeated 64px wide sprites
Sprites 3+4 are attached and repeated 64px wide sprites.

Sprites above that seem to scan double... very weird.

[timg]

Are the lower (green masked) characters being duplicated with SSCAN2? I was thinking it had to be on the same line?

[mcgeezer]

Originally Posted by timg

Are the lower (green masked) characters being duplicated with SSCAN2? I was thinking it had to be on the same line?

No, those are just bobs.

(sorry should have mentioned that).

[timg]

Ah OK, that makes more sense!

Unless I'm missing something the downside of this is that it seems it's an all or nothing thing... I don't think you can repeat 4*64px sprites across the screen, but have other sprites not repeating within the same horizontal band of the screen. (not sure if I've explained that clearly!)

[mcgeezer]

Originally Posted by timg

Ah OK, that makes more sense!

Unless I'm missing something the downside of this is that it seems it's an all or nothing thing... I don't think you can repeat 4*64px sprites across the screen, but have other sprites not repeating within the same horizontal band of the screen. (not sure if I've explained that clearly!)

No, I know what you mean (I think).

The thought occurs though that you can have a very nice full screen repeating background (256px wide).

You would be limited on colours if using scrolling because in my example I'm having to lose 3 sprites due to DDFSTRT.

I wonder how they did this in Flink, apparently it uses the same technique.

[DanScott]

Flinks background layer appears to repeat every 128 pixels by the look of it, so they are probably just re-arming SPRxPOS with the copper to repeat the sprite data

Beautiful looking game is Flink, but don't know why they let the background parallax appear behind the status panel at the top.. it just looks very odd to me

[ross]

Flink does not use SSCAN2.
FMODE fetches = x4 for sprites and x2 for bpls, DDFSTRT=$30, DIW = $91 to $b1, sprites repeated with the usual copper x-multiplexing.

[mcgeezer]

Originally Posted by ross

Flink does not use SSCAN2.
FMODE fetches = x4 for sprites and x2 for bpls, DDFSTRT=$30, DIW = $91 to $b1, sprites repeated with the usual copper x-multiplexing.

Then bull shit is what I read somewhere else.

[ross]

Originally Posted by mcgeezer

Then bull shit is what I read somewhere else.

If you want a game that use SSCAN2 with a 256px sprites repeated background look for Fantastic Dizzy AGA.
FMODE fetches like Flink, but DDFSTRT=$38, DIW = $a1 to $1a1, all 8 sprites used for the background (4x64x16colors).

[timg]

Originally Posted by mcgeezer

The thought occurs though that you can have a very nice full screen repeating background (256px wide).

You would be limited on colours if using scrolling because in my example I'm having to lose 3 sprites due to DDFSTRT.

That's exactly what I was thinking too...

Originally Posted by mcgeezer

I wonder how they did this in Flink, apparently it uses the same technique.

How have I not heard of Flink before?!?! That's got some seriously nice pixel art.

Originally Posted by DanScott

Flinks background layer appears to repeat every 128 pixels by the look of it, so they are probably just re-arming SPRxPOS with the copper to repeat the sprite data

They are still managing to scroll the background vertically, I thought that would be quite time consuming with x-multiplexing... would you have to update every row individually?

Originally Posted by DanScott

Beautiful looking game is Flink, but don't know why they let the background parallax appear behind the status panel at the top.. it just looks very odd to me

Very true. Does make the play area look larger when you're outside though.

[Tigerskunk]

Originally Posted by timg

They are still managing to scroll the background vertically, I thought that would be quite time consuming with x-multiplexing... would you have to update every row individually?

They just need to update the pointer to the sprites start.
Compared to the rest that you need to take care of in x-multiplexing for a bg scroll layer this is not complicated.

[timg]

Originally Posted by Steril707

They just need to update the pointer to the sprites start.
Compared to the rest that you need to take care of in x-multiplexing for a bg scroll layer this is not complicated.

Ah, is that for a whole screen... I've been thinking of mixing layers of sprites with bitplane parallax layers and scrolling those vertically which does make the copperlist more complex.