Re: A85: Dumb question
[Prev][Next][Index][Thread]
Re: A85: Dumb question
I made a routine similar to this... atleast similar in the masking portions.
I like the use of self modifying code. that's a good idea. that does sound
like it should be pretty quick. I would be interested in seeing the source
(maybe everyone else on the list would also??) if you wouldn't mind sending
it. It makes me think that the routine i wrote only did OR drawing (i used
both in Solytare). Do you have a routine that draws all bits with
overwriting the existing memory?
-mike pearce
-----Original Message-----
From: JayEll64@aol.com <JayEll64@aol.com>
To: assembly-85@lists.ticalc.org <assembly-85@lists.ticalc.org>
Date: Wednesday, March 10, 1999 9:37 PM
Subject: 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
>