Re: A89: Need help with game


[Prev][Next][Index][Thread]

Re: A89: Need help with game




>Shifting is most common.  The 89 doesn't _really_ need clipping routines.
>Greyscale is standard (any write address).  Masks are generally used.  And
>how about some flip/rotate routines?

I fail to see any need for a sprite library.  Actually, I don't think that
ANY libraries are worthwhile if they're for the purpose of common routines -
I find only ones that make programs larger than 64k and prosit's great
management libraries worthwhile.  Looking at my calc, with 40-some odd
games, I most likely LOSE space from my libraries, most of which contain
small routines that are only used in a few programs.  The ones with some of
the more useful routines contain too many extra routines - see graphlib -
which make them bloated enough to lose space.

Why can't you manage sprites with just graphlib?  What else do you want in
your sprite routine?  A little wrapper routine handles greyscale:

;putsprite
;draws a greyscale sprite 16x16 in the form of two
;bitplanes, one after the other
;graphlib::choosescreen must not equal zero
;input: a0 - pointer to sprite
putsprite:
    move.l a1,-(a7)
    lea blankmask(pc),a2
    move.l (graphlib::plane0),a0
    jsr graphlib::put_sprite_mask    ;desired variation here
    move.l (graphlib::plane0),a0
    jsr graphlib::put_sprite_mask    ;desired variation here
    move.l (a7)+,a1
    rts

Flipping can be done easily, and putting that in a library is a waste.  The
calc itself doesn't seem fast enough to handle bitmap rotation in a
real-time game, although vector rotation could work.  You're better off just
having a sprite for each rotation (size ain't that important).

To the guy who originated this thread: graphlib's putsprite functions CAN
handle negative coordinates - it'll clip itself.  If you're only using the
89's screen, you don't even need to clip it - just subtract 1 from the y
value, and subtract the distance off the screen on the left from 240.  This
cheap hack works because the calc draw's to the off-screen part and
overflows onscreen.  Top clipping is a little bit harder, but a large buffer
would do.

    -Scott