Blitter Size and game speed

[geldo79]

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

[roondar]

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.

[guy lateur]

Originally Posted by roondar

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.

I always kinda assumed that, for the same blit size, it would be faster to blit fewer long lines than it would be to blit more small lines. Eg, blitting 16 lines of 64 pixels each would be faster than blitting 64 lines of 16 pixels.

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?

[geldo79]

Thanks roondar,

this gives me the motivation i needed....even if it would be only 2 times faster (-:

[roondar]

Originally Posted by guy lateur

I always kinda assumed that, for the same blit size, it would be faster to blit fewer long lines than it would be to blit more small lines. Eg, blitting 16 lines of 64 pixels each would be faster than blitting 64 lines of 16 pixels.

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?

It is indeed true that blitting longer lines is faster for bobs (but usually not for other operations). But the reason isn't to do with calculations (the Blitter adds the modulo/offset for free between lines), but rather with the need to shift the image to get to get to the location on the screen that is desired.

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.

Originally Posted by geldo79

Thanks roondar,

this gives me the motivation i needed....even if it would be only 2 times faster (-:

You're welcome!
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

[geldo79]

Originally Posted by roondar

You're welcome!
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

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?

[roondar]

Originally Posted by geldo79

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?

On the Amiga, most games use double buffering. Some even use a form of triple buffering. The idea of double buffering is that you show one buffer while you draw the next one. That way, you can use up to the entire frame to calculate & draw bobs rather than just the time of the vertical blank.

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.

[geldo79]

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?

[Antiriad_UK]

Originally Posted by geldo79

Thus, i would have to define a second bitplanes-buffer in memory, and switch the bitplane pointers every frame to the other buffer?

Yes, that's standard for games/demos. You use all the frame to draw your scene and then switch pointers to display.

[jotd]

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.

[pink^abyss]

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.

[geldo79]

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?

[pink^abyss]

Originally Posted by geldo79

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?

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.

[mcgeezer]

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

[defor]

Originally Posted by geldo79

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?

It's often a copper-list which is swapped. Every copper-list, usually at the beginning, then sets BPL pointers to an appropriate buffer (hence the double-buffering). It's more convenient to swap just one copper-list pointer (COP1LC) instead of changing all BPL pointers again and again. You can do it anytime after vblank because Copper fetches that address on vblank (automatic strobe of COPJMP1).
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.

[geldo79]

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.