Immer interessant ist, dass wenn man Interviews macht oder Leute zusammenbringt oder auch nur nachfragt, dies zu Aktivtität führt in schon vergessene gegangen Zusammehängen. So fangen Menschen an, Artefakte wieder zu sammeln oder aktualisieren Websteiten oder stellen sogar neue Webseiten ins Netz. Es kann aber auch dazu kommen, dass sich Leute wieder treffen und wieder Spiele spielen.

In diesem Sinn ist Forschung – an/mit noch lebenden Menschen vorallem – auch eine Aktivierung dieser Welten.

// ToDo: Kategorieren und Beispiele. – gameZfestival – Interviews – Ausstellungen

R. + B.

Vermutlich muss man anfangen, die verschiedenen Arten von Autonomie gerade Anfang der 80er Jahre genauer anzuschauen und die gut untersuchten wie die Autonomen Zentren neben die digitalen zu stellen.

	Autonome Zonen	Digitale Autonome Zonen
	„Location“: Basel https://www.bzbasel.ch/basel/basel-stadt/vom-ajz-zum-nt-areal-legendare-besetzungen-und-zwischennutzungen-in-der-stadt-basel-ld.1496138 (Basel)	„Location“: Basel Supaplex
Selbstverständnis	Revolution, Veränderung gegen die verhärtete Gesellschaft (Gemeinsame) Zukunft entsteht	Selbst Zukunft, Andere Analoge Vergangenheit (Autonome Zonen) (Digitale) Zukunft entsteht
Zugang	Analog öffentlich	Digital in privaten Räumlichkeiten evtl Teilöffentlich Computerclubs
Verteilung	Zentralisiert	Dezentralisiert
Raum	Analog begrenzt	Unendlich und abhängig von CPU, Memory, Display
Programmierung	Atome	Digitale Regeln
Player	Jeder*, der wollte	Jeder der Geld hatte für die Hardware und Software
Verfügbarkeit	Wenig, immer in Konkurrenz mit anderen Angeboten	Keine Konkurrenz im ersten Moment, Markt bei Produkten
Tätigkeiten	Musik, Konzerte, Unterhaltung, Entwicklung, DIY	Tool/Dev: _Grafikerstellung _Programmierung _Musik _GameDev Unterhaltung: _Demoscene _Games Alles DIY
Hauptidee	Neue gesellschaftliche Regeln, neue eigene Räume – neue Gesetze	_ Neue Welten erstellen? _ …
Vorbilder	_Revolutionen _ Freie Gesellschaften _ Umnutzung _ Ausprobieren/Experimentieren	_Demoscene _Arcades, aber auch neue explizte _Computerspiele _Communication: BBS, Internet _Neue Dinge, die nicht existieren
Kommunikationsmittel	Gespräch, Poster, Plakate, Graffiti, Film, Videorecorder und Videocamera Theater Demonstrationen Feste	Pausenhof Selbstlaufende Programme wie Digitale Welten, Demos, Games, OnlineGames (MODS), Disks, Diskmagazine, BBS, Telnet, FTP, Internet, Grossrechner Computerclub Crackerparty, Demoparty
Politik	Verschiedenste Richtungen	Freie Informationen / Daten / Games Meist unklar, wenig Angaben

Vielleicht kann man die Demoscene der Anfänge auch als Besetzung oder zumindest als Markierungszene sehen, also eine Scene, die diesen neuen Raum – In Ermangelung eines Begriffes – „kolonialisiert“ (sie trifft dabei nur auf ihren eigenen neuen Raum!). Damit wäre dann auch klar, wie diese Scene sich von der Crackerscene absetzt, die sich ja zumindestens noch an den ersten digitalen existierende Welten – den Spielen – orientierten, diese kolonialisieren, für sich nutzen und diese letztlich ‚entführten‘ als Vehikel und damit die Grundlage legten für eine völlig emanzipierte Form – kurz die Demoscene. Dies erklärt in einem gewissen Sinn auch, warum diese Scene sich absolut nicht an der Kunst/Designszene und maximal noch an der Musikszene orientierte – auch visuell. Hier ging es darum, möglichst viel neues „Land“ abzustecken, es zu erweiteren und das war fatal: auch nur um das technisch Machbare zu erweiteren. Für viele war das Ganze geradezu ein Kampf um Aufmerksamkeit mit Effekten und Machbaren. Oder anders gesagt: Entfesselte Konkurrenz – ganz im Zeitgeist jener Tage.

Das ist die Realität von Hardwarenahem Programmieren und gerade für Spielprogrammierung in 8- und 16-bit ist genau das, Visualität.

Der Code dazu: (ATARI ST)

// Jede 1 ist hier ein Pixel in der ersten Farbe von 16. Weil der Rest 0 ist, wird genau die Farbe 1 gezeichnet.

Die Geschäfte liefen nicht mehr gut mit dem Atari ST nach 1989 und so kam (nach vielen Blitter gestützten STs und TT-Ideen) dann der ATARI STE raus mit DigiSound, Blitter und Hardware-Scrolling. Diese Demo zeigt die Ideen von damals. Zu beachten ist die ganze Gestaltung.

// Persönlich Erlebtes: Geblieben ist von dieser Demo vor allem „Please load, I’m waiting.“.

// Eine Demo von 1989 mit vielen Spritess

It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted‘!

https://smfx.st/?sprites

Radikale aber auch interessante Äusserung, da sie den Nachteil vom Atari ST – nämlich letztlich ein CPU mit RAM zu sein – zum Vorteil macht. Hier geht es nur um Code.

Konkret geht es um Sprites – die Frage, wieviele virtuelle Sprite holt man aus der Atari ST. Hier gibt es eine lange Tradition, dies herauszufinden.

Eine der grössten Probleme an Assembler-Programmierung ist die Nachvollziehbarkeit nach der Erstprogrammierung. Es ist dabei wie bei PERL – das ganze ist schwer nachvollziehbar. Einige Gründe: Immer sehr an Assembler und damit dem Prozessor. Einfachste Dinge (in Hochsprachen) werden in verschiedenste Schritte aufgeteilt und es muss praktisch immer verstanden werden, was ist in D0 gerade?

Es ist wie wenn man in einer höheren Programmiersprache bestimmte Dinge nur in 8+8 Variablen (68kProzessor) rechnen könnte.

Oder noch konkreter: Es gibt einen TaschenRechner in der Mitte, da kann man Dinge rechnen. Im Fall eines 8Bit Computers sind das dann nur +1, -1 und dann muss man es wieder wegschieben. Dann kommt das nächste dran. Das funktioniert nur, weil man es programmieren kann.

[RECHNERCODEA]
Variabeln/Memory ----> [RECHNER]----->Variabeln/Memory
[RECHNERCODEA]

AssemblerCoding ist in einem gewissen Sinn, ein Arbeiten mit sehr wenigen Funktion. In einem 8Bitter etwa.

incrementA()
incrementX()
incrementY()
copyAX();
copyXA();
copyYA();
copyVarToAdress(var);
copyAToAdress(var);
…
compareA();
compareX();
etc.

dadurch wird der Code lange, repetitiv und schlecht wartbar.

// ToDo: ActionCoding-Beispiel
// ToDo: Eine solche höhere Programmiersprache!

Das Restoren des Background sind bei rein virtuellen Sprites wie auch bei BlitterSprites essentiell. Hier TheHolyCube ohne BackgroundRestoreing (Double Buffered)