[A83] Re: something to talk about
[Prev][Next][Index][Thread]
[A83] Re: something to talk about
Gavin Olson writes:
> What if you do two rounds of tiles, one for the first set, then inc
> the msb and go through the second set. Getting what tile to draw
> isn't the hard part right, so adding a check hee to see if it gets
> drawn now or later won't be that big a hit.
Nope, that's not possible due to how it works. The routine draws the entire
map at once. In the case of this routine, getting the map tiles is actually
the slowest part of the inner loop. The rest is a simple copy operation.
Crashman's routine is actually a lot different than Kirk's routine, though
still based on the same general principle. And very clever. It draws
vertically. It may sound crazy, but that's how the LCD works. So, the
routine must work like that also. Note that because it draws vertically,
interleaving the sprites is not necessary or desired.
The routine first calculates how many times to shift each graphic byte from
the X offset of the screen pixel offset. It then preshifts all of the
graphics into two 256 byte tables, one for left and right. The shifting is
quickly done using a prewritten, self modifying (relocated) loop. This is
very fast, since the loop is then essentially "hard coded" for that shift
number.
It then calculates the offset into the tile map. It then modifies two jumps
that skip none, some or all of the copies of the first and and last columns,
depending on the Y offset of the screen pixel offset. The last column skips
the opposite number as the first column. This is used to even out two ends,
because they are special cased.
After that it sets up the registers and shadow registers for the main loop.
The registers are used for the outer part of the loop and the shadows are
used in the inner part of the loop. The inner loop is not really a loop
because it is completely unrolled for speed. The loop runs twelve times,
once for each byte column. The beginning of the loop sets the column on the
LCD controller. It then jumps into the drawing part.
At the start of a column byte, the tile number is grabbed from the map. The
low bytes of the two sprite lookup tables are then set to the correct
position for the map tile. Then for each of the eight bytes, the value in
the buffer is first copied to the LCD controller and the bytes from the two
tables are combined and written to the buffer. This is repeated for all
eight bytes in the sprite. The entire process is then repeated eight times,
for all bytes in the column.
The reason for the 32 tile limit is the shift tables. Each one can only
hold 256 bytes. Changing this would completely change the way the routine
works.
--
David Phillips <david@acz.org>
http://david.acz.org/
References: