Preshift tables – from 32 characters to 256 pixels
In the 80’s, not all machines could access the screen at a per-pixel level easily. Most were a case of for every 8 pixels, 1 byte of screen memory would be used. Each little ‘bit’ inside this byte of memory was treated as a dot on screen. This, in laymans terms, means that if you wanted to move game characters super-smooth, a pixel on screen would be a “bit” inside an 8 pixel byte. Clever maths would be involved to translate a pixel, to a memory location and then to a bit inside a byte (sounds more complex then it was, really)
There was no “writing to a pixel” – it was in 8 pixel blocks at a time. So how did I get things moving a little smoother then 8 pixels (or “1 character”) blocks at a time when designing games?
The solution was pre-shift tables… That is, I would design a sprite for a game that was 1 character (8 pixels) wider then it needed to be. A second (or multiple) copy of the same sprite moved across a number of pixels would be also made, and then an X and Y coordinate value would have some maths applied to it so that the sprite was drawn at the correct location on this “higher res” location, making games look a lot smoother.
The other thing that also had to be done back then was not just to draw the sprite on screen, but it would have to be deleted before it was drawn again. As it was in the day, some games would start to look a little flickery… Tricks like masks came later for me, but for speed there were many techniques from just deleting all the “bytes” to 0, or using the computers processor to apply a ‘boolean’ to quickly flip bits around in a single command…
These concepts would come up time and time again, so I wrote it all down in a book so I would always have a reminder/reference to come back to… For anybody interested in a little “guide” to this whole concept of pre-shifted sprites, collision detection, etc on the ZX Spectrum :