View Single Post
Old 01 December 2015, 11:58   #107
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Originally Posted by Codetapper View Post
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.
So do i, currently, but i'm thinking about not doing that in future. Or perhaps store the word width, plus an additional value to compare against the shift register when you have it, which might be faster than a shift.

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.
There is not "a bunch of calculations". There is a single comparison operation (once you know what to compare against, which you can precalculate), and you either proceed exactly as normal, or you decrement the word width/increment modulos and set the Last Word Mask to $ffff. If you were using a lot of 8-pixel wide bullets i think that would be worth doing. Obviously there's no point programming features you don't intend to use. Admittedly, i've been coding for A1200, where the profile is different.

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).
We risk falling into pedantic word games here. It's "extra" in the cases where it isn't really needed. How often this case occurs depends on the design of the game. I can think of many cases where it would occur a lot. Platform games where characters go up and down word-aligned ladders, vertical shoot-em-ups with waves of 16-pixel wide missiles hailing down the screen.

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.
i've also ditched things in the past that i could probably do better now. i tried to implement some kind of blitter queue at one stage, that didn't really work out so i gave it up. i might try again at some point.

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.
If the guns firing such bullets are stationary, it is not a problem.

EDIT: just been looking at my source code, i haven't touched it for over a decade and i can see immediately that i could do some fairly trivial optimisations (the benefits of hanging out here), but after that and stripping out the code that handles the clipping at the edge of the screen, calculation of BltAFWM/BltALWM looks like this:
  moveq.l #-1,D4
  and.w #$F,D1  ; low 4 bits of X-coordinate
  beq.s aligned
    addq.w #2,D2  ; blit width
    subq.w #2,D3  ; A/B modulo
    clr.w D4
  [lsl.w D1,D4]  ; BltAFWM : BltALWM
EDIT2: wait a minute that can't be right, i'm going to have to sort this out until it makes sense again
EDIT3: worked it out, the last line only happens during clipping (forgot how the masks worked! it's been too long)

Last edited by Mrs Beanbag; 01 December 2015 at 21:13.
Mrs Beanbag is offline  
Page generated in 0.04137 seconds with 11 queries