If a sprite's colours takes priority, and it moves with pixel by pixel movement, as soon as it enters a new cell, the background will take on it's colours. The colour clash seems to extend furthur than the sprite. This is down to the 8x8 cell colouring.
'''Possible resolutions on Spectrum:'''
* Remove colour from the display so that background and sprites use the same colours, clash is eliminated but the game is monocolour..
* Move sprites in cell based movements. The colours still take priority but the clash is less of a problem.
* Add a black border around the sprites. Clash occurs, but because of the border it is not/less seen.
'''Consequences for porting to CPC:'''
* If colour priority, colour clash exists: CPC version has the colour clash simulated which is unnecessary.
* If 2 colours are used and colour clash eliminated: CPC version lacks colour, same as Spectrum
* The CPC can't replicate the Spectrum's colour attribute system, this means a game converted to Amstrad's mode 1 has even less colours than the Spectrum version. The CPC version then has 4 colours, compared to up to 15 possible colours on the Spectrum.
'''What they should do for be done on CPC:'''
* Recolour the graphics appropiately for the CPC in either mode 1 or mode 0.
* Use the Amstrad interrupts and change the colours multiple times each frame, this will give each region (between each interrupt) it's own colours increasing the number of colours on screen. Each region is 52 scanlines in height, and the whole screen in width. Note that the colours must be set for each region for each frame to maintain them, and that the pixels within each region are still limited to 4 colours in mode 1. The colour regions like this are ideal for having different colours for the HUD and for the main game area.