English Amiga Board


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

 
 
Thread Tools
Old 23 September 2018, 00:28   #1
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 642
Free Form Sprite Layer example + source

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 ]
roondar is online now  
Old 23 September 2018, 00:43   #2
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,363
Great 'racing the beam'

+1 for the article, source and video.

Yes, a bit expensive on DMA and memory

Cheers.
ross is offline  
Old 23 September 2018, 08:01   #3
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 523
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?
NorthWay is online now  
Old 23 September 2018, 08:31   #4
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,200
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!
Leffmann is offline  
Old 23 September 2018, 09:47   #5
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,363
Quote:
Originally Posted by NorthWay View Post
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.

ross is offline  
Old 23 September 2018, 13:07   #6
ovale
Registered User

 
Join Date: Jun 2014
Location: milan / italy
Posts: 154
Great work and article. Thanks for sharing.
ovale is offline  
Old 23 September 2018, 15:29   #7
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 642
Quote:
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.

Quote:
Originally Posted by ross View Post
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.
Quote:
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 is online now  
Old 24 September 2018, 11:24   #8
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 642
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.
roondar is online now  
Old 24 September 2018, 11:38   #9
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,363
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..).

ross is offline  
Old 24 September 2018, 11:45   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
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!)
Toni Wilen is online now  
Old 24 September 2018, 11:55   #11
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 642
Quote:
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 ).

Quote:
Originally Posted by Toni Wilen View Post
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).
roondar is online now  
Old 24 September 2018, 14:02   #12
Steril707
OCS rocks!

 
Join Date: Sep 2016
Location: Amiga Island
Posts: 507
Amazing stuff... Thanks, Roondar...

Just a question, though:

you wrote:

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

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

Last edited by Steril707; 24 September 2018 at 14:33.
Steril707 is offline  
Old 24 September 2018, 19:44   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by roondar View Post
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.
Toni Wilen is online now  
Old 24 September 2018, 21:48   #14
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 642
Quote:
Originally Posted by Steril707 View Post
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.

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


Quote:
Originally Posted by Toni Wilen View Post
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.
Attached Files
File Type: zip SPR_Layer_AGA.zip (24.5 KB, 23 views)
roondar is online now  
Old 25 September 2018, 14:36   #15
Steril707
OCS rocks!

 
Join Date: Sep 2016
Location: Amiga Island
Posts: 507
Quote:
Originally Posted by roondar View Post
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?

Quote:
Originally Posted by roondar View Post
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.
Steril707 is offline  
Old 25 September 2018, 15:17   #16
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 642
Quote:
Originally Posted by Steril707 View Post
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.

Quote:
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.
Attached Files
File Type: zip BOB_Test.zip (22.9 KB, 26 views)
roondar is online now  
Old 25 September 2018, 22:11   #17
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
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.
Toni Wilen is online now  
Old 25 September 2018, 22:25   #18
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,363
Quote:
Originally Posted by Toni Wilen View Post
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?
ross is offline  
Old 25 September 2018, 22:39   #19
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by ross View Post
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.
Toni Wilen is online now  
Old 25 September 2018, 22:48   #20
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,363
ok thanks.
ross 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
Any way to free sprite 0 (mouse pointer)? StingRay Coders. System 9 19 October 2017 10:43
Parallax scrolling layer with sprites possible? phx Coders. Asm / Hardware 21 12 July 2015 19:15
UAE Scripting Layer FrodeSolheim support.FS-UAE 15 26 January 2014 16:56
Opus Magellan source is free now! OlafSch Amiga scene 5 18 December 2012 17:43
Opus Magellan source is free now OlafSch News 0 18 December 2012 12:34

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 21:20.


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