Re: A85: Dumb question

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

Re: A85: Dumb question


In a message dated 3/10/99 7:59:56 PM MST, mpearce@bbnow.net writes:

> Unluckily, most of the source code i had at the time is gone (got a new
>  computer and didn't transfer all of the code.. but atleast i got Solomon's
>  Key which should be finished in a couple of weeks).  Like i said, it gave
>  very comparable results to PutSprite and maybe 5 bytes larger, so i never
>  even used it in my own game (i was working on Solytare at the time).  Wait,
>  maybe i didn't use it in Solytare because it didn't do OR drawing.  Yeah,
>  that was probably the reason but i'm not for sure.  Does your routine
>  completely rotate one row at a time or does it do 1 rotate then move to the
>  next row?
>  
>  -mike pearce

Okay, basically what it does is, before the actually putting and right after
the ' call FIND_PIXEL instruction', the following code is executed:

 call FIND_PIXEL
 add a,a\ dec a\ ld c,a
 ld a,b\ and %00000111\ ld (&SDRPrepByte),a

What the first line does is put the offset mask into C.  For example, if A was
%00100000, then C would become %00111111.  Since most sprites lie between two
video bytes (like, if C had become %00111111, then the sprite would be put to
a row of video mem bytes the following way:  %00xxxxxx,%xx000000 <- the x's
being where the sprite goes...you'll see why C is what it is if not already),
it's necessary to mask off a "left half" and "right half" when it's rotated.
The next line simply modifies the jump instruction right before the unrolled
loop that rotates each sprite byte.  It'll look like this if B was, say, 42,
after the second line of code is executed:

SDRPrepByte:
 jr 2
 rlca\ rlca\ rlca\ rlca\ rlca\ rlca\ rlca\ rlca

So, in the actual sprite putting loop, each sprite byte is loaded into A and
rotated with the above unrolled loop.  The result of this is stored in a
register temporarily, and then the rotated sprite byte's "left half" would be
masked off.  What do I mean by this?  Well, this is where C comes in...  Say B
and C are what they were stated above.  The first sprite byte is, say,
%11001101.  It would be rotated left 6 times, or rotated right twice, so it'd
look like this: %01110011.  Then the "left half" is masked off using C:
%00110011...since the sprite starts at a bit 5 of each video mem byte, bits 6
and 7 are suppose to be reset.  Then this result is 'or'ed with the video
memory, loaded into the video memory, and the vid mem pointer increases for
the "right half" of the sprite to be put.
So, next, C is loaded in A and complemented (it's now %11000000), then the
"right half" is masked off of the orginally rotated sprite byte (so that'd be
%01000000).  Then it's a simple ' or (hl)\ ld (hl),a'!  Of course, regular
sprite putting is a little harder, but by no means much...shouldn't be hard to
figure out.

JL