4*16px is done by using the modulo-value of bitplanes, modulo-shifting isn't smoothscrolling, but take for example a shift of 58px => 3*16px +10px, this will be 48px moduloshift and then 10px Hshift.įor this to work the bitplanes have to be setup to be larger than the wisible part, in the case of max 80px shifting a 320px wide screen has to be made at least 320px + 64px = 384px (moduloshifting values are dependant on the difference of the width of the bitplane and the screen). 80px is a chosen value, calculated from 4*16px + 16px, of which the lonely 16px is the same 16px shifting as above.

The 80px H-shift is a little more problematic. At the end of each image the Hscroll-value is set to 0, as otherwise graphics after moving image would float sideways according to the last set Hscroll-value. In this demo there are copperbars put behind the moving images, but are not important for the effect. If playfields aren't setup, then the same value has to be set for both PF1 and PF2, otherwise colormissmatching (on binary level) will occour.

Bits are Playfield 1 horizontal scrollvalue, and bits are for Playfield 2. Both shiftings are 100% made with the Amiga chipset, the CPU only tells the Copper what to do in a copperlist, and the Copper then adjusts the shifting.ġ6px shifting is made by putting a value in the interval of into BPLCON1-hardwareregister ($dff102). We will look at two different horizontalshifts, one is only 16px, but the other one is 80px. Horizontal shifiting on pixel-level is built-in into the Amiga chipset, but it is only 16 pixels wide. This time we will look at horizontal shifting, something that is also used in games with scrolling background. This is the secod codesnippet I upload here.

Horizontal shift