View Single Post
Old 01 December 2015, 02:09   #104
2 contact me: email only!

Codetapper's Avatar
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,099
Originally Posted by Mrs Beanbag View Post
How is retrieving "exact pixel dimensions" any more CPU usage?
In my case, I don't bother storing the width of the object in pixels as when you're plotting it it doesn't make any difference if it's 31 pixels wide or 32. I store the fact it is 2 words wide on the sheet of graphics so it's ready for the blitter. It seems pointless to read the width as 31 into a register if the final pixel happens to be empty and make a bunch of calculations including shifts (which are slow on the 68k) to work out that almost all of the time it's going to still take up 2 words plus the one extra for shifts. Remember the A500 has a fast blitter compared to the CPU, and I am making it to run on the A500 at 50fps.

And it's not "one extra word". We're talking about *doubling the size of all the blits of 16-pixel wide objects*. Or for 32-pixel wide objects, it's 50% extra blitting.
It's not "extra" at all, that is the "normal" case that you should consider - ie. the object NOT exactly on the word boundary. Anything else is (hopefully) an optimisation to save one word per pixel height (but if you do too much work on every object to work that out, it's not).

Anyway, I originally wrote my code thinking that method you speak of might work (saving a word rarely) and ditched it as it made the general blitting routine much more of a mess and so I ditched it.

It is a simple matter to ensure that an enemy's bullets go at 8 pixels per frame, for instance, or that an enemy charges at 4 pixels per frame.
Have you seen shoot'em-ups that do that? They look utterly mental. The bullets either look like they're appearing from way out in front of the guns one frame and way back the next frame when you creep forward a pixel.
Codetapper is offline  
Page generated in 0.05279 seconds with 9 queries