Mehr Farben, weniger Kopierarbeit – und ein teurer Kameraschwenk
Entwicklungsstand vom 24.–25. September 2026, nachgetragen am 1. Oktober. Ergänzung zur Buildumgebung vom 30. September.
Die Frage nach 16 oder 32 Farben führte zunächst zu einer unerwarteten Entdeckung: Der emulierte A1200 lief zwar, seine Grafikbibliothek arbeitete in den bisherigen Demo-Läufen aber im ECS-Anzeigemodus. In der Startsequenz fehlte SetPatch. Die fünfte Bitplane ließ sich deshalb zunächst gar nicht öffnen. Ausgerechnet der Wunsch nach mehr Farben brachte also einen Fehler im Testaufbau ans Licht.
Mit SetPatch wurde AGA erkannt. Die früheren Zeitmessungen bleiben dokumentierte Ergebnisse ihres damaligen Aufbaus, sind aber keine passenden AGA-Vergleichswerte. Das ist besonders für den vorherigen Performancepass wichtig: Seine hohen Zeiten dürfen nicht stillschweigend als Leistungsgrenze des neuen AGA-Pfads weiterleben.
Wofür die zusätzlichen Farben gebraucht werden
Für den Vergleich blieb die Szene geometrisch gleich: 640×400 Bildpunkte, 48×24-Kacheln, dieselben Positionen und Masken. Die bisherige 16-Farben-Grafik wurde nicht absichtlich schlechter gemacht. In der erweiterten Szene zeigt sie jedoch, wie viele Aufgaben eine einzelne Farbe inzwischen übernehmen muss: Wasser, Anhänger, zweites Spielerfahrzeug und Bedienfläche teilen sich ein dunkles Blaugrau. Der Teich erinnert dabei eher an ein Loch im Boden.
32 Farben trennen diese Rollen. Wasser bekommt eine eigene Farbe, das zweite Fahrzeug ein deutliches Blau, der Mähdrescher hebt sich besser von Geräten und Weizen ab. Gebäude und Fahrzeuge gewinnen Schattenseiten. Nicht jede zusätzliche Nuance hilft: Die Feldzustände „gesät“ und „bearbeitet“ bleiben auch mit mehr Farben nur schwach getrennt.
Die Rechnung dazu: Ein reiner Bildpuffer wächst von 128.000 auf 160.000 Byte. Im protokollierten AGA-Vergleich kostete die komplette Szene mit fünf Bitplanes rund 13 Prozent mehr Zeit, ein Scrollschritt etwa 18 Prozent. Die endgültige Farbtiefe bleibt offen. Eine brauchbare Messung auf dem neuen Mindestziel fehlt weiterhin; das vorhandene 68030-Emulatorprofil ist dafür nicht kalibriert.
Der Blitter bekommt einen kürzeren Weg
Im anschließenden Scrollpass wurde aus der zuvor nur vermessenen Möglichkeit eine Implementierung: Maskierte Kacheln und Grafikobjekte nutzen jetzt überwiegend direkt programmierte Blitteroperationen. Eine vereinfachte, auf Gleichheit geprüfte Projektion spart zusätzlich Rechenarbeit. Ein Versuch für links abgeschnittene Grafiken hinterließ Bildfehler und wurde verworfen; dort bleibt der Bibliotheksweg zuständig.
Im gleichen AGA-Testaufbau sank ein Scrollschritt bei vier Bitplanes von rund 396 auf 278 Millisekunden, bei fünf von 466 auf 321 Millisekunden. Der Randtest meldete für beide Farbtiefen null abweichende Pixel und null veränderte Schutzbytes. Die protokollierten Bild-, Zustands- und Wiederholungstests bestanden ebenso wie 55 Host-Testgruppen. Eigener Assembler wurde nicht ergänzt. Das Ergebnis ist ein echter Fortschritt, aber noch weit von den 40 Millisekunden entfernt, die zu 25 Bildern pro Sekunde gehören.
Die Kamera bewegt den Ausschnitt – bis der Vorrat endet
Der nächste abgeschlossene Versuch zeichnete die Welt auf eine größere Bitmap. Solange die Kamera darin bleibt, wird nur der sichtbare Ausschnitt verschoben. Die Landschaft muss dann nicht bei jedem Kameraschritt umkopiert und am Rand nachgezeichnet werden.
Das funktioniert im isolierten Overscan-Test: Ein gewöhnlicher Kameraschritt ohne bewegte Objekte und ohne Spiellogik kostete ungefähr 8,2 Millisekunden. Diese Zahl ist ausdrücklich keine Bildzeit des vollständigen Spiels. Im Demo-Ablauf mit Spiellogik lagen normale Scrollschritte eher bei 122 bis 132 Millisekunden.
Am Pufferrand kommt die Rechnung gesammelt. Die größere Bitmap muss neu zentriert und ergänzt werden. Je nach Puffer und Farbtiefe dauerten solche Nachladeschritte etwa 393 bis 1.139 Millisekunden. Größere Puffer verschieben die Pause nach hinten, machen die einzelne Pause aber teurer. Der Hof scrollt damit günstiger im Durchschnitt – und stolpert gelegentlich umso deutlicher.
Die geprüften Bildausschnitte stimmen pixelgenau mit dem Referenzpfad überein. Trotzdem bleibt dies ein Machbarkeitstest, keine freigegebene neue Rendererarchitektur: Die feste Seitenleiste ist im Versuchsaufbau ungelöst, pixelweises Scrollen wurde noch nicht gemessen, und echte Hardware samt Bildsynchronisation steht aus. Der normale Renderer bleibt die Referenz.
Neue Planungsgrundlage, gleiche Amiga-Grenzen
Die Hardwarefrage ist inzwischen entschieden: Seit Entscheidung D-040 vom 24. September gilt ein A1200 mit AGA, 68030 ab 50 MHz oder vergleichbarer Leistung, 2 MB Chip-RAM und mindestens 8 MB Fast-RAM als Mindestziel. Der Nachweis für das vorläufige 8-MB-Budget ist noch offen; empfohlen sind 16 MB Fast-RAM. Der 68020 bleibt ein verbindliches Low-End-Testprofil für sichere Ausführung und gleiche Simulation, Savegames und Replays. Eine Grafikkarte wird nicht vorausgesetzt.
Mehr CPU-Leistung löst dabei nicht die Grenzen des Chip-RAMs und des Blitters. Genau deshalb waren Farbvergleich und Scrollversuche nötig. Die Messungen stammen aus FS-UAE, nicht von einem echten A1200; insbesondere die Scroll- und Overscan-Zeiten sind Vergleichswerte eines nicht zyklengenauen Aufbaus und keine Zusage für einen 68030/50.
Nach dem Rechnerumzug wurde am 30. September außerdem die Docker-Cross-Buildumgebung wiederhergestellt. Mit GCC 6.5.0b bauten die drei Standardziele für Vertical Slice, Fahrzeugmaßstab und Savegame-Test erfolgreich. Die erzeugten Amiga-Binaries waren laut Abschlussprüfung SHA-256-identisch mit den übernommenen Vorgängern. Das bestätigt den Neubuild, nicht einen neuen Emulatorlauf.
Grundlage: die Abnahmeprotokolle zum Vergleich 4/5 Bitplanes, Scrollpass 1 und Overscan-Scrolltest sowie der abgeschlossene Buildbericht. Die dort genannten Tests wurden für diesen Tagebucheintrag nicht erneut ausgeführt. Neue Spielaufnahmen konnten auf der aktuellen Umgebung wegen des fehlenden Testbootvolumes nicht angefertigt werden.