English Amiga Board


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

 
 
Thread Tools
Old 19 May 2020, 17:21   #41
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 56
Quote:
Originally Posted by roondar View Post
Code:
OCS Blitter efficiency: ~90%
AGA Blitter efficiency: ~95%

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
Hi! really interesting and accurate numbers here ( I'm currently playing with OCS blitter bobs speed). I'm wonder where comes the "OCS Blitter efficiency: ~90%". Is it empirical value measured with some tests you did?
leonard is offline  
Old 19 May 2020, 17:45   #42
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,964
Quote:
Originally Posted by leonard View Post
Hi! really interesting and accurate numbers here ( I'm currently playing with OCS blitter bobs speed). I'm wonder where comes the "OCS Blitter efficiency: ~90%". Is it empirical value measured with some tests you did?
The efficiency figures are basically a rough estimate based on my own Blitter code. It was tested by looking at how many Bobs I could draw in a frame, timing how long that took and subtracting the time the Blitter would've taken to draw the bobs.

That gave me a figure for the overhead, which for OCS and my routines hovered around 10% of the total time blit. It's not exactly 100% precise. But then again, it's not meant to be a set-in-stone figure - just a useful estimate. Other ways of blitting or even different object sizes can make the number go up or down a bit
roondar is offline  
Old 19 May 2020, 18:01   #43
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 56
yeah that's quite accurate. My own measure for 32*32 bobs, 4bpl, OCS, with 320*256 screen, and "without" restoring the background ( just clearing it ). So with your numbers it gives:

46704/1920*0,9 : 21.89 sprites ( 1920 because clearing, not restoring backg)

and my code can push 21 of these bobs ( I'm using WinUAE, cycle exact, OCS, don't know if it's 100% speed accurate compared to a real OCS amiga. I guess it is )
leonard is offline  
Old 19 May 2020, 23:57   #44
alain.treesong
Aghnar
 
Join Date: Jan 2019
Location: France
Posts: 13
So I try to do some measures with Amos (Pro, no specific extension)

The config is winuae. Same as @leonard with also the "wait for blitter" option checked (otherwise I remark the emulator is a bit faster than a real A500, with Amos at least)

For 32x32 bobs, OCS, 4 bitplanes, 320x256 with a little animation (cycle moves left/right):

6 bobs 50 fps with restoring background
8 bobs 50 fps without restoring background (clear color 0)
13 bobs 25 fps with restoring background
19 bobs 25 fps without restoring background.

Not so bad.

In fact, hardware sprites and bobs have to be used together.

For a platform game, in Amos, I will set the dual playfield mode (7+8) :
- foreground with bobs at 25 fps with no restoring
- background 8 colors for the scrolling at 50 fps
- use of sprites which can remain at 50 fps.
It can give perhaps an interesting engine, in Amos.
alain.treesong is offline  
Old 20 May 2020, 09:43   #45
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 176
You may calculate the (theoretically) limits of drawing Bobs on OCS hardware here: https://jsfiddle.net/zkwa9fnu/

It's based on calculations done by roodar.
AnimaInCorpore is offline  
Old 20 May 2020, 09:45   #46
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 176
This might be of interest as well:
[ Show youtube player ]
AnimaInCorpore is offline  
Old 20 May 2020, 10:58   #47
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 233
Quote:
Originally Posted by AnimaInCorpore View Post
You may calculate the (theoretically) limits of drawing Bobs on OCS hardware here: https://jsfiddle.net/zkwa9fnu/

It's based on calculations done by roodar.
Oh that's neat. Thanks
Antiriad_UK is offline  
Old 20 May 2020, 13:06   #48
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,964
Quote:
Originally Posted by AnimaInCorpore View Post
You may calculate the (theoretically) limits of drawing Bobs on OCS hardware here: https://jsfiddle.net/zkwa9fnu/

It's based on calculations done by roodar.
Yeah, it's very nice having that piece of Javascript. I've used it quite a few times now
roondar is offline  
Old 20 May 2020, 13:47   #49
DanielAllsopp
Registered User

DanielAllsopp's Avatar
 
Join Date: Feb 2018
Location: Northumberland, UK
Posts: 87
Quote:
Originally Posted by AnimaInCorpore View Post
You may calculate the (theoretically) limits of drawing Bobs on OCS hardware here: https://jsfiddle.net/zkwa9fnu/

It's based on calculations done by roodar.
Oh, this is great. Do you mind if I "port" this code over to my ASM helper tool that I'm building?
DanielAllsopp is offline  
Old 20 May 2020, 13:49   #50
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,964
Quote:
Originally Posted by DanielAllsopp View Post
Oh, this is great. Do you mind if I "port" this code over to my ASM helper tool that I'm building?
If you do, keep in mind that Dual Playfield bobs are either 3 or 4 bitplanes deep (OCS/AGA), not 6 or 8. I made that error once or twice and it made everything seem much less nice than it was
roondar is offline  
Old 20 May 2020, 15:14   #51
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 176
Quote:
Originally Posted by roondar View Post
If you do, keep in mind that Dual Playfield bobs are either 3 or 4 bitplanes deep (OCS/AGA), not 6 or 8. I made that error once or twice and it made everything seem much less nice than it was
https://jsfiddle.net/wk910ymo/

Now the number of planes for the sprites can be defined independently. Can you please check if the results are correct?
AnimaInCorpore is offline  
Old 20 May 2020, 21:54   #52
leonard
Registered User
leonard's Avatar
 
Join Date: Apr 2013
Location: paris
Posts: 56
Quote:
Originally Posted by AnimaInCorpore View Post
Can you please check if the results are correct?
I think the formulas are slightly off. I did some test with optimal blitter driven by copper. I'm looking at 3 bitplan screen, with 32*32 3 bitplans sprites, without any backup or restore, just CLEAR.
I can draw 30 bobs max. Formula says 31.19 and even *with* restore!

For 4 bpls, I can draw 20 bobs max. formula says 21.17 *wit* restore.

Maybe the empirical *0.9 is wrong. Or maybe DMA cycles are wrong. Or maybe WinUAE is wrong.
leonard is offline  
Old 20 May 2020, 23:07   #53
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,964
Quote:
Originally Posted by AnimaInCorpore View Post
https://jsfiddle.net/wk910ymo/

Now the number of planes for the sprites can be defined independently. Can you please check if the results are correct?
Those numbers look fine, yeah. I did some calculations and they came to the same numbers for the theoretical max.

In fact, yours are slightly better than the ones I used in this thread because I mistakenly calculated the audio+refresh to be a maximum of 2304 cycles, while it is in fact (312*4)+(312*4)=2496. Which is what your Javascript uses
Quote:
Originally Posted by leonard View Post
I think the formulas are slightly off. I did some test with optimal blitter driven by copper. I'm looking at 3 bitplan screen, with 32*32 3 bitplans sprites, without any backup or restore, just CLEAR.
I can draw 30 bobs max. Formula says 31.19 and even *with* restore!

For 4 bpls, I can draw 20 bobs max. formula says 21.17 *wit* restore.

Maybe the empirical *0.9 is wrong. Or maybe DMA cycles are wrong. Or maybe WinUAE is wrong.
There's a couple of things here: the code AnimaInCorpore wrote does not use the *0.9 factor - it's designed to just show the theoretical limit of the Blitter (meaning it assumes the Copper & CPU take zero time to set up blits/run other code, which isn't true).

So if we take the 21.17 bobs it came to for 4 bitplanes and multiply it with my "overhead estimate" of 0.9x, we're down to 19.05 bobs for the optimal draw+restore method - which is much closer to the 20 you got.

However, there is another factor which causes your code to perform a bit worse than you might have originally thought and that is the way Blitter clearing works. That is to say: Blitter clearing does not take half of the time that it takes to do Blitter copying. It in fact takes same amount of time, but has half of it's cycles as "idle".

These idle cycles are a bit complicated as they're not really fully free, but not really fully in use either. The way it works is as follows:
  • Blitter idle cycles can be freely used by the CPU
  • Blitter idle cycles can not be used by any standard DMA source (bitplane, audio, sprites, copper, disk, refresh)
  • Which means that Blitter idle cycles must always be either completely free (no interleaving with other DMA), or be used by the CPU
The main consequence* of this is that a Blitter clear's idle cycles can't interleave with the display DMA, so it's not actually any faster than a standard copy in that case. The end result of this is that often you gain less performance by using Blitter clears than you might think (it'll be somewhere between the speed of a copy and twice the speed of a copy).

*) sprite/copper/audio/disk are usually quite small DMA loads so they have less of an impact
roondar is offline  
Old 21 May 2020, 08:37   #54
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,887
PAL non-interlaced field has normally 313 (long field) lines, not 312 (short field)
Toni Wilen is online now  
Old 21 May 2020, 15:22   #55
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,964
Ah, I did not know that. Thanks for the info!
roondar is offline  
Old 21 May 2020, 18:15   #56
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 176
Quote:
Originally Posted by Toni Wilen View Post
PAL non-interlaced field has normally 313 (long field) lines, not 312 (short field)
Thanks for the info. So the newest jsfiddle version can be found here: https://jsfiddle.net/p2d53qLn/2/
AnimaInCorpore 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 20:13.


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