Parallax scrolling layer with sprites possible?

[phx]

Yes, of course it is possible, as explained on Codetapper's sprite tricks page (http://www.codetapper.com/amiga/sprite-tricks/).

But I'm not sure if it would be possible in my current game project, as repositioning the sprites needs a lot of Copper DMA, which may only be available up to a maximum of four bitplanes.

The game imposes the following restrictions:
- 320x240 display window
- five bitplanes, all colours are used
- early DDFSTRT to enable hardware scrolling, i.e. the last sprite's DMA channel is not available
- OCS system

On the positive side I have lots of free processing time. The whole (finished) game is running in below 50 raster lines per frame. The game doesn't use any sprites yet.

I would like to create a background parallax layer on the bottom of the screen with a height below 100 pixels, which looks like this (minus the greenish copper background):

Three-colour trees would be nice, but a single colour (black) is sufficient.

Is that possible to do? What would be the best approach? I fear that there are no sufficient DMA slots available for sprite repositioning. Writing SPRDAT (single colour sprite) is also no option, as scrolling needs too much time to update.

Maybe I don't have to fill the whole 320 pixels with sprites, but there may be gaps between the trees...

In any case the background layer should scroll at half speed of the game's bitmap.

[Mrs Beanbag]

it sounds to me that you could do it the way Flimbo's Quest did it. we were discussing that here a few weeks ago: http://eab.abime.net/showthread.php?t=76158

if your background is only using 1 or 2 bitplanes there should easily be enough time to do the blit.

[phx]

Ah yes, I remember that thread. Could be an alternative, to do it without sprites.

But as far as I understood Flimbo's Quest was using a single plane mask, and then blits the five background planes one by one using this mask. That's not possible for me, as I forgot to mention another restriction:

- game is using interleaved bitplanes

[Mrs Beanbag]

that shouldn't make it impossible, you can still blit a single plane even if they are interleaved.

[mc6809e]

If you're willing to accept some repetitiveness in the graphics you can try a tile based approach using the sprites.

Just use the copper to change only SPRxPOS to reuse a sprite.

This method gives you seven or eight 16 pixel wide tiles.

And with tiles you can mix things up as you scroll things along.

[Codetapper]

It's not possible to update the SPRxDAT register and reposition it across the screen with 5 bitplanes. With 4 planes it definitely works.

With 5 planes, you're racing the beam and after about 4 or 5 sprites wide it will skip with a single colour sprite (and this technique only works if you're using 2 sprites, for example updating SPR6DAT and SPR7DAT in between repositioning). That gives you a little more breathing room as you can pre-load one of the sprites.

The problem with the 'gaps in the trees' approach is that if it's scrolling, sometimes the gap will be near the far left of the screen.

My thoughts are you have 3 options (and based on what you've said, I would use option 1):

1. As you draw the tiles for the screen, build up a mask in another area of memory containing the parts of the background that are see-through. Then simply blit the entire tree background (1 or 2 blits, if you can get away with it) to get your 1 or 3 colour background.

2. Use the 'Jim Power' approach and have a simpler 32 pixel wide repeating pattern for the background.

3. Opt for a static background made of sprites that does not scroll at all, so you can have a reasonably detailed pre-calculated background and gaps in differing places for the trees.

[phx]

Originally Posted by Codetapper

It's not possible to update the SPRxDAT register and reposition it across the screen with 5 bitplanes.

Yes, that's what I feared. Is it also impossible to update SPRxPOS instead, and repeating a pattern of 6 or 7 sprites, like mc6809e suggested?

1. As you draw the tiles for the screen, build up a mask in another area of memory containing the parts of the background that are see-through. Then simply blit the entire tree background (1 or 2 blits, if you can get away with it) to get your 1 or 3 colour background.

Hmm, ok, I would have to rearrange my colour palette that a single plane shows the tree colour. Might be possible, even with interleaved planes. Although I would still prefer a sprite-based solution.

2. Use the 'Jim Power' approach and have a simpler 32 pixel wide repeating pattern for the background.

No. This would be too much repetitiveness.

3. Opt for a static background made of sprites that does not scroll at all, so you can have a reasonably detailed pre-calculated background and gaps in differing places for the trees.

Maybe this is an alternative. A static background also provides a parallax effect. The question is which technique provides the most sprites, SPRDAT with two sprites? Multiplexing all sprites (but then I have to use 6 attached sprites) by writing SPRxPOS? I would probably try the latter...

[Mrs Beanbag]

Originally Posted by phx

Hmm, ok, I would have to rearrange my colour palette that a single plane shows the tree colour. Might be possible, even with interleaved planes. Although I would still prefer a sprite-based solution.

It won't make a difference to how possible it is. You won't be able to blit the parallax layer in an interleaved fashion, but it would just be the same as not having interleaved planes but with a different modulo. You could, however, interleave the mask with the planes and still use a single blit for the tiles that blits the tile graphics and mask at the same time.

[Codetapper]

Originally Posted by phx

Yes, that's what I feared. Is it also impossible to update SPRxPOS instead, and repeating a pattern of 6 or 7 sprites, like mc6809e suggested?

If you are using 6 or 7 sprites (and not just sprites 6 and 7) then you'd have to be prepared to have the same colours multiple times in your palette. If you're happy with that, then this would work. If it's a single colour background for the tree (eg. black) then you could use sprites 0-5 and set colour 17, 21 and 25 to black and get a 96 pixel wide pattern with this method.

With a 32 colour screen, you get 3 copperlist entries processed every 32 pixels. So you can do a SPRxPOS-SPRx+1POS-NOP loop to reposition them. (64 colour screen gives 2 copperlist entries, 16 colour screen gives 4 entries).

Hmm, ok, I would have to rearrange my colour palette that a single plane shows the tree colour. Might be possible, even with interleaved planes. Although I would still prefer a sprite-based solution.

Easiest method is make colour 1 your tree colour, then you only need to blit the first plane onto the screen. Interleaved planes or not, it makes no difference. I have used this exact technique to add a 32 pixel high parallax layer in the background of a 32 colour screen by blitting the first 2 planes only and having the parallax layer using colours 1-3 for that section of the screen. 2 masked blits of 320x32 was all that was required (and building up the mask itself as I draw new tiles into the screen).

No. This would be too much repetitiveness.

A good artist might be able to help you here. The parallax doesn't have to differ too much, if there's action happening, any parallax pattern would be better than nothing.

Maybe this is an alternative. A static background also provides a parallax effect. The question is which technique provides the most sprites, SPRDAT with two sprites? Multiplexing all sprites (but then I have to use 6 attached sprites) by writing SPRxPOS? I would probably try the latter...

If you are happy with a 1 or 3 colour static background, you can use the two 3-colour sprites as much as possible and intersperse it with the four attached sprites to get the same colours.

Another trick you can do to fake a bigger background is offset the sprites a little each line to simulate a diagonal (such as a blown over tree) making the parallax layer look a lot wider than it really is.

[mc6809e]

Originally Posted by Codetapper

If you are using 6 or 7 sprites (and not just sprites 6 and 7) then you'd have to be prepared to have the same colours multiple times in your palette. If you're happy with that, then this would work. If it's a single colour background for the tree (eg. black) then you could use sprites 0-5 and set colour 17, 21 and 25 to black and get a 96 pixel wide pattern with this method.

One can do even better by putting the sprites in attached mode, but being careful not to overlap them.

In that case the even sprites get palette entries 17, 18, 19 and the odd sprites get 20, 24, 28 so only two entries would need to be black (17 and 20, for instance).

[Samurai_Crow]

If you only activate the even sprites' DMAs but set the attachment bit and feed zero words into the odd sprites' fetch registers, would that give you 4 sprites with the same 3 palette entries?

[mc6809e]

Originally Posted by Samurai_Crow

If you only activate the even sprites' DMAs but set the attachment bit and feed zero words into the odd sprites' fetch registers, would that give you 4 sprites with the same 3 palette entries?

Yep, but that would happen anyway even if they were overlapped.

I think I see what you're getting at, though. By using attached mode one can reduce the number of palette entries used by sprites in a five bitplane display and so leave more colors available just for playfield graphics.

That's a good point.

[phx]

Originally Posted by Codetapper

If you are using 6 or 7 sprites (and not just sprites 6 and 7) then you'd have to be prepared to have the same colours multiple times in your palette. If you're happy with that, then this would work.

No I'm not. It would be hard to free another colour out of these 32.

Originally Posted by mc6809e

One can do even better by putting the sprites in attached mode, but being careful not to overlap them.

In that case the even sprites get palette entries 17, 18, 19 and the odd sprites get 20, 24, 28 so only two entries would need to be black (17 and 20, for instance).

That's a nice trick! Probably still too expensive for me.

Originally Posted by Codetapper

With a 32 colour screen, you get 3 copperlist entries processed every 32 pixels. So you can do a SPRxPOS-SPRx+1POS-NOP loop to reposition them. (64 colour screen gives 2 copperlist entries, 16 colour screen gives 4 entries).

Ah yes, I understand. Actually that becomes pretty clear from looking into the DMA diagram in the HRM.

Easiest method is make colour 1 your tree colour, then you only need to blit the first plane onto the screen.

You're right. A single plane, or even two planes, could be quick enough. Might be worth considering.

[Mrs Beanbag]

[ Show youtube player ]

[phx]

LOL
No, I didn't ignore you. I am very aware of your contributions.

I hoped for more comments, to avoid a blitter-based solution, though, as there are so many completely unused sprites available. I will probably investigate the sprites options first and keep the blitting as a fallback, when I don't achieve any acceptable results.

[Mrs Beanbag]

yeah i wasn't having a go, i just thought it was funny that your last line was pretty much what i said in the first place.

i know what you mean about sprites going to waste, because they're such potentially useful things, but is there really no other use for them?

[phx]

Originally Posted by Mrs Beanbag

i know what you mean about sprites going to waste, because they're such potentially useful things, but is there really no other use for them?

Maybe I could construct some use. But the game is finished and works very well (and fast) without them. I was just thinking about adding some eye candy with sprites, but without changing anything which is already working.

[Mrs Beanbag]

Originally Posted by phx

Maybe I could construct some use. But the game is finished and works very well (and fast) without them. I was just thinking about adding some eye candy with sprites, but without changing anything which is already working.

surely even the parallax is a "constructed use" in the same way?

obviously i don't know anything about your game but one thing i use sprites for is to build a score/stats panel that floats above the playfield rather than on a separate area above or below.

[phx]

Originally Posted by Mrs Beanbag

surely even the parallax is a "constructed use" in the same way?

I mean, I didn't want to change the inner workings of the game anymore, like taking sprites for objects which are already implemented.

obviously i don't know anything about your game but one thing i use sprites for is to build a score/stats panel that floats above the playfield rather than on a separate area above or below.

Yes. I like to do that too (as in Solid Gold). But this game is a 68k port from an SDL game written in C and it has its scores in a separate area - indeed, below.

[Mrs Beanbag]

oh ok, fair enough... hmm... well you could always do ANOTHER parallax layer with the sprites! Maybe the moon or something, or occasional objects in front of the main layer