Free Form Sprite Layer example + source

[roondar]

Ever since reading the article on Risky Woods over at codetapper.com, I've wanted to try to create a different sprite layer. After some experimentation, I've succeeded in creating a copper list that allows for a 'Free Form' sprite background, which is to say one without any need for repeating patterns. While the DMA cost is high (the copper list is 'kinda big' ), it does allow a basic OCS/ECS machine to display a two layered 'Dual Playfield like' display with a 15 colour and a 4 colour layer.

I'm not sure how useful it is (considering the DMA & memory cost) - or if it was already known/used elsewhere - but I liked the effect a lot anyway so I made a YouTube video and wrote an article about it showing how it's done.

I've also included the full source code for those interested, and if you like it - please use it as you see fit (note that the tiles I used are ripped from Turrican II and the startup code is by Photon of Scoopex).

Hope you guys find it useful or neat.

The article/source can be found here:
http://powerprograms.nl/amiga/spr-layer.html

Here's the video:
[ Show youtube player ]

[ross]

Great 'racing the beam'

+1 for the article, source and video.

Yes, a bit expensive on DMA and memory

Cheers.

[NorthWay]

About doing it with the blitter instead; for a general masked copy (basically a cookie-cut) you nearly run out of cycles in a single frame. (Assuming only updating 2 bitplanes.)

The interesting thing would be if it is possible to do in 32 colours too? If not, what if you use a narrower display?

[Leffmann]

If you had shown this on an A500 in 1987, people might not have believed it. Very good demonstration of pushing the hardware to its limits!

[ross]

Originally Posted by NorthWay

The interesting thing would be if it is possible to do in 32 colours too? If not, what if you use a narrower display?

There is not enough DMA available for a 32 colours FG. Narrowing the display could work but how tight would become? Probably too much for every game..

Well, potentially you could make a totally free 3+3+3 colours 3 playfields (FG/BG/SP) game

Next step for this effect: make a full screen sprites plane full animated (like Apydia one) but free form.

[ovale]

Great work and article. Thanks for sharing.

[roondar]

Originally Posted by NorthWay

About doing it with the blitter instead; for a general masked copy (basically a cookie-cut) you nearly run out of cycles in a single frame. (Assuming only updating 2 bitplanes.)

Well, that's kind of what I figured. I might still experiment just for fun though, maybe some clever trick can be used.

Originally Posted by ross

There is not enough DMA available for a 32 colours FG. Narrowing the display could work but how tight would become? Probably too much for every game..

Well, wonder no more

A 5 bitplane screenmode gets you one extra sprite drawn every 36 pixels (instead of the 4 bitplane screenmode's 24 pixels). Essentially, the maximum width you can then generate comes to 192 pixels* for a static layer or 176 pixels for a scrolling layer.

So no, it's sadly not really viable at 5 bitplanes.

*) 128/36 = 3 extra sprites, during which you can manage one more sprite = 128 + 4*16 = 192.

Next step for this effect: make a full screen sprites plane full animated (like Apydia one) but free form.

Right, well - I'm actually vaguely confident you could do that. It's just that you won't have enough raster time to actually do anything else of note at that point

[roondar]

A small, but sad, update.

Yesterday, I tried creating an AGA version of the above using 16 colour sprites.

The idea being that I'd use the first 8 channels in the AGA 64 pixel wide sprite mode (attached - so covering 256 pixels) and then fill the remaining pixels using 16 pixel wide (again attached) sprites. This switch between 64/16 pixel sprites would be needed because the Copper cannot reload the data of 64 pixel sprites

To do so, I dynamically set the FMODE register to 64 bit sprites for the first part of the scanline and then to 16 bit sprites for the remainder. On WinUAE, this actually works.

Sadly, on my real A1200, it doesn't work

It actually acts rather strangely - instead of resetting the sprites to 16 pixels, it resets them to 32 pixels instead (which is useless as 32 pixel sprites can't be reloaded using the copper either as I understand it). However, that's not all - changing the FMODE register mid-scanline causes a 16 pixel gap to appear in the middle of sprites at the point where FMODE register is changed.

Considering the Copper isn't faster on AGA (and thus can't update 16 colour sprites quickly enough if they're only 16 pixels wide), this unfortunately means that a 16 colour free-form sprite background isn't possible, even using AGA.

[ross]

Hi roondar, can you try without 32bit mode but only double CAS? (FMODE=B then FMODE=3).
Yes, you can cover only 128bit but it's just to help Toni to make a precise AGA emulation (seems that the fetch do not change between 32 to 16 bit..).

[Toni Wilen]

Could you attach test executable? I'd like update emulation to handle this special case. (It does not matter if it is totally unusable situation!)

[roondar]

Originally Posted by Ross

Hi roondar, can you try without 32bit mode but only double CAS? (FMODE=B then FMODE=3).
Yes, you can cover only 128bit but it's just to help Toni to make a precise AGA emulation (seems that the fetch do not change between 32 to 16 bit..).

I'm sure I could do that, though testing it on real hardware is a bit of a pain (my A1200 is only set up when I need it and I put it back in storage after the test yesterday ).

Originally Posted by Toni Wilen

Could you attach test executable? I'd like update emulation to handle this special case. (It does not matter if it is totally unusable situation!)

I don't have the executable here, so it'll have to wait a bit (I'll try to get it done tonight, no guarantees though). But sure, I can attach the executable for you.

If you want I can also attach the source code (though that'll be quite messy - the test was a minor change based on my original OCS code with alot of stuff commented out etc).

[Tigerskunk]

Amazing stuff... Thanks, Roondar...

Just a question, though:

you wrote:

Sprite layer effect costs
A standard sprite layer (224 pixels high) costs 8736 DMA cycles.
A 'Risky Woods' sprite layer (224 pixels high) costs 16800 DMA cycles.
A 'Risky Woods' sprite layer (176 pixels high) costs 13200 DMA cycles.

A static Free Form sprite layer (224 pixels high) costs 19040 DMA cycles.
A scrolling Free Form sprite layer (224 pixels high) costs 21728 DMA cycles.
A scrolling Free Form sprite layer (176 pixels high) costs 17072 DMA cycles.

What are the differences between a standard sprite layer and a "risky woods"
one?

Number of 32x32 bobs shown per frame
Normal screen (no effects): 50320/2304=21*0.9=19 bobs
Standard sprite layer: 46736-8736=38000 DMA cycles => 38000/2304=16*0.9=14 bobs
'Risky Woods' sprite layer: 52240-16800=29936 DMA cycles => 29936/2304=12*0.9=11 bobs
'Risky Woods' actual game screen: 47696-13200=34496 DMA cycles => 34496/2304=14*0.9=13 bobs

Static Free Form sprite layer: 46736-19040=27696 DMA cycles => 27696/2304=12*0.9=10 bobs
Scrolling Free Form sprite layer: 46736-21728=25008 DMA cycles => 25008/2304=10*0.9=9 bobs
Scrolling Free Form sprite layer (smaller screen): 47696-17072=32352 DMA cycles => 32352/2304=14*0.9=12 bobs

I wonder if my BOB routine is just superbad, or if I am missing something here...
19 32x32x5 BOBs seems to be a bit high of a BOB count here to me, even with triple buffering. I get around 14 with that method.

Care to explain what you might be doing different here?

[Toni Wilen]

Originally Posted by roondar

I don't have the executable here, so it'll have to wait a bit (I'll try to get it done tonight, no guarantees though). But sure, I can attach the executable for you.

If you want I can also attach the source code (though that'll be quite messy - the test was a minor change based on my original OCS code with alot of stuff commented out etc).

Executable that shows the "problem" is fine. I'll write my own test later, I only want confirmed test case first.

[roondar]

Originally Posted by Steril707

Amazing stuff... Thanks, Roondar...
What are the differences between a standard sprite layer and a "risky woods" one?

A standard sprite layer uses 3 colour non-attached sprites and can be up to 128 pixels wide. A "Risky Woods sprite layer" uses 15 colour attached sprites and can be 64 pixels wide.

I wonder if my BOB routine is just superbad, or if I am missing something here...
19 32x32x5 BOBs seems to be a bit high of a BOB count here to me, even with triple buffering. I get around 14 with that method.

Care to explain what you might be doing different here?

Well, mostly I calculated the number for a screen using 4 bitplanes rather than 5 (because, well, this effect only works up to 4 bitplanes) and then it suddenly becomes much more possible to do 19

Originally Posted by Toni Wilen

Executable that shows the "problem" is fine. I'll write my own test later, I only want confirmed test case first.

No problem, it's attached to this post.

[Tigerskunk]

Originally Posted by roondar

A standard sprite layer uses 3 colour non-attached sprites and can be up to 128 pixels wide. A "Risky Woods sprite layer" uses 15 colour attached sprites and can be 64 pixels wide.

Okay, I guessed that.
Why do the attached Sprites take double DMA time, though, I wonder...
Isn't it the same amount of sprite-positions that I need to rewrite riding the beam?

Originally Posted by roondar

Well, mostly I calculated the number for a screen using 4 bitplanes rather than 5 (because, well, this effect only works up to 4 bitplanes) and then it suddenly becomes much more possible to do 19

Yeah, sorry, I meant 4 planes, off course...
19 sounds like a loooooot of BOBs to me in one frame. Even with triple buffering.

[roondar]

Originally Posted by Steril707

Okay, I guessed that.
Why do the attached Sprites take double DMA time, though, I wonder...
Isn't it the same amount of sprite-positions that I need to rewrite riding the beam?

No, you'd need to reposition twice the amount (16 pixels are covered by two sprites when attached, rather than just one). So a 288 pixel screen would take 18 non-attached sprites, but 36 attached ones.

Yeah, sorry, I meant 4 planes, off course...
19 sounds like a loooooot of BOBs to me in one frame. Even with triple buffering.

If you have game mechanics, sprites, music, etc, then yes - 19 is a lot.

However, if you're just doing an up and down weave like my example does, it's definitely possible. As an example, I've ripped the background layer out of my example (bobs are still fully cookie-cut tripple buffered ones) and upped the number of bobs until no more would fit in a frame.

Turns out it can manage 20 of them while still updating the foreground scrolling data and running at 50Hz on an A500. I'm reasonably sure you'd be able to do 21 if no tiles need to be updated.

I've attached the modified program below so you can see it for yourself, always nicer than me saying stuff

--
Do note that my program does use a 288x240 pixel screen (+16 pixels fetched for scrolling). A 320x256 scrolling screen will lose about two bobs in a frame.

[Toni Wilen]

I did some quick tests and noticed that Lisa decides sprite size when SPRxDAT gets loaded, not when FMODE is changed.

Change FMODE=0, then write to SPRxDATA (and also B if B also had non-zero data at 32-> pixels previously) with copper and sprite becomes 16-pixel wide even if in current line it was already shown as 32 or 64 wide.

[ross]

Originally Posted by Toni Wilen

I did some quick tests and noticed that Lisa decides sprite size when SPRxDAT gets loaded, not when FMODE is changed.

Change FMODE=0, then write to SPRxDATA (and also B if B also had non-zero data at 32-> pixels previously) with copper and sprite becomes 16-pixel wide even if in current line it was already shown as 32 or 64 wide.

This is a good news because with a proper copper shuffle a 15 colors free form sprites background on AGA is probably possible.

But I'm not sure I understood the part in brackets..
SPRBDATA in not mandatory anyway to write it together with A?
(well, apart from the unlikely event you want to keep valid the lower 16 bits)
Or I miss something?

[Toni Wilen]

Originally Posted by ross

But I'm not sure I understood the part in brackets..
SPRBDATA in not mandatory anyway to write it together with A?
(well, apart from the unlikely event you want to keep valid the lower 16 bits)
Or I miss something?

I added it just before posting and it didn't become very clear.. If A or B has previous sprite's pixel data at pixel positions 16+ and you don't want it to be visible anymore, register needs to be written after FMODE change or old data is visible each time same sprite is shown in same scan line.

Again undocumented rare feature that makes emulation more complex.. Size was global setting but size is actually sprite plane specific (in hardware level it obviously simply selects which part of internal 64-bit register gets loaded and which gets cleared but in emulation it would not be optimal to emulate it all the time as 64-bit when wide sprites are rarely used)

It is possible bitplanes also work identically.

[ross]

ok thanks.