05 January 2015, 21:41 | #1 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
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): 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. |
05 January 2015, 21:49 | #2 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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. |
05 January 2015, 22:39 | #3 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
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 |
05 January 2015, 23:12 | #4 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
that shouldn't make it impossible, you can still blit a single plane even if they are interleaved.
|
06 January 2015, 01:44 | #5 |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 374
|
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. |
06 January 2015, 03:41 | #6 |
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,188
|
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. |
07 January 2015, 10:52 | #7 | ||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
Quote:
Quote:
Quote:
Quote:
|
||||
07 January 2015, 12:00 | #8 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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.
|
07 January 2015, 21:56 | #9 | ||||
2 contact me: email only!
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,188
|
Quote:
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:
Quote:
Quote:
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. |
||||
08 January 2015, 05:14 | #10 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 374
|
Quote:
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). |
|
08 January 2015, 06:01 | #11 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,224
|
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?
|
08 January 2015, 08:28 | #12 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 374
|
Quote:
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. |
|
08 January 2015, 15:49 | #13 | ||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
Quote:
Quote:
Quote:
Quote:
|
||||
08 January 2015, 19:51 | #14 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
[ Show youtube player ]
|
09 January 2015, 14:26 | #15 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
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. |
09 January 2015, 14:49 | #16 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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? |
09 January 2015, 15:44 | #17 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
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.
|
10 January 2015, 11:45 | #18 | |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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. |
|
11 January 2015, 17:58 | #19 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,574
|
Quote:
Quote:
|
||
11 January 2015, 18:13 | #20 |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
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
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Lionheart Parallax question | trydowave | Retrogaming General Discussion | 19 | 03 February 2020 08:24 |
UAE Scripting Layer | FrodeSolheim | support.FS-UAE | 15 | 26 January 2014 15:56 |
increase 1 layer size without affecting the rest | turrican3 | support.WinUAE | 3 | 23 September 2013 01:01 |
Parallax scrolling meant nothing to me until... | killergorilla | Amiga scene | 26 | 12 February 2006 16:40 |
Parallax scrolling in DPaint (tutorial) | Stein | Retrogaming General Discussion | 2 | 17 January 2006 22:18 |
|
|