English Amiga Board


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

 
 
Thread Tools
Old 14 April 2020, 19:55   #21
Nightfox
Registered User

Nightfox's Avatar
 
Join Date: Apr 2016
Location: Perth, Australia
Posts: 238
Quote:
Originally Posted by olleharstedt View Post
Sprite vs blit also has consequences for collision detection.

How so?
Nightfox is offline  
Old 15 April 2020, 10:09   #22
olleharstedt
Registered User

 
Join Date: Mar 2020
Location: Hamburg
Posts: 20
There's hardware support for collision detection between groups of sprites, so that you don't have to loop through all items on each frame to detect it.

http://amigadev.elowar.com/read/ADCD.../node015A.html
olleharstedt is offline  
Old 15 April 2020, 13:19   #23
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,495
Quote:
Originally Posted by Nightfox View Post
Awesome cheers. And if I was to make an AGA version of the game, is 256 colours too much for a 50fps platformer?
I summon @Roondar to make the calculations for you on this topic...

From my gut feeling, I'd say you'd want to avoid using 8 bitplanes for a 50fps game, even on AGA.

And from my experiments and analysis of SNES and NEO GEO games with and for using higher colour counts for game graphics, I'd wager that using 64 to 128 colours is usually enough to achieve that look.
Steril707 is offline  
Old 15 April 2020, 13:48   #24
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 622
Personally I'd us 2 x 16 colour playfields, and try to make use of the 16 attached sprites too
DanScott is offline  
Old 15 April 2020, 14:05   #25
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,962
RE: AGA 256 colour/50FPS games calculations

AGA offers more bandwidth to chipmemory than OCS does, which increases Blitter througput (it runs at the same speed, but gets more time on the bus). However, increasing the number of bitplanes increases the time the Blitter needs to finish blitting and ultimately the extra cycles are not enough to cover the extra bitplanes needed to be drawn. This means that AGA Amiga's using the Blitter will be slower in 8 bitplanes than OCS Amiga's in 5.

Here's some back-of-the-envelope numbers to show what I mean. Note that I'll not be looking at hardware sprites for the numbers, just the Blitter.

Code:
Resolution: 320x256 (effectively 336x256 due to hardware scrolling)
AGA fetches: 4x OCS speed, but 64 pixel aligned
All figures assume there is no game/demo logic

DMA time available (PAL): 70512 DMA cycles
Refresh/audio: up to 2304 DMA cycles
Left: 68208 DMA cycles

OCS bitplane cost@4BPL: (336/16)*256*4= 21504 DMA cycles/ 46704 DMA cycles left
OCS bitplane cost@5BPL: (336/16)*256*5= 26880 DMA cycles/ 41328 DMA cycles left
AGA bitplane cost@8BPL: (336/64)*256*8= 12288 DMA cycles/ 55920 DMA cycles left

BOBs are assumed to use a pristine copy of the background for restoring 
(i.e. three buffer based blitting).
32x32 BOB cost@4BPL: 3*32*6*4=2304 DMA cycles
32x32 BOB cost@5BPL: 3*32*6*6=2880 DMA cycles
32x32 BOB cost@8BPL: 3*32*6*8=4608 DMA cycles

OCS Blitter efficiency: ~90%
AGA Blitter efficiency: ~95%
The above efficiency figures are a rough indication of the time that is lost by
having the CPU set up the Blitter. This is done about twice as fast on AGA
machines, due to the faster processor. Interleaved blitting is assumed here.

BOBs per 320x256 PAL frame:
OCS 4 BPL: 46704/2304*0,9=about 18 bobs
OCS 5 BPL: 41328/2880*0,9=about 12 bobs
AGA 8 BPL: 55920/4608*0,95=about 11 bobs
AGA 16+16 Dual Playfield mode: 55920/2304*0,95=about 23 bobs
Do keep in mind the above will vary based on a few factors and assumes you are running on a chip/slow memory only machine and that your code is not using any CPU time at all apart from blitting. Also note the figures assume no special tricks of any kind (there are several, including my CPU+Blitter combination for AGA Amiga's) and exclude any use of hardware sprites.

For AGA, as DanScott just mentioned, I've always found that the most optimal mode by far is Dual Playfield mode. You get the best 'bang for the buck' in that mode.

Do note that using hardware sprites will very likely mean having to drop back to 1x fetch mode, which will lower the number of bobs you can draw considerably. But it will gain you 64 pixel wide sprites which are effectively "free". Something to consider.

Last edited by roondar; 15 April 2020 at 14:10.
roondar is offline  
Old 15 April 2020, 14:13   #26
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,811
Quote:
Originally Posted by roondar View Post
RE: AGA 256 colour/50FPS games calculations

Do note that using hardware sprites will very likely mean having to drop back to 1x fetch mode, which will lower the number of bobs you can draw considerably. But it will gain you 64 pixel wide sprites which are effectively "free". Something to consider.
Could you explain a little more on this? I'm not saying you're wrong I just want to understand more.

In Rygar I had the Amiga in x2 fetch with 32 wide hardware sprites and from recollection the fetch mode and the hardware sprites are completely independent.

Looking back I could have put Rygar in x4 fetch mode but I would have lost 3 hardware sprites due to scrolling limitations.

Geezer
mcgeezer is offline  
Old 15 April 2020, 14:20   #27
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,962
Quote:
Originally Posted by mcgeezer View Post
Could you explain a little more on this? I'm not saying you're wrong I just want to understand more.

In Rygar I had the Amiga in x2 fetch with 32 wide hardware sprites and from recollection the fetch mode and the hardware sprites are completely independent.

Looking back I could have put Rygar in x4 fetch mode but I would have lost 3 hardware sprites due to scrolling limitations.

Geezer
It's all about the resolution I was thinking about (320 pixel wide)

As you correctly note, the fetch rate does not actually impact sprites per se, it's just that the 64 pixel wide fetches occur so early when you use a 320 pixel wide screen with horizontal scroll that all (or all but one?) of your sprites go missing.

You could instead just make the screen less wide (such as Rygar is due to the nature of the original graphics).
roondar is offline  
Old 15 April 2020, 15:35   #28
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,495
Quote:
Originally Posted by roondar View Post
RE.
For AGA, as DanScott just mentioned, I've always found that the most optimal mode by far is Dual Playfield mode. You get the best 'bang for the buck' in that mode.
.
You end up with something that doesn't look much better than OCS in that mode, though.

It's still only 16 colours in the foreground with a ridiculously colourful background as a parallax layer, which you usually don't need since you want the viewers attention on the foreground.

I think I'd either go with a few more bitplanes and sprite layer, or whatever voodoo mcgeezer was doing in Rygar fir getting 32 colours in the foreground and 8 in the back.
Steril707 is offline  
Old 15 April 2020, 15:51   #29
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,962
Quote:
Originally Posted by Steril707 View Post
You end up with something that doesn't look much better than OCS in that mode, though.

It's still only 16 colours in the foreground with a ridiculously colourful background as a parallax layer, which you usually don't need since you want the viewers attention on the foreground.
We'll have to agree to disagree here

Quote:
I think I'd either go with a few more bitplanes and sprite layer, or whatever voodoo mcgeezer was doing in Rygar fir getting 32 colours in the foreground and 8 in the back.
AFAIK he set up a smart palette across 8 bitplanes to allow him to blit three background bitplanes separately from the foreground. I'm not quite sure if the scrolling was pure blitter or that he used the odd/even playfield shift to shift bitplanes in groups of 4 and then corrected the position of one with the blitter. Regardless, the general idea is "simply" to play around with bitplanes and palettes
roondar is offline  
Old 17 April 2020, 17:18   #30
Nightfox
Registered User

Nightfox's Avatar
 
Join Date: Apr 2016
Location: Perth, Australia
Posts: 238
Thanks so much for the in-depth info. Is there a book or online resource to learn how the AGA hardware works? I have the latest edition of the amiga hardware reference manual (3rd edition) but that was released before AGA came out I think as there is no mention of it. Is there a 4th edition? If not, how did amiga game devs learn the AGA hardware when it was released?
Nightfox is offline  
Old 17 April 2020, 17:47   #31
buzzybee
Registered User

 
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 367
Sprites are pretty versatile for some game genres, depending on design. If I created a platformer, I´d consider using sprite for the main character and the score display. Because if you this, you can update the rest of the screen with only 25 fps and the result will still look smooth and convincing.

Also, while the Amigas sprites certainly have their limits, you can do quite a lot with them if you know how to properly control and multiplex them. Consult the Sprite pages within Commodores official Hardware Reference Manual to learn more about multiplexing using DMA, which is comfortable and leads to good results. As for AGA, I use this register overview and the EAB :-)
buzzybee is offline  
Old 17 April 2020, 18:03   #32
olleharstedt_wo
Registered User

 
Join Date: Apr 2020
Location: Hamburg, DE
Posts: 10
There's a video on YouTube showing 94 sprites at the same time, moving randomly, on OCS. Some minor flickering is visible if you slow down the playback. Searching for "amiga sprites" should be enough to find it.
olleharstedt_wo is offline  
Old 17 April 2020, 21:34   #33
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 233
Quote:
Originally Posted by Nightfox View Post
Thanks so much for the in-depth info. Is there a book or online resource to learn how the AGA hardware works? I have the latest edition of the amiga hardware reference manual (3rd edition) but that was released before AGA came out I think as there is no mention of it. Is there a 4th edition? If not, how did amiga game devs learn the AGA hardware when it was released?
No there was no new manual. Commodore didn't want anyone banging the hardware at that time. There were some commodore confidential register chipset descriptions that people got hold off (I still have a photocopy!) and lots of reverse engineering.
Antiriad_UK is offline  
Old 20 April 2020, 12:40   #34
pink^abyss
Registered User
 
Join Date: Aug 2018
Location: Untergrund/Germany
Posts: 26
Quote:
Originally Posted by DanScott View Post
Ah thanks!! That's one of the 2 parts I didn't code

Oops. They looked so Dan'ish to me
pink^abyss is offline  
Old 20 April 2020, 13:40   #35
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Sunny Bournemouth, UK
Posts: 622
Quote:
Originally Posted by pink^abyss View Post
Oops. They looked so Dan'ish to me
Aha! yes, the idea came from Facet, from a GIF he saw somewhere... and the other part I didn't code was the dot tunnel thing (that also originated as a GIF that I found on Pinterest)

Everything else came from my hands/mind
DanScott is offline  
Old 30 April 2020, 11:53   #36
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 350
Quote:
Originally Posted by Steril707 View Post
You end up with something that doesn't look much better than OCS in that mode, though.

It's still only 16 colours in the foreground with a ridiculously colourful background as a parallax layer, which you usually don't need since you want the viewers attention on the foreground.

I think I'd either go with a few more bitplanes and sprite layer, or whatever voodoo mcgeezer was doing in Rygar fir getting 32 colours in the foreground and 8 in the back.
But you also get better sprites with their own unique colour palettes. You probably want the player and enemies to stand out against the background so having separate colours for them really helps. Or alternatively you can add another parallax layer.

Another option is to use the foreground playfield just for bobs. If you are careful you can avoid needing to use cookie cut mode at least some of the time, and erasing is faster too.
zero is offline  
Old 30 April 2020, 14:57   #37
coder76
Registered User

 
Join Date: Dec 2016
Location: Finland
Posts: 109
"BOBs per 320x256 PAL frame:
OCS 4 BPL: 46704/2304*0,9=about 18 bobs
OCS 5 BPL: 41328/2880*0,9=about 12 bobs
AGA 8 BPL: 55920/4608*0,95=about 11 bobs
AGA 16+16 Dual Playfield mode: 55920/2304*0,95=about 23 bobs"

Interesting figures here, and really shows how inefficient the blitter is. If we take OCS 4 bitplanes and 32x32 size, the effective bandwidth for bobs is 32*4*4*18*50=460,80 kB/sec. This can be compared to blitter copy speed of 3,3 MB/sec.
coder76 is offline  
Old 30 April 2020, 15:53   #38
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,962
Quote:
Originally Posted by coder76 View Post
"BOBs per 320x256 PAL frame:
OCS 4 BPL: 46704/2304*0,9=about 18 bobs
OCS 5 BPL: 41328/2880*0,9=about 12 bobs
AGA 8 BPL: 55920/4608*0,95=about 11 bobs
AGA 16+16 Dual Playfield mode: 55920/2304*0,95=about 23 bobs"

Interesting figures here, and really shows how inefficient the blitter is. If we take OCS 4 bitplanes and 32x32 size, the effective bandwidth for bobs is 32*4*4*18*50=460,80 kB/sec. This can be compared to blitter copy speed of 3,3 MB/sec.
Well, it's not really inefficient per se... The issues the Blitter has here also exist for CPU based drawing methods (but less so as the Blitter has less overhead in drawing than the 68000/68020). It's rather the reverse: Sprites are simply vastly more efficient than the Blitter/CPU

The Blitter (nor the CPU, Copper or Sprites for that matter) simply can't access the cycles that bitplane DMA use so you have to subtract those from any bandwidth figure you get. Furthermore, blitting a bob is also a two step process (cookie-cut draw & restore), which drops "Bob bandwidth" quite severely.

But yeah, Sprites are massively more efficient. Use them

Edit: I just noted the numbers you use might be a slight underestimation (well, IMHO anyway), I'd say the number should be 32*6*4*18*50=675KB/sec. Reason for this is that the Blitter (or any word based algorithm really) needs some extra "space" for shifting the data, which adds an additional word per line to draw. Then again, I suppose you could argue that this shifting space isn't really part of the "bob"... Swings and roundabouts...

Last edited by roondar; 30 April 2020 at 16:21.
roondar is offline  
Old 05 May 2020, 13:47   #39
Auscoder
Registered User

 
Join Date: Jan 2019
Location: Brisbane
Posts: 63
Quote:
Originally Posted by Antiriad_UK View Post
No there was no new manual. Commodore didn't want anyone banging the hardware at that time. There were some commodore confidential register chipset descriptions that people got hold off (I still have a photocopy!) and lots of reverse engineering.
This is quite good if you can read Italian : http://corsodiassembler.ramjam.it/dl...VYryAVFjxkzeBM

Also use : https://www.ikod.se/references/amiga...or-aa/#BPLCON3

And hit up ppl on this forum for the missing links!

Quote:
Originally Posted by Steril707 View Post
You end up with something that doesn't look much better than OCS in that mode, though.
You are a marvelous pixel artist, it nearly killed me when attempting Boss Machine at 2x8.

Quote:
Originally Posted by DanScott View Post
Personally I'd us 2 x 16 colour playfields, and try to make use of the 16 attached sprites too
We are using 2x16 for Boss Machine (Still a work in progress), with 64 bit sprite assist. We love the extra colors over OCS. Minspec 020/AGA seems well worth it. [ Show youtube player ]
Auscoder is offline  
Old 06 May 2020, 16:17   #40
AmigaHope
Registered User
 
Join Date: Sep 2006
Location: New Sandusky
Posts: 680
Quote:
Originally Posted by Tsak View Post
64 colors is only good (but still not ideal due to ram limitations) for something like a point'n'click adventure game (on OCS).
I wouldn't say that's true. You can use it for more than just point and click adventure games.

It works great for something like Desert Strike where you can draw shadows using only one bitplane's worth of writes.

Or you can use it in fast action games that don't have a lot of independently moving objects and you don't draw new scroll and just scroll around bitmap, like in Pinball Fantasies or Fightin' Spirit OCS/ECS versions.

Or in RPGs where there's action but it's limited to animations in part of the screen, like Black Crypt.

Last edited by AmigaHope; 06 May 2020 at 16:24.
AmigaHope 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
Pointer to blank (null) hardware sprite DanScott Coders. Asm / Hardware 10 08 March 2020 15:48
Displaying hardware sprites to the left of DDFSTART DanScott Coders. Asm / Hardware 12 10 March 2019 20:37
Hardware Sprite Glitch Old_Bob support.WinUAE 4 05 April 2018 23:53
Advanced enemy paths and connected sprites on old hardware MickGyver Coders. General 7 06 December 2017 05:51
Using hardware sprite images more than once per lin jimmy2x2x Coders. General 5 20 November 2014 11:30

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 04:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.11484 seconds with 15 queries