View Single Post
Old 30 November 2015, 22:08   #101
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Originally Posted by Codetapper View Post
Apart from a few games like Rick Dangerous that use 24 pixel wide bobs (so the graphics are standard across all platforms), I would say you'd hardly find any games that don't have the majority of their graphics very close to a 16 pixel wide boundary.
The reasoning here is oddly circular... obviously if the bob engine only supports images with widths of multiples of 16, it would be wasteful not to design your graphics to that limitation.
I don't believe this 30% speedup at all, you'd be lucky to save 10% total and you probably lose that when you add up all the extra checks you have to do on every object to detect them, thus wiping out any saving.
It is exactly a third less in terms of total blitted area. I think you are overestimating the complexity of the process, there are no "extra checks on every object", all there is is a function that can redraw the map in a rectangular area. There is obviously some extra CPU overhead involved, but it's hardly reams of code.

For a 16 pixel wide object, you have 1 case where you adjust the mask to be $ffff, and can draw the object with 1 word if it's being plotted with 0 pixel indentation to a word boundary.
For a 15 pixel wide object, you have 2 cases where you adjust the mask to be $fffe, and can draw the object with 1 word if it's being plotted with 0-1 pixel indentation to a word boundary.
For a 14 pixel wide object, you have 3 cases where you adjust the mask to be $fffc, and can draw the object with 1 word if it's being plotted with 0-2 pixel indentation to a word boundary.
You think it is a special case for every extra pixel wide, this is strange. There is the case where you have to blit an extra word wide, and the case when you don't. There is no need to worry about the LWM at all in the latter case, since the bob's own mask image is zero there anyway.

you don't need to calculate if it's going to need one word less to blit, don't need to adjust those modulos when the edge case is found, can use the blit-one-extra-word-with-last-word-mask-set-to-$0000 trick for shifting etc.
But these calculations are trivial. For a 16-pixel wide bob, knowing when not to blit one extra word wide is just a case of checking if the bit shift is zero. For other widths it's just a comparison against (16 minus (pixel width & $f)).

Not to mention your restoring-from-tiles idea, adding that onto a complicated blitter routine when the screen could be using a copper-split to begin with seems inefficient.
Copper-split does add some complexity, but it is worth doing for the sake of the scrolling. Although i have another idea up my sleeve for my next scrolling and bob routine.

If you go ahead and disassemble some games you will see that most have quite a compact blitter drawing routine. They do not tend to have loads of extra cases to speed up blitting in the rare event that it happens. If it was worthwhile, I would imagine most of the big name games would have extremely complicated blitter routines, but the simple fact is that they don't. Check out the Lotus series for a great example of how simple the blitter routines are.
Well i imagine if it was "fast enough" and they had a release deadline coming up, that they were happy to leave it at that, and we all know how many games creators seemed happy with 25fps. Lotus is not a great example to compare, since most of its bobs are fairly large and probably appear in a fairly uniform distribution regarding their position on the screen, but for 2D scrolling games things are different. Often enemies are constrained to move along one axis at a time. If they move sideways at 4 pixels per frame, they are on word boundaries 1/4 of the time, not 1/16. If they move around a maze like pacman, they are on word boundaries about 1/2 the time. If they only move up and down, they are on word boundaries ALL the time. So for 16 pixel wide bobs, you can cut the blitting time in half, and you would tell me that it's not worth doing, for the sake of a few CPU instructions? And that when it is usually the CPU waiting for the Blitter, rather than the other way around, and that the CPU can perform its calculations for the next blit while the Blitter is still busy on the previous one.

Last edited by Mrs Beanbag; 30 November 2015 at 22:16.
Mrs Beanbag is offline  
AdSense AdSense  
Page generated in 0.06033 seconds with 9 queries