The Spectrum screen memory does not lend itself to aligning objects to pixels horizontally. Allow me to elaborate.

If you have a 16×16 sprite of a ball and only want to place it at character (byte) positions, you can simply take the sprite data and copy it to the screen.

However, if you wanted to place it at pixel positions, you first need to establish the nearest character position, then shift the sprite data to the pixel position before copying it to the screen.

Shifting can be quite a time consuming process, but there is a sneaky shortcut. You can pre-shift the sprites.

Take the following example:

There are four sprite images in blocks of memory which are 3 bytes wide x 16 rows tall. The sprite image itself is only two bytes wide.

This is the science bit. Each sprite image has been drawn with a different shift to the right. To place this ball sprite within two pixels on the X coordinate, simply take the X coordinate, AND with %00000110, and use this four bit value to index the correct sprite definition.

Of course this means that this sprite takes 6 times the amount of memory up (including the shift area).  This would be more for the 8 definitions required for pixel accuracy.

There are two ways to reclaim some of this memory back:

1. Get the graphic artist to incorporate the shift into the sprites animation, say for example shift and animate the walk of the man.
2. Reserve a scratchpad area of memory for sprites and before the sprites are required (say, at the beginning of a game level) pre-shift the required sprites into this area.

The benefit of this voodoo trickery is speed; very important when you are trying to squeeze every ounce of power out of a relatively slow computer. The drawback is that you have to box smart and pick the method which suits the game best.