Hier virtuelle Noch-nicht-Sprites auf dem Atari ST. Virtutelle Sprites bedeutet ein Riesenaufwand an Aufwand für Storen des Hintergrunds, Zeichnen darauf, Darstellen, dann wiederum Löschen. Da das Ganze nicht ohne DoubleBuffering läuft, muss jedes Spriteposition beim Zeichnen abgespeichert werden im jeweiligen DrawScreen, dann wird es angezeigt im DisplayScreen und anschliessend muss es wieder gelöscht werden, wobei das akutelle Sprite schon weiter ist. Das war beim Amiga letztlich nicht anders neben den „spärlichen“ Sprites des Amigas. Dort machte das Speichern und Zeichnen dann der Blitter, der Administrationsaufwand war sonst derselbe. All dies machten sonst Hardwaresprites ohne irgendwelchen Aufwand: 0% Rechenzeit.
In diesem Sinn waren Consolen immer besser dran für Entwickler*. Die Kosten allerdings dort zu entwickeln waren astronomisch im Vergleich zum Preis eines Computers.
Und ja dann begann natürlich ab 92/93 die 3D Zeit und damit waren Sprites nicht mehr StateOfTheArt technisch.
Das Ganze funktionierend mit einem Darstellungsbug.
Der Code als These, die angewandt im Computer ganz was anderes tut. Eine stetiger These-Falsifizierungsprozess = Coding. Und die Frage: Wo liegt das Problem? Wo liegt das andere?
Der Code rechts sollte das links mit Streifenpixeln (%010101) überschreiben. Aber das sind keine Streifen! Auch nach 20 Minuten umschreiben nicht.
Debugging ein hässlicher Sozialisierungsprozess an eine Maschine – es ist ein anrennen gegen die Maschine: „Lerne deine Turingmaschine!“
Assembler-Coding für den Atari ST im Gamebereich bedeutet: Alles selbst machen. Die Hardware ist letztlich nicht mehr als der Prozessor der Motorola 68000. Darum ist praktisch alles von einem selbst. Man hat die völlige Kontrolle. Alles ist die eigene Schuld aber auch: Keine Coroutinen, keine CustomChip wie der Amiga. Jedes Kopieren alles 100% der eigene Code.
Anders dagegen der Amiga, hier gibt es „Sprites“ und den Blitter/Bobs. Gerade der Blitter ist ein magischer Prozessor. Da kann, muss man viel wissen, bis man nur irgendetwas kopieren kann. Aber dann ist es eine Erfüllungsmaschine. Wobei eben auch stimmt, dass man nicht so genau weiss, wie dieses Erfüllungsmaschien funktioniert und damit auch viel aus der Hand gibt.
Der Atari ST folgt damit eher in der Tradition der Computer während der Amiga mehr den Spielcomputern folgt wie dem C64 und ja auch als das designed wurde: ein Spielcomputer. Es erstaunt deswegen auch kaum, dass am Ende der Tage der Spielcomputer im Spielbereich die Nase vorne hatte und viele Games in CH entstanden, weil der Amiga war dann doch einfacher für Games ohne Tricks wie Vorshiften von Sprites etc. Und der Sound war natürlich wirklich digital.
Interessanterweise beginnt mit den 68k Homecomputern auch die Skalierbarkeit anders zu werden. Es ist nun möglich auf der Ebene des Prozessors wie auf der Ebene der Coprozessoren, zu skalieren.
MOVEM (68k-Command)
Der 68k besitzt etwa den MOVEM-Befehl, damit lassen sich ganze Speicherbereiche kopieren. Möglich sind damit 8 Longworlds der Datenregister D0-D7 wie auch Addressregister von A0-A7. Also im Gesamten sind dass 8*4 + 8*4 Bytes. Das heisst, es lassen sich gleichzeitig 2*64 Bytes direkt verschieben ohne einen Blitter (grafischen Prozessor). das sind 2*64 also 128 Bytes.
Das sind etwa beim Atari ST in Bildpunkten: (128/4)*8 Pixel = 256 Pixel – also fast eine ganze Screenlinie.
Das heisst auch, dass man damit bei grösseren Sprites einen Vorteil hat gegenüber kleineren Sprites, die etwa nur 16 Pixel breit sind, hier bringt der Einsatz von MOVEM nicht viel. Allerdings spielt hier ror.l und rol.l auch eine Rolle in der Effizienz.
Blitter Amiga später Atari ST
Noch radikaler sieht es natürlich beim Einsatz von Grafischen Prozessoren aus wie dem Default-Blitter des Amigas. Hier spielt die Grösse (Fläche) des Grafischen Objektes zwar eine Rolle, aber viel weniger als die einzelnen Operationen des Blitters – hier ist einer der Flaschenhälse die Anzahl der Blits.
[Dieser Kommentar wird in einen anderen Blog verschoben, sobald dieser steht.]
Zunehmend wird der Begriff „Industrie“ verwendet im Bereich des Gamedesigns in CH. Etwa im folgenden Artikel/TV-Beitrag zum neu eröffneten Gamehub von den Machern selbst (aber er taucht auch in Gesprächen, Selbstbeschreibungen auf):
Der Begriff wird hier bewusst benutzt. Es scheint als Abgrenzung – als eine Art „positives“ Label – zu sein. Er folgt damit dem längeren Diskurs der „Kreativwirtsschaf/-industrie“. Einem Begriff, der eingeführt wurde, um zu zeigen: „Wir sind wichtig, wir setzen soviel um“. Dabei geht es auch um einen Sammelbegriff, da die Kreativbranche meist aus vielen kleinen Betrieben besteht (im Vergleich zu Sony, ABB etc) und damit nicht unbedingt dem Konzept von Industrie entspricht.
Industrie
Normalerweise wird der Begriff Industrie vorallem für die Grossindustrie verwendet. Also Unternehmen mit 100+ oder eher 1000+ Mitarbeiter, die im grossen Stil Produkte herstellen. Massenprodukte.Der durchschnittliche Betrieb mit 5-15 Mitarbeitern sieht sich dagegen eher als „Mittelständler“ – auch wenn viel produziert wird. In der Kategorie „Industrie“ gibt es wenige in CH – vielleicht GIANTS und die FUMINA(?) – 40+.
Das „Hüslipapier“ ist konstitutiv fürs Gamedesign der 80er Jahre und das auf mehreren Ebenen. Wie bei anderen Medien auch entstehen die neuen Produkte oft zuerst in den ältern Medien, also in den Medien, die von diesen später ’simuliert‘ werden (The medium ist the message).
Rechner und -papier und Gesellschaft
Und so ist es Papier, damals frei verfügbar und eben gerastert. Das Hüslipapiert dient zum Rechnen (darum auch Rechenblock) wie zu Schreiben. Dabei hilt das Raster. Es passt damit auch politisch noch in die sehr rastrige Welt der 80er Jahre. Teilweise gilt das karrierte Hemd auch visuell als das Hemd des Kleinbürgers. Die Welt hat gerade angefangen sich aufzubrechen und sich zu „individualisieren“.
Programmieren auf Papier
Als am Anfang Computer noch teuer war, wurde auch diesen Blöcken vorprogrammiert – auf Papier programmiert. Man hatte noch keinen Rechner und darum blieb einem nichts anderes übrig. Aber auch Formeln wurden benutzt, erstellt. Hier ging fliessend über vom Papierrechnen zum Computerrechnen.
Simulation der Turing Maschine
Das Häuschenpapier war geradezu der Ausgangspunkt für die Digitalisierung, das Medium, das in den Computer „digitalisiert“ wurde. Oder anders gesagt: die analoge Grundlage der virtuellen Turing Maschine. Der analoge Rechner.
Execl und Array
Aber nicht nur auf der Ebene des Rechnens spielte das ganze eine Rolle, sondern auch im Grafischen. War doch Grafik am Anfang nichts anderes als Pixel-Arrays. Und nichts anderes ist natürlich auch das Häuschenpapier, ein riesiger Array oder härter: der Vorläufer des Excelrasters.
Zeichnungsprogramm
Und da Grafik in der Homecomputerzeit auch immer Array war, ist es kein Wunder nutzte man die Kästchen auch als Zeichnungsprogramme, um sie danach von Hand zu digitalisieren. [0][0][1] wurde dann einfach 2^3*0 + 2^2*0 + 2^1 * 1 = 1. Es war also auch eine sehr gute Sache Digitales abzubilden, damit umzugehen und es zu verwandeln. Sei es für Klötzchen oder für Sprites
Leveleditor
Die nächste wichtige Tool ist der Leveleditor. Damalige Spiele waren – wie die Zeit – aus Tiles aufgebaut. Komplexität entstand aus einer Art Tile-Atomen. Und dies ging natürlich ebenfalls fantastisch damit. In diesem Sinn entstand die grosse Welt als Leveleditor auch oft im Hüslipapier und wurde später „digitalisiert“, was heisst übertragen.
// Vgl. Paradigma des Rechners – zx81 und die Idee des Rechners – ausbaubar mit Drucker – Basic Einführung – Rechnen mit dem ZX81 > BlogEintrag
