Gerade bei der Programmierung von virtuellen Sprites stellen sich Umstellungsprobleme. Aber sind virtuelle Sprites immer nur nachteilig? Eine Kurzanalyse zeigt ein detailiertes Bild
| Aspekte | HardwareSprites | SoftwareSprites (inkl. Grafikprozessoren wie Blitter) |
| Entwicklungsaufwand | Kein | Hoch. Verständnis des Bildmemoryaufbaus, Verstehen des BlitterChips falls vorhanden |
| Initialisierung | Teilweise aufwändig | Keine, ausser Vorberechnung dann Aufwand hoch |
| An/Auschalten | Teilweise aufwändig | Nicht vorhanden, werden einfach nicht mehr gezeichnet |
| Clipping | Kein Aufwand | Grosser Aufwand |
| Rechenzeit-Kosten Zeichnen (CPU) | Keine | Hoch Varianten: Vorberechnet vgl. Atari ST |
| Management | x/y vorhanden | Hoch (Retten des Speicherbereichs – 2x Onscreen/Offscreen/Restore) |
| DoubleBuffering | unnötig mehrheitlich | zwingend, grosser Aufwand Verwaltung, Objekte und Positionen |
| Collision | Meist vorhanden | Nicht vorhanden, manuelle Lösung, aber auch nicht so wichtig, da mehrheitlich Rechteck-Kollisionen verwendet wird |
| Anzahl | HardwareDefiniert (meist 8) | Rechenzeit abhängig |
| Nutzbar in Effekten wie Wasser (exotisch) | Nein | Ja |
| Im der freien Wildbahn | Meisten Consolen, TI-99 (sehr viele sprites), C64 (8 Sprites), Amiga (8 4 Farbensprites), | BBC Micro, Atari ST (Amiga mit Blitter, Atari ST mit Blitter) |