Archiv der Kategorie: Uncategorized
Atari ST – 100% My Code vs/and Amiga – 75% My Code
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.
68k-Homecomputer: je grösser umso schneller

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.
Begriff „Industrie“ im Schweizer Gamedesign [Aktuell]
[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+.
Des Gamedevs/-designers* wichtigstes Tool (Homecomputerzeit): das „Hüslipapier“ oder das Blockpapier [KurzBeitrag]

// Mehr dazu: https://research.swissdigitization.ch/?p=3782
Hülsipapier
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
Wiederaufnahme des Spielens durch Interviews und Nachforschungen [Notiz]
Beat Suter, René Bauer
Ein Sideeffekt der historischen Forschung bei lebenden Personen und Gruppen, ist die Wieder- oder Neukonstituierung dieser Gruppen. Sie fangen wieder an zu spielen, sich zu treffen oder gar zu entwickeln.
Strich um Strich (Demo, Atari ST)
GFA Basic: Screen Buffering (Atari ST)
Interessant, dass es selbst DoubleBuffering in GFA Basic natürlich gab. Das Resultat lässt sich auch sehen.
Virtualisierung auch in Sachen Hardwarearchitektur und Software von Punchcards bis zu Betriebssystemen [Notiz]
Es wird immer wieder Vergessen, dass auch die Hardware vor den Homecomputern und zur/in der Mainframezeit virtualisiert wurde. Da waren zum einen die Entwicklungen von den Lochkarten zu den Computern und hier entstand dann ja auch das RAM für Random Access Memory. Das heisst letztlich auch die Virtualisierung oder die Unabhängigkeit von Daten und deren Verarbeitung. Siehe dazu auch Buch: Wie die Welt in den Computer kam (D. Gugerli) Auch die Zugänge In- und Output zu Grossrechnern wurden später virtualisiert mit den Terminals.
Einen wichtigen Schritt in der Virtualisierunggeschichte sind aber auch die höheren Programmiersprachen. Anfangs direkt in Assembler (Prozessorgebundenheit) entstehen mehr und mehr höhere Programmiersprachen wie COBOL oder ALGO oder die Lernsprache BASIC. Diese lassen sich egal auf welchem System einsetzen und übergehen damit die Hardwaregebundenheit. Das bekannteste Beispiel ist sicherlich C. Der Standard ermöglichte später das schnelle Portieren oder gar das Kaufen nur des SourceCodes zum Compilen auf jeglicher Hardware (Processor) und damit auch das Betriebssystem UNIX.
In diesem Sinn muss das Projekt „Digitale Virtualisierung“ als eine Tendenz betrachtet werden, die seit den Anfängen der Digitalen Revolution immer da war und letztlich auch ein Teil der digitalen Bewegung ist. Letztlich geht es darum so wenig Abhängigkeit und so viel Meta wie möglich zu haben. Wobei natürlich die Homecomputer- und Consolenscene das ganze dann verspätet zu den Grossrechnern nochmals „wiederholte“, um am Ende gegen die verkleinerten Grossrechner alias Mainframes mit den Grossrechnerbetriebssystemen zu unterliegen.
Gesellschaftlich spiegelt sich hier – als These – vermutlich die Idee wieder – Dinge unabhängig von Ort und Zeit laufen zu lassen. Also eine Welt zu schaffen, die kybernetisch überall funktioniert ohne störendes Lokales. Und so wurde letztlich das digitale Medium zum Träger einer Globalisierung nicht zufällig ab 1993 mit dem HTML-Standard und co.
Grafik- und Designentwicklung der Consolen & Homecomputerscene
Betrachtet man die Cracker/Demos der 80er und Anfang der 90er Jahre wird etwas schnell klar: das Gegenständliche ist schwierig.
TY-Constraints 1980-95: 160-320×200 Pixel mit 2,4,16, 32 Farben
Dabei hemmen mindestens zwei Sachen eine Direktübernahme von Content aus dem analogen Bereich (Zeichnung, Malerei, Photographie): es gibt wenig bis gar keine verfübaren Scanner und wenn es diese gibt dann muss mit Dithering oder anderen seltsamen Sachen gearbeitet werden wie etwa im Druck. Die Farbmöglichkeiten sind dabei ebenfalls minim: teilweise 2, 4 oder wenn es hochkommt 16 Farben aus einer Palette von 16 (bestehenden Farben C64) oder 512 (Atari ST) oder 4096 (Amiga) um ein paar Beispiele zu nennen. Aber noch viel einschränkender: die Auflösungen sind klein und orientieren sich am Fernseher. Es geht hier um 160 (C64) hoch bis 320×200 (ST) oder 320×256 (Amiga, PAL). Das sind nur 64 000 Bildpunkte (auf einem damals kleinen Screen). Dennoch: Farbverläufe lassen sich damit nicht machen und Flächen sind ein Problem.
Der eigene Stil – nutze die Constraints
Dadurch folgt das Screen-Grafikdesign nicht der erarbeiteten Logik von Gestaltung, sondern entwickelt eine eigene Welt. Diesen Welten – gerade im Gamebereich – stossen auf andere Herausforderungen als klassische Grafikentechniken, die mehrheitlich statische Fläche bedienen (Design) oder zwar Animation sind – aber noch mehrheitlich analoge Welten abbilden. Im Game oder der Demoscene geht es um Echtzeitkonstruktion von „Screen“.
Es kann also wenig übernommen werden. Dabei geht es auch nicht nur um das Design von Fläche oder das übermalen von Fläche, denn es gibt in Games ja auch immer Dinge wie Sprites, die über Fläche darüber gelegt werden und und und. Und ja all das muss designed werden für alle möglichen und unmöglichen Kombinationen. Es ist ein unsicheres Design. Digitale Welten besitzen in diesem Sinn eine „eigene“ Logik.
Die Gamedesigner* entwickeln sehr schnell eigene Ästehtiken dafür. Wie sich diese Ästehtiken unterschieden muss dringend erarbeitet werden mit Fragen wie: Wie kann ich mit so wenig Farben und damit Unterscheidung auskommen etc? Welche Rolle spielt die Interaktion etc.
Anders gesagt: Die Computergamerealität musste zuerst erschaffen werden. Es mussten Stile gefunden werden, die in sich funktionieren, interaktiv funktionieren.
Mehr dazu findet man in folgendem BlogBeitrag mit BlogEinträgen zu verschiensten Themen, wie mehr Farben, mehr plastische Grafiken und doch begrenzte Darstellungsmöglichkeiten durch die Auflösung und und und und …
Ein Post mit einer Zusammenstellung von einigen Posts dazu: