5 bitplane image with 16 colour non-repeat hw sprites?

[mcgeezer]

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

[a/b]

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.

[aros-sg]

Originally Posted by mcgeezer

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.

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

[ross]

Originally Posted by a/b

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.

Originally Posted by aros-sg

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

Wait, too much pessimism here
(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.

[aros-sg]

Originally Posted by ross

Wait, too much pessimism here

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.

[ross]

Originally Posted by aros-sg

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.

Ah, ok, sorry, you know very well how to do hardware scrolling and I had to understand that you meant something else..
But we don't know the speed at which mcgeezer wants to do it, it could also be accelerating.

[a/b]

Originally Posted by ross

Well, not that you can gain in fact much pixels..

Yeah, attached not only cuts your available time in half, it's also detrimental to staggered reloads because you need both paired sprites to be available at the same time, you reach the threshold sooner.

[paraj]

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.

[mcgeezer]

Originally Posted by ross

Ah, ok, sorry, you know very well how to do hardware scrolling and I had to understand that you meant something else..
But we don't know the speed at which mcgeezer wants to do it, it could also be accelerating.

Thanks everyone for the responses, all very much appreciated.

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.

[DanScott]

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.

[mcgeezer]

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 ]

[a/b]

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.

[mcgeezer]

Originally Posted by a/b

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.

Yeah, given what it is does for such a small part of the game I'm inclined to just leave it as is... if I get time I can improve the speed of it but I'm more happy with the text processor.

[NorthWay]

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.

[DanScott]

Originally Posted by mcgeezer

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 ]

Looks great!!! No need to spend more time on it

[mcgeezer]

Originally Posted by NorthWay

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.

The background sky is on 8 colours. hardware sprites would only give me 64 pixels at 16 colours, the foreground is 32 colours. The blitter is fully cookie cutting the entire scene - just for simplicity.

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.

Originally Posted by DanScott

Looks great!!! No need to spend more time on it

Thanks Dan.

[aros-sg]

Originally Posted by mcgeezer

The background sky is on 8 colours.

Btw, if you are cookie-cutting-blit the background through inverted building mask it's can be done with 3 plane blit only.


Btw, what happened to the black trees? Too annoying when creating mask? ;-)

[Galahad/FLT]

Looks great

[Tigerskunk]

Originally Posted by mcgeezer

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 ]

It's perfect already. Just leave it the way it is now. No need to complicate things when you already have this result in your pocket, mate...

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.

[mcgeezer]

Originally Posted by aros-sg

Btw, if you are cookie-cutting-blit the
Btw, what happened to the black trees? Too annoying when creating mask? ;-)

I totally didn't realise I lost the trees, thanks for pointing that out. I'll fix it.

Originally Posted by Galahad/FLT

Looks great

Originally Posted by Tigerskunk

It's perfect already. Just leave it the way it is now. No need to complicate things when you already have this result in your pocket, mate...

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.

Thanks gents