Der Atari ST war bekanntlich ein 68k-Computer schnell zusammengebaut, nachdem Jack Tramiel (gerade von Commodore) gewechselt trotz Zusammenarbeit mit der Amiga Firma, den Zuschlag dann doch nicht gekriegt hat und der Amiga an Commodore ging. Durch die sehr schnelle Entwicklung war der Atari ST ein richtiger Computer. Er bestand aus einem Prozessor und viel RAM. Ohne Hardware-Unterstützung mussten alle Sprites in Echtzeit berechnet werden. Darum gab es eher wenige davon. Bis ein Kniff auftauchte – man konnte diese Sprites ja vorberechnen. Das Problem ist nämlich auch hier: Der Screen ist in 8Pixel eingeteilt, man muss also Pixel über diese Byte-Grenze bewegen oder in Assembler „Rollen/Shiften“ und den überschüssigen Pixel dann im wieder im nächsten Byte einfügen etc. Ein komplexes und vorallem rechenzeitlastiges Problem. Da hilft dann eben alle 16 Verschiebungen schon vorher zu machen und einfach die geeigneten Blöcke zu kopieren bzw. zuerst die Maske auschhneiden und den Rest darüber legen. Und in diesem Bereich ist der 68k schnell mit movem- und co. Und macht damit fast die Vorteile des Blitters des Amiga wet..
Vereinfacht sieht dies Folgendermassen aus. Das wäre eine monochromer Screen (nicht erklärt: 16 Farben werden in 4 Layern untergebracht – Bitplanes):
Anbei sieht man eine solche automatisch generierte Masse von 16 x 2er Bläcken und daneben die Maske. Aus dem Spiel TheHolyCube (Atari ST) extra visualisiert, da die Daten nicht so nebeneinander liegen.
Damit erreicht man relativ einfach 32 * 16×16 Sprites pro Frame.
