Gerade bei der Programmierung von virtuellen Sprites stellen sich Umstellungsprobleme. Aber sind virtuelle Sprites immer nur nachteilig? Eine Kurzanalyse zeigt ein detailiertes Bild

Eine wirklich wichtige Frage. Geht es doch um die Trennung zwischen Tool – dann lautet die Antwort sicherlich ja – und den digitalen Welten – dann lautet die Antwort vermutlich maximal Ja.

Als Linked-Post:

„Ist der Computer ein Medium?“
[Man könnte die Frage auch stellen: Ist die Taube ein Medium.]

– Als Tool sicher: Ja [auch bei der Taube]
– Als Digitale Welten-Holder: Ja indem es diese vermittelt. Vermutlich Nein als DigitaleWelt selbst. [Bei der Taube auch eher nein]

Die Frage scheint auch nach nach 55 Jahren Mainstream-Digitalisierung wieder aktuell viel offener den je.

Eigentlich ist der Effekt super, irgendwas an der Funktion für die Animation funktioniert nicht. Es flackert. Es wäre perfekt für ein Game – es würde die Gemachtheit dieser Welten zeigen und zwar bei den Objekten und nicht beim Gesamtbild. Es wäre keine Bildstörung.

Allerdings ist klar, für solche Brechungen und Fehler hat die Community kein Verständnis. Denn es haftet immer der perfekten Oberfläche der Fehler an und das „Das hat der Coder* nicht hingekriegt“. Das zeigt letzlich auch wie tief schöne und glattrasierte Oberflächen die Spielkultur verlangt.

Im folgenden Fall geht es auch darum, dass die Musik in Zusammenarbeit entsteht. Und wer will schon seine Musik in „Medienkunst“ haben. Insofern ist das Kapital „Credibility“ gerade in diesem Umfeld schon stark „gewichtet“. Nicht anders als in der Kultur. Der Fehler ist und bleibt ein Problem und ist nicht per se „Schön“ oder „Anders“. Dabei sieht man an ihm tief ins Innere. Hier zerreisst es das System.

Dabei ist auch nicht langweiliger als eine überdesignte Oberfläche.

// ToDo: A glitch game – vielleicht ein Shooter vgl. dazu auch der Glitch-Shooter von Daniel Z.
// ToDo: Glitch demo

Um schnell genug zu sein, werden auf dem ATARI ST vordefiniert (am Anfang des Spiels) all Sprites geshiftet (vorgeschoben 0-15 Pixel). Und hier lief anscheinend etwas schief. Es ist ein visuell interessanter Effekt, auch hinsichtlich der Frage, wie er entsteht.

Der simulierte = virtualisiert Atari ST im kleinen Fenster alias Käfig.

Vergleiche dazu der ominöse Amiga-Emulator auf dem ATARI ST.

Die 16Bitter verdoppeln teilweise die Auflösung. Dadurch wird aus einem Pixel, zwei Pixel und damit muss doppelt soviel designed werden oder positiver: Dadurch kann doppelt soviel designed werden. Hier am Beispiel des Ports von THE HOLY CUBE. Die Frage – muss nun die ganze Grafik umgestellt werden oder wird alles doppelt so breit? Links das Alte verdoppelt – rechts die neuen Möglichkeiten.

Grösse der virtuellen Sprites 16×16.

Umsetzung A: Linie bleibt Linie nun einfach feiner

Die Frage hier: Ist das noch eine Vektorgrafik?

In frühen Homecomputerspielen – nicht in den frühsten Arcade-Games siehe Space Invaders, die mehr den analogen Spielautomaten folgten – gab es viel schwarze Fläche oder allgemeiner Abstraktheit, davon zeugen eindrücklich die Screenshots der frühen vor allem Homecomputer-Spiele.

Viel Schwarz. Für viele Designer* ungestaltete Fläche. Als Beispiel einige Spiele mit viel Fläche.

Fairchild Cartridge 12

Diese Aussage/Erkenntnis ist naheliegend, aber dennoch weitreichend, weil sie den Sonderstatus der Spiels als kulturelle Errungenschaft neu definiert und sie in die Reihe mit CocaCola etc. Die Konsumprodutke der 80er Jahre. Dabei ist genau in den 80er Jahren die Frage, was sind elektronische Spiele? Reihen sie sich kulturell ein oder so zumindest ihre Entwickler*, sind sie etwas ganz Neues. Eigenes? Oder eben doch nur Warenwelt, Überkonsum und das selbst wenn ihre Aneignung eher privater Natur ist. Und wie steht es heute? Denn tatsächlich ist die Konsumware Game wie der Plastik-Junk der 90er Jahre: Viel zu viel. Schnell angeschaut, ausprobiert und weggeworfen.

Und wenn dem so ist, warum ‚fühlt‘ sich ein Spiel so anders an als eine Cola Dose. Warum liegen die Spiele nicht zertreten rum bzw. müsste man das einführen. Die digitalen Spiele in der Ecke oder jedes Spiel in der Ecke im Müll?

Bei einem Farbraum von 2^8 Atari ST 512 oder 2^9 Amiga 4096 gibt es eigentlich gar nicht soviele Farbnuance etwa für eine Rotskale. Das heisst konkret müssen für dieses Spektrum auch Mischfarben hinzugezogen werden.

Dabei spielt jede einzelne Farbe eine Rolle. Je mehr eine Farbe eine Mischfarbe ist, umso mehr kann sie auch bei anderen Übergängen „helfen“. Je mehr eine Farbe keine ist, umso schwieriger ist es, Übergänge zu kreieren. In diesem Sinn sollten wenig direkte Farben vorkommen und viele Mischfarben zu beobachten sein.

Das Recording ist Realtime aufgenommen worden anhand einem konkreten Problem im DevProzess der GameEngine und des Spiels (Port vom Amiga) HolyCube (Orginal C64 Game).

zeigt meine persönliche Arbeitsoberfläche. Diese besteht aus:

0. MacOS X
1. Compiler in der Shell
2. Editor (Sublime)
3. Atari Emulator: Hatari
4. eigenes GrafikTool für Tile-Design

Das anstehende Problem hier: Die Textroutine für kleine Texte (drawSmallText) scheint überhaupt nicht zu funktionieren. Dahinter liegt das Problem der Routine drawSmallBlock. Das normale System in der Engine ist 16×16 Pixel gross. Für die Darstellung von kleineren Texten (Lauftext) wurde zusätzlich ein 8×8 Font erarbeitet. Die Blöcke sind alle nacheinander abgelegt in 2 Bytes (16Pixel) * 16 Linien.

Dieser 8×8 Font findet sich im Tiledesign-tool in den Blöcken 2+.

Der Screen des Atari ST ist aufgebaut nach Linien. Eine Linie besteht aus jeweils 16 Pixeln in 2 Bytes*4 Ebenen. Die Bitplane-Anordnung ähnelt damit mehr dem C64 als dem Amiga, wo die Bitplanes pro Wert auf 4 verschiedene Bereich verteilt ist.