English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 05 January 2015, 22:41   #1
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,225
Parallax scrolling layer with sprites possible?

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):
Click image for larger version

Name:	back.png
Views:	451
Size:	5.7 KB
ID:	42687
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.
phx is offline  
Old 05 January 2015, 22:49   #2
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 05 January 2015, 23:39   #3
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,225
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
phx is offline  
Old 06 January 2015, 00:12   #4
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
that shouldn't make it impossible, you can still blit a single plane even if they are interleaved.
Mrs Beanbag is offline  
Old 06 January 2015, 02:44   #5
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 293
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.
mc6809e is offline  
Old 06 January 2015, 04:41   #6
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,150
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.
Codetapper is offline  
Old 07 January 2015, 11:52   #7
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,225
Quote:
Originally Posted by Codetapper View Post
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?

Quote:
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.

Quote:
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.

Quote:
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...
phx is offline  
Old 07 January 2015, 13:00   #8
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by phx View Post
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.
Mrs Beanbag is offline  
Old 07 January 2015, 22:56   #9
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,150
Quote:
Originally Posted by phx View Post
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).

Quote:
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).

Quote:
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.

Quote:
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.
Codetapper is offline  
Old 08 January 2015, 06:14   #10
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 293
Quote:
Originally Posted by Codetapper View Post
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).
mc6809e is offline  
Old 08 January 2015, 07:01   #11
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 44
Posts: 1,134
Send a message via Yahoo to 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?
Samurai_Crow is online now  
Old 08 January 2015, 09:28   #12
mc6809e
Registered User
 
Join Date: Jan 2012
Location: USA
Posts: 293
Quote:
Originally Posted by Samurai_Crow View Post
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.
mc6809e is offline  
Old 08 January 2015, 16:49   #13
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,225
Quote:
Originally Posted by Codetapper View Post
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.

Quote:
Originally Posted by mc6809e View Post
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.

Quote:
Originally Posted by Codetapper View Post
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.


Quote:
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.
phx is offline  
Old 08 January 2015, 20:51   #14
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
[ Show youtube player ]
Mrs Beanbag is offline  
Old 09 January 2015, 15:26   #15
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,225
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.
phx is offline  
Old 09 January 2015, 15:49   #16
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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?
Mrs Beanbag is offline  
Old 09 January 2015, 16:44   #17
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,225
Quote:
Originally Posted by Mrs Beanbag View Post
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.
phx is offline  
Old 10 January 2015, 12:45   #18
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by phx View Post
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.
Mrs Beanbag is offline  
Old 11 January 2015, 18:58   #19
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,225
Quote:
Originally Posted by Mrs Beanbag View Post
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.

Quote:
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.
phx is offline  
Old 11 January 2015, 19:13   #20
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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
Mrs Beanbag is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
UAE Scripting Layer FrodeSolheim support.FS-UAE 15 26 January 2014 16:56
increase 1 layer size without affecting the rest turrican3 support.WinUAE 3 23 September 2013 02:01
Lionheart Parallax question trydowave Retrogaming General Discussion 9 02 June 2011 17:21
Parallax scrolling meant nothing to me until... killergorilla Amiga scene 26 12 February 2006 17:40
Parallax scrolling in DPaint (tutorial) Stein Retrogaming General Discussion 2 17 January 2006 23:18

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09145 seconds with 14 queries