24 June 2022, 17:01 | #1 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
5 bitplane image with 16 colour non-repeat hw sprites?
Hi all,
Before I attempt this I'd just like to ask if it's even do-able (I may attempt it anyway). Taking the image I've attached it is in 32 colours, however I want to apply some parallax where the sky is used by 16 colour hardware sprites in a non-repeating pattern, the house in the foreground would then scroll downwards... very little would be going on. Would I have enough DMA time to achieve something like this on a stock OCS or would the bitplane DMA take priority from the HW sprites and not give me enough time? Ta, Graeme |
24 June 2022, 17:24 | #2 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,039
|
Bitplane DMA is not a problem since you don't use overscan. But you won't be able to reload all sprite data within 64 pixels (4*16, attached 16col sprites), that's 8*3 words (1 for horizontal position, 2 for data) => 24*8 = 192 pixels, assuming 1-4 bitplanes.
|
24 June 2022, 18:09 | #3 | |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
Quote:
A vertical scroll speed/distance of 50 pixels per second is pretty high for something like that, so at the end you may end up going to slow down to 25 pixels per second anyway. Then you could also just do the parallax in software ... |
|
24 June 2022, 18:32 | #4 | ||
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
Quote:
(even if in fact what mcgeezer wants to do cannot be done ) @a/b: true, but you can start reload data/b/pos immediately after first sprite display, so you can 'delay the problem'. Basically you can set the CWAIT after first sprite display end, and from here write new data in sprite display order. At some point the beam surpasses you but then you can do an x-gap and display something more at some distance. Well, not that you can gain in fact much pixels.. @aros-sg: you can do an hardware scroll changing only bitplane pointers. |
||
24 June 2022, 18:41 | #5 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
No, it's just as said that at the end he may end up slowing the scrolling down anyway, because 50 pixels per second may look too fast. And if so, there is no visual difference between software parallax at 25 fps and hardware parallax at 25 fps. It would look 100 % identical.
Almost every classic vertical shooter on real arcade machines and elsewhere scrolls at 25 vertical pixels per second or less, because otherwise you move through the level/map much too fast. 25 fps vertical scrolling looks smooth. |
24 June 2022, 18:53 | #6 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
But we don't know the speed at which mcgeezer wants to do it, it could also be accelerating. |
|
24 June 2022, 19:16 | #7 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,039
|
|
24 June 2022, 19:47 | #8 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,098
|
Maybe dual playfield mode (2x3 BPL) could be used with sprites adding detail to the temple since the clouds only seem to use about 8 colors. Would likely require quite a bit of both coding and graphics work, so probably not worth it.
|
24 June 2022, 20:00 | #9 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
To clarify, I would expect the background hardware sprites containing the dark blue sky to be static, while the foreground would vertical scroll only (at 50fps) by updating the bitplane pointers. However it looks like it may not be possible due to not having enough DMA slots, i'll have a re-think and consider just doing it all in software with double buffering. Thanks guys. |
|
25 June 2022, 15:13 | #10 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,209
|
If it's just vertical scrolling, you can easily calculate the large areas of the foreground that can be blitted with D=A blit... only the edge areas would need proper masking.
In De Profundis, I am doing a pretty similar thing in the intro (but left to right scrolling), and that is running at 25fps.. but because we scroll so slowly we can get away with the half frame rate. |
25 June 2022, 19:06 | #11 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
So here it is... just pretty much raw blitting the entire scene. I guess for all you go faster stripe Amiga owners you'll get a more smooth transition.
[ Show youtube player ] Last edited by mcgeezer; 25 June 2022 at 19:17. |
25 June 2022, 19:46 | #12 |
Registered User
Join Date: Jun 2016
Location: europe
Posts: 1,039
|
It's a matter of preference how hard you want to minmax this, I guess...
I'd split the temple into 16x16 blocks, edge blocks would be copied with a cookie cutter d=ac+b!c (don't need a mask for the entire picture, only specific blocks), inner blocks (merged horizontally into a single blit) straight up d=a, and blitter nasty turned on. Bottom part (wall) I'd do with a copper split, no need to blit that. If it's fast enough to run at 50fps, blit ahead of raster beam and avoid double buffering. |
25 June 2022, 19:57 | #13 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
|
|
25 June 2022, 21:11 | #14 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 839
|
I'm not sure what limitations that have to be honoured, but somehow that seems very possible for 50fps if the background is 16c.
First order of the day would be to make sure only blitting 4 bitplanes for the background. I guess you could order them so it could be done with 2 blits? Second would be to use the hw sprites on the far left and far right for 64+64 pixels (I think there would be enough cycles for that?). Alternatively map it out so you use hw sprites where the fg and bg would force a 4 channel blit. Third, split the blits into copy and cookie-blit parts. I'm sure you could cheat a bit and do like demos do; pre-calc all the blitter values for each frame so you don't need to spend time on that. Maybe even use the cpu for data copy if the blitter is skipping cycles on copy operations. |
25 June 2022, 21:13 | #15 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,209
|
|
25 June 2022, 22:05 | #16 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
I disagree that this could be done at 50 frames under the circumstances, even halving the current blit size isn't getting me near to 1 frame on an A500. Thanks Dan. |
|
26 June 2022, 07:38 | #17 |
Registered User
Join Date: Nov 2015
Location: Italy
Posts: 191
|
|
26 June 2022, 08:10 | #18 |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 8,986
|
Looks great
|
26 June 2022, 12:08 | #19 | |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,770
|
Quote:
ps: Lovely thread with lots of interesting ideas. Missed these kind of discussions a bit lately, since this is what makes the Amiga so special. So many ways to skin a cat. |
|
26 June 2022, 15:01 | #20 | ||
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Quote:
|
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Can you use 1 bitplane anims to modify 6th bitplane only | ImmortalA1000 | Coders. Blitz Basic | 0 | 18 December 2021 11:55 |
Sam Raw, Why does it repeat?? | volvo_0ne | Coders. AMOS | 2 | 09 February 2018 20:41 |
Using SSCAN2 & SH10 register to repeat sprites horizontally in Blitz2 | leathered | Coders. Blitz Basic | 1 | 03 June 2014 19:29 |
Can amiblitz (blitz basic2) blit an image per bitplane? | Michael Parent | Coders. General | 7 | 29 October 2009 17:59 |
key repeat rate | dbain21 | support.WinUAE | 0 | 02 March 2003 14:35 |
|
|