05 June 2021, 15:13 | #1 |
Registered User
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 44
Posts: 114
|
Blitter Size and game speed
Hi,
I want to optimize the speed of my game. When i started coding, i thought i'd need 16x16 pixel bobs. But now for the main bobs, a height of 3 pixels is sufficient. Now i wonder if it will have a large effect if i change the bob buffering/setting/clipping/clearing routines to a blitsize of 3x16 instead of 16x16 pixels. What do you think? At the moment, i get display problems if there are more than 8 Bobs are active, because the calculations need more time than a VBlank. Greetings Christian |
05 June 2021, 18:38 | #2 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
The time required to blit Bobs consists of two main parts: the time to set up the Blitter and the time the Blitter itself takes to complete the request*. The cost for the first part is usually fairly static, the cost for the second part scales linearly with the size of the Blit.
So, yes, dropping the size should give you more speed (in fact, the Blitter itself will be done over 5x as fast). However, the question is how much you'll gain in real world performance. This will depend a great deal on your Blitter set up code, as a 16x16 bob doesn't take that much time to draw with the Blitter and thus the static overhead of setting up the blit will become a much larger percentage of the total cost. Therefore, I can't say for sure how much you'll gain. It'll be at most 5,5x the speed, but realistically it'll probably be closer to 2,5-3,5x the speed due to the overhead of setting up the blit (assuming you use the CPU to set up the Blitter). *) There is also the time spend waiting on the Blitter to complete it's previous action, but if programmed well this can be seen as a static overhead that is part of the time to set up the Blitter for the next blit. |
05 June 2021, 21:56 | #3 | |
Registered User
Join Date: May 2017
Location: Belgium
Age: 50
Posts: 334
|
Quote:
The only reason I have for thinking this is you have to do the offset calculation after each line. Do you think this could make a real difference, or is this usually negligible? |
|
05 June 2021, 22:19 | #4 |
Registered User
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 44
Posts: 114
|
Thanks roondar,
this gives me the motivation i needed....even if it would be only 2 times faster (-: |
05 June 2021, 22:48 | #5 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
To be able to shift, the Blitter needs to draw 16 additional pixels per line (which is where the shifting is done into). These extra 16 pixels cost as much as any other 16 pixel block. With this is mind, we can say it's least efficient to have 16 pixel wide objects for blitting bobs and that blitting becomes progressively more efficient the wider the object becomes, though you reach diminishing returns pretty quickly. Quote:
If you don't mind me asking, what is the reason you have to be done during the Vertical Blank? Do you use a single buffered display perhaps? Because that's quite rare on the Amiga Last edited by roondar; 05 June 2021 at 22:57. |
||
05 June 2021, 23:12 | #6 | |
Registered User
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 44
Posts: 114
|
Quote:
Hmm,.I don't know if i got the point. I want my game to be fast....with a maximum framerate (50 fps). Calculations have to be done in the vb period I think. Not? |
|
05 June 2021, 23:18 | #7 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
The frame rate you get using that method will be the same (50fps), but you do introduce a slight latency/lag of 1 frame between drawing and showing. The reason it's so popular is because it allows you to draw more objects per frame without getting visual artefacts. |
|
05 June 2021, 23:45 | #8 |
Registered User
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 44
Posts: 114
|
That sounds interesting. Maybe i have to switch over to double buffering. Are there any examples? Thus, i would have to define a second bitplanes-buffer in memory, and switch the bitplane pointers every frame to the other buffer?
|
06 June 2021, 00:27 | #9 |
OCS forever!
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 418
|
|
06 June 2021, 00:36 | #10 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,161
|
either switch copperlist pointer or switch bitplane pointers at the end of the frame (BOF) or on copper interrupt. Pretty easy.
On Bagman I went from racing the beam (which didn't work) to double buffering very quickly. |
06 June 2021, 13:19 | #11 |
Registered User
Join Date: Aug 2018
Location: Untergrund/Germany
Posts: 408
|
I think a good practice to handle the cpu overhead of different bob sizes and their setup, is to allow any height, but restrict their width to a few values that you will actually need (16 and 32 pixel width should be enough for most games). Cache the blitter size for each of your bobs and blit all of a given width one after the other. So you can save a lot of blitter setup time because all modulos stay the same.
In C++ i need around one rasterline of setup time for a complex bob, that supports custom height, x+y clipping and copper splits. As a moving 16x16 bob on 4 planes takes around 3 rasterlines to blit, every height reduction is a win. Last edited by pink^abyss; 06 June 2021 at 13:31. |
06 June 2021, 16:21 | #12 |
Registered User
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 44
Posts: 114
|
When you say end of frame (BOF), can i use the start of the vblank too? I mean, is the start of the vblank the correct time to switch the bitplane pointers to the next buffer when using double buffering?
|
06 June 2021, 16:28 | #13 | |
Registered User
Join Date: Aug 2018
Location: Untergrund/Germany
Posts: 408
|
Quote:
Usually the bitplane pointers are set with a copper list. One apporach is to set the new copper list pointer on the line after your last gfx has been displayed. Then you should start right away with blitting because the blitter can now run at full speed because not bitplane dma is running. |
|
06 June 2021, 22:15 | #14 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Just don't do what I did in my first game and restored the screen buffer using the sprite positions from the current frame.
You'll know you've screwed it up because you'll get graphical glitches. You need to restore the positions from the previous frame. I might be able to dig out an example if you still need one. Geezer |
07 June 2021, 12:26 | #15 | |
Registered User
Join Date: Jun 2020
Location: Brno
Posts: 90
|
Quote:
P.S.: However to answer your question: You can change BPL pointers (by any mean) anytime before BPL DMA starts fetching words from bitplanes to BPLxDAT registers and after that fetching stops (see DIWSTRT/DIWSTOP registers) as changing it during the bitplane data fetching would obviously corrupt your displayed image. Last edited by defor; 07 June 2021 at 13:38. |
|
07 June 2021, 18:46 | #16 |
Registered User
Join Date: Oct 2019
Location: Eydelstedt / Germany
Age: 44
Posts: 114
|
It works now. I just swap the pointers at the beginning of vblank. Perfect result....now 20 bobs at once are no problem any more. Have to check the limits again now. I just worry why i did not have the idea of using two buffers by myself.....:-) Thanks again.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Question about blitter speed / DMA usage | LaBodilsen | Coders. Asm / Hardware | 3 | 25 January 2018 11:14 |
Throttle Blitter speed | amilo3438 | support.WinUAE | 5 | 12 August 2017 19:47 |
Maximum blitter speed with pipelining | zero | Coders. Asm / Hardware | 41 | 25 November 2016 20:35 |
Blitter filling speed, how much? | sandruzzo | Coders. Asm / Hardware | 7 | 03 July 2015 14:38 |
WHDLoad blitter speed tests - needs you! | girv | project.WHDLoad | 44 | 22 February 2008 13:43 |
|
|