So, based on what I've read about software sprite engines for the ZX Spectrum, we should be able to blit in a 16x8 pre-shifted bitmap during the v-blank interval, and then blit the background back in afterwards. Maybe even 24x16.
Of course, the sprite colours are limited to the colours in the corresponding text cells. One solution would be to introduce a multi-colour mode. In this mode, 8 bits in memory would correspond to four double-width pixels. We would have a second 64 KiB lookup table, and the two bits for each pixel would correspond to Fixed A, Fixed B, Attribute Foreground and Attribute Background. I propose Fixed A and Fixed B are black and white for simplicity - they will be a function of the generated 64 KiB table and so cannot be changed at run-time. But it would allow for a white 'Dizzy' style sprite to run past red, black and green background. The pixel doubling would drop the effective horizontal resolution to 192, which should be workable. You could drop the vertical resolution from 288 to 144 if you were seriously memory limited, or limit the bitmap section to the playfield, with 25% of the screen at the top and bottom remaining in text mode.
So, based on what I've read about software sprite engines for the ZX Spectrum, we should be able to blit in a 16x8 pre-shifted bitmap during the v-blank interval, and then blit the background back in afterwards. Maybe even 24x16.
Of course, the sprite colours are limited to the colours in the corresponding text cells. One solution would be to introduce a multi-colour mode. In this mode, 8 bits in memory would correspond to four double-width pixels. We would have a second 64 KiB lookup table, and the two bits for each pixel would correspond to Fixed A, Fixed B, Attribute Foreground and Attribute Background. I propose Fixed A and Fixed B are black and white for simplicity - they will be a function of the generated 64 KiB table and so cannot be changed at run-time. But it would allow for a white 'Dizzy' style sprite to run past red, black and green background. The pixel doubling would drop the effective horizontal resolution to 192, which should be workable. You could drop the vertical resolution from 288 to 144 if you were seriously memory limited, or limit the bitmap section to the playfield, with 25% of the screen at the top and bottom remaining in text mode.