Und hochladen: MSA/Zip.

http://absencehq.de/atariaviary/?id=740948

Selbst heute – im Zeitalter von Web, Google und Co – ist das Finden von funktionierenden Beispielen etwa für eine einfache Routine etwa für die JoystickAbfrage ein mühselige Aufgabe. Man findet etwas, testet Code, versucht ihn zum Funktionieren zu bringen und es läuft meist nur ein Teil oder gar nicht. Dabei geht es um Assembler Dialekte und einfach Sachen, die nie richtig gingen. Es ist zum „Haarölsäiche“ wie man im Schweizerischen vor 70 Jahren zu sagen pflegte. Nicht dass es auch sonst viel „Nicht-Funktionstüchtigen Code“ gibt, aber hier ist es schon nochmals eine andere Liga. Dies vorallem dann auch für eine Plattform, die heute nicht mehr so stark bedient wird.

Zusammenfassendes Schaudbild/Diagramm. Es stellt eine behauptete „Entwicklung/Erweiterung“ der Informatik dar (ab den 60er Jahren). Diese Entwicklung ist zumindest nachweisbar für die Entwicklung der Games und hatte damit dort Folgen.

Turnbasierte Informatik

Parameter-Interaktion (Exo-Turnbased-Programm-Interaktion)

In den Anfängen der Computertechnologie war die Standardisierung klar: Programme bekamen ihren Input am Anfang als Parameter. Das funktionierte ähnlich wie ein heute standardisiertes Rezept (frühe Rezepte waren nicht so – sie enthielten alles ‚durcheinander‘ und waren eher Hilfen zum Erstellen von Mahlzeit, als Programme) am Anfang kommen die Ingredenzien und danach läuft das Programm ab. Diese Art von Programmen finden sich früh. Sie sind eine Art direkte Übersetzung aus der Mathematik. Variablen in Formen. Diese definiert man, der Rest wird berechnet.

Immer wieder liest man diesen Satz

// Aus der „Dokumentation „The Art of … “ siehe unten

Die Demoscene soll sich also durch Nummern ausdrücken?

Am Anfang des Prozesses stehen Algorithmen, diese werden meist in einer Programmiersprache geschrieben und dann in Exes, ausführbaren MaschinenCode übersetzt. Dieser wird dann ausgeführt vom Computer und generiert in der Sprache der Mathematik Geometrie oder anders gesagt Grafik.

Das ist nicht die finale Version der Atari ST-Grafik.

Die Tilebasierung ist ein mindestens 5faches mächtiges Designtool – es ist geradezu ein Designregelsystem gepaart mit Funktionalitätsregeln:

1. Das visuelle Design der einzelnen Tiles – visuelles Regelsystem
2. Das Design von grossen Flächen aus Tiles (proceduraler Anteil) – visuelle Flächenregeln
3. Das Designen von Übergängen – Intertile Regelsystem
4. Das funktionale Leveldesign
5. Die Möglichkeit jederzeit das gesamte Design zu ändern – Digitale Eigenschaft

Viele dieser Dinge gab es schon vorher etwa bei Kacheln, Fliesen. Neu sind allerdings die Instant-Veränderungsmöglichkeiten. Hier kann alles in Echtzeitgeändert werden: Das ganze visuelle Regelsystem. Es erlaubt geradezu in unsinnigerweise die visuelle Umgestaltung in Sekunden. Hier ist die Power von Regelhaften Design in den Fingerspitzen. Kybernetik Designtools in Höchstform.

ToDo: Mögliche gesellschaftliche Dimension: Letztlich werden hier visuelle Regeln geändert und da das gesamte aus diesen Regeln besteht ändert sich auch das System. Eventuell spiegelt sich hier ebenfalls kybernetisch, was in der Gesellschaft jener Zeit passiert. Mit einigen wenigen logischen Einheiten (die verändert werden), wird Gesellschaft gemacht. Man könnte die Globalisierung der 80er Jahre lesen als eine Durchsetzung von wenigen Tiles, die das ganze bestimmen. Dabei kann das Aussehen dieser Tiles jederzeit geändert werden.

Im Spiel gibt es einen Bug, das Restore der Sprites/animierten Blöcke funktionierte nicht. Deswegen überschreibt nun ein künstlicher Wert (Grünstreifen) das zu Restaurierende. Damit wird versucht herauszufinden, was da schief läuft und als erster Schritt, was passiert eigentlich. Das Ganze ist ästhetisch fast so interessant, wie das Spiel danach.

Die ersten Prototypen von Imp89 [Assemblerphase] versuchen Spiele zu sein, die den Ideen der ‚grossen‘ Spiele/Demos folgen. Sie versuchen also diese Spielmechaniken und Stile zu simulieren.

Konkret gibt es nicht soviel Einfluss aus anderen Bereichen. Es wird wenig versucht einen eigenen Stil zu entwickeln. Eventuell gibt es eigene Entwicklung in der Grafik bei Dingen wie Büchern etc. Vorlagen sind eher Arcade/Spielhallen-Games, die verkauften Homecomputespiele (Hits) und die Demoscene.

In Sachen Spiel gibt es vermutlich falsche Vorstellungen zu den benutzten Techniken. Dabei ist der benutzte Computer Atari ST nicht gerade hilfreich, da er kein „Videogame-Computer“ ist. Er bringt fast nichts mit wie Hardwaresprites, Scrolling, Musikroutinen (YM). Die Magazinartikel oder Bücher sind dürftig – etwa 1987. Anders gesagt: Es muss eigentlich alles selbst gemacht werden. Ein Fehlen von anderen Ressourcen und Programmierinteressierten (ausser meinem Bruder) in der Peergroup half dabei auch nicht. Die nächsten an Spielprogrammierung interessierten Kollegen war in der Kantonsschule. Dieser hatte einen PC (MS-DOS) und das war dann noch jenseitiger. Er programmierte mit einem Kollegen zusammen ein Tetris in PASCAL.

Deswegen basieren einige Prototypen auf Falschannahmen (In Technik und Konzept) und sind viel zu kompliziert im Vergleich zu den Lösungen in publizierten Games nach heutigem Wissen.

Was sind „dreckige“ Grafiken? Grafiken könnten Grafiken sein, die nicht versuchen „reine“ Übergänge zu haben, sondern ‚Dreck‘ simulieren – also ‚beschmutzte“ Grafiken im konkreten Sinn sind. Oder anders gesagt: Es werden Objekte dargestellt, die beschmutzt oder schon sehr benutzt aussehen.

Die Grafiken erwecken nicht die Idee von „Hell und Lustig“ – diesen typischen Biedermeierstil den man in vielen frühen Grafiken entdeckt.

Dieses Sprite hier macht den Eindruck – nicht „Hell und lustig“ zu sein. Die Frage ist nun: Liegt das daran, dass nur die Farben anders sind oder ist es ein Mix aus mehr genutzter Farbraum und grössere Auflösung.

Dagegen spricht, dass es schon früher „dreckige“ Grafiken gibt, etwa auf dem C64. Allerdings war da das „dreckige“ eher „brute“. Die Grafiken waren nicht detailliert genug. Siehe etwa erste Spiele.

// ToDo: Beispiele suchen für die Frage der „Schmutzgrafiken“
// ToDo: Konkreter Erarbeiten, was mit Schmutz gemeint ist
// ToDo: Vergleich 70/80er Jahre Filme ohne Schmutz und Benutztheit (Nutzungsspuren)
// ToDo: Ähnliches Problem bei Filmen der 70/80er Jahre – die Modell in Filmen waren echte Modelle, danach oft gerenderte Modelle – diese waren mehrheitlich Clean. Erst später wurde wieder Dreck und damit Gebrauch simuliert.