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
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.
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.
Teil des Programmierjobs: das erwartete ist eine Linie des Characters „1“ auf der 3ten Linie des 8*8 Grids . stattdessen passiert da was ganz anderes. Irgendwie ist schon was da, aber auf jedem zweiten Tile und irgendwie schiebt sich die Grafik nach oben (fehlerhafte Bitverschiebung) – das würde auch die Falschfarben erklären.
Fazit: Es funktioniert überhaupt nicht, oder nur wie ich es bis anhin getestet habe.
Gesellschaftliches Fazit: Anders als eine reine Philosophie kann ich hier testen, was aus den Regeln wird, leider. Ok Philosophien können dann Gesellschaftlich weit gefährlicher sein, weil sie auf Menschen laufen als dieses Menu.
Als GameDev interessiert normalerweise das Spiel. Hier liegen die Herausforderung, das Management von Spielmechanik, Interaktion und Darstellung (Displays: Grafik, Music). Und dann muss man sich um das Drumherum kümmern also Titelbild und Menus. Das ist eine beschwerliche Sache. Aus Programmiertechnischer Sicht der 80er Jahre: Vorallem eine Statemachine, Textroutinen. Alles Dinge die eher mühsam sind – GUI halt. Dazu kommt das Fehlen von Frameworks für diesen Frame um Spiel herum. In diesem Sinn: Es darf nicht unterschätzt werden, wieviel Zeit damals auch für dieses „Drumherum“ genutzt werden musste und beim Betrachten von Games sollte auch dies Einfliessen.
Denn klar ist – das zeigt die Demoscene – hier wäre viel möglich gewesen, aber es findet sich sehr wenig selbst in den Menu dazu. Die Menus sind meist schlicht, funktional. Und dies hat noch einen anderen Grund: Wäre das Menu zu fantastisch würde es den Hauptteil ausstechen und das Spiel sähe ’noch‘ langweiliger aus.
Interessant ist eigentlich, dass die Cracker-Bewegung auch angefangen hat in Richtung Sammlung zu gehen. So entstanden zunehmend – auch dank dem zunehmenden Einbau von Komprimierungssoftware bei normalen Cracks, weil die Disks ‚randvoll‘ waren – Disketten mit 3,4 Spielen drauf. Neu musste natürlich auch Auswahlen angeboten werden. dadurch entstand dann wiederum ein Medium diese Sammelcracks, die wieder buchartiger waren. Dabei wurden diese Sammelcracks nummeriert, so dass man tatsächlich Games hätte sammeln können mit einer Gruppe. Anders gesagt: Es waren nicht mehr Einzelcracks sondern eine Art Cracker-Games Library spezifisch für bestimmte Crackersgroups.
Die Organisation des Atari ST mit 16 Pixel-Zeilen basierten Bitplanes begrenzt Fehler, während sie beim Amiga immer grossflächiger sind. Hier nun mal ein Bug, der fast schon an einen Amiga-Bug auf dem Atari ST erinnert.
Hier müssen 16 Bytes bewegt werden, um die Hintergründe der Softwaresprites auf dem Atari ST wieder herzustellen. Darum muss der alte (gesavte) Hintergrund wieder kopiert werden. Das sind 8×2 Bytes in Worten 2 Bytes (move.w) insgesamt 16 pixel in 16 farben. In der zweiten Version kopiert man 4 mal 4 Bytes per move.l – LongWords.
