Shift

The Shift value will perform a right bit-shift for the number of places specified. For example, to shift the value 4 places to the right (dividing by 16), you would enter 4. If you need to bit-shift to the left (highly unusual), specify a negative value.

Why on earth would you want to do this? The most logical way to store maps in games is to create an array of the tile numbers. For example, a small 5 by 4 map might look like this:

$11, $12, $13, $14, $15
$21, $22, $23, $24, $25
$31, $32, $33, $34, $35
$41, $42, $43, $44, $45

Each entry in the array refers to a single tile, so the top row of the map contains tile number $11, then $12, $13, $14 and $15. When the game has to draw the screen, it will look up the tile, and then have to locate the tile graphics in memory.

If each tile is 16x16 pixels in size and stored as 4 bitplanes (16 colours), then each tile would occupy 2 bytes x 16 pixels high x 4 planes = 128 bytes. The game knows where the tile graphics are located, so it has to take each tile number and multiply it by 128 to find the correct graphics for that tile:

_GetTileGfx     lea     _MapData(pc),a0         ;a0 = Map
                lea     _TileGfx(pc),a1         ;a1 = Tile graphics				
                move.w  (a0)+,d0                ;Read tile index into d0
                mulu    #128,d0                 ;Multiply by 128 to get offset

Multiplication is very slow on the 68000 chip. This can be sped up by using bit-shifting if the number is a power of 2. In this case, a shift of 7 to the left will give the same number, but is much faster:

_FasterTileGfx  lea     _MapData(pc),a0         ;a0 = Map
                lea     _TileGfx(pc),a1         ;a1 = Tile graphics				
                move.w  (a0)+,d0                ;Read tile index into d0
                lsl.w   #7,d0                   ;Faster multiply by 128 to get offset

But even bit-shifting is slow on the 68000, and it takes longer for every bit shift. Thus a bit-shift of 5 will be slower than a bit-shift of 4. The best solution is to store the map indexes pre-multiplied by 128, or if you don't have spare bits for that, at least bit-shift as many places as possible. The optimal routine would be removing the shift altogether:

_FastestTileGfx lea     _MapData(pc),a0         ;a0 = Map
                lea     _TileGfx(pc),a1         ;a1 = Tile graphics				
                move.w  (a0)+,d0                ;Read tile graphics offset into d0

If you are having to plot hundreds of tiles every frame, this optimisation can make the difference between a fast or slow frame rate.

This does pose a problem for map ripping however! If you are expecting to find the values $11, $12, $13, $14 and $15 in memory, you might find they are actually stored as $880, $900, $980, $a00 and $a80!

The program comes with a sophisticated map search function that will attempt to calculate the correct Mask and Shift values automatically.

When it comes time to display the map, you need to reverse the bit-shifting that has already taken place, otherwise the wrong tiles will be drawn. This is where the Shift value is useful. In this example, if we specify 7 as the Shift value, each tile index will be shifted right 7 times (dividing by 128) and giving the correct tile index. The first tile would be read from memory ($880), shifted right 7 times to give $11, which is the actual tile number.