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)

(One)ScreenLevels haben oft verschiedene Aspekte: einen levelbasierten Aspekt (Spielmechanik-Funktion) und einen optionalen Grafischen Aspekt (Zusätzliche grafische Funktion – evtl. sogar StoryTelling).

Tilebased Levels & Grafiken könnten folgendermassen unterteilt werden.

Tile-Hidding-Graphics (Default)

Grafik per Blöcke zu genieren war in den 80er-Jahre 8Bit/16Bit Homecomputer oft die einzige und schnellste Art Grafik zu produzieren. Dabei konnte man auch mit wenig Daten grosse Welten generieren. Dies war auch in den meisten Spielkonsolen fest eingebaut als Hardware. Die Idee dabei war aber immer auch, die Tiles beim Design zu verbergen, so dass gar nicht auffiel, dass es sich dabei um ‚geklötzelte‘ Grafik handelte (wie wir das im Alltag auch erleben). Die radikalsten Beispiele dafür wären etwa im 16/32Bit Bereich Xenon II und ähnliche Spiele. Hier geht es darum keine einzigartigen Grafiken zu machen wie etwa in DefenderOfTheCrown, sondern um grosse Landschaft zu gestalten, die man passiert. Man kann auch sagen „2D-Open World“ (vgl. dazu 3D-Grafiken zur 16/32Bit Zeit). Mehr zum konkreten Tilebasierten „Tile-Hidding-Graphics“ findet sich hier: Tiles-based-Design und Pixeln (Erfahrungsbericht – Amiga) oder auch hier: Power of Tile based (digitales) Design – Design mit Typendesign oder hier Tilebasiert II – Vor- und Nachteile (wird upgedated). Welt erscheint hier einzigartig. Wie oft die organische Welt wahrgenommen wird. Während Wiederholung und Repetition gleicher Objekte/Abschnitte eher an industrielle und damit menschliche Produktion erinnert oder Trivialer: Die Kultur wiederholt sich, während die Natur visuelle Wiederholung eher unwahrscheinlich hervorbringt. Hier geht es um Individualität (organisch) während es beim „Menschlich-Künstlichen“ meist um die Vervielfältigung geht.

Tile-Showing-Graphics

Neben diesen „Tile-Hidding-Games“ gibt es aber auch der bewusste Reentry der Tiles – gerade bei Spielmechaniken, die auf Klötzchen setzen wie beim Nachfolger von Breakout Arkanoid II etwa. Hier werden bewusst Pixelige Dinge als Inhalt genommen (die natürlich keine Pixel = 1 farbig und eine Information im Videoram mehr sind), die grafisch längst passé sind. Es ist also eine bewusste Referenz an frühere Stile von Games, die hier quasi durch die Spielformaten/Spielmechaniken legitimiert ist.

Arkanoid I / II

Im Folgenden etwa leiht sich das Spiel Arkanoid den Gegner aus von Space Invaders und zwar nicht die Masse sondern einen Gegner und macht ihn statisch, bleibt aber dennoch dem Motto von Breakout treu: Die Gegner sind die statischen Paddles (Multiplayer Pong) – hier formieren sie sich zu einem SpaceInvaders. Sie werden quasi direkt zur materiellen Wand.

2014

Except an assembler coded thing. This can be a ‚original‘ because it runs natively on a maschine. But of course, you learned somewhere how to code and what the assembly is like. But theoretically you could do it all on your own.

Die Crackerszene hat es immer getan: Sie hat alles ‚entwendet‘, was es so gab, Grafiken, Sprites und vorallem Musik. Es finden sich oft Teile von Spielgrafiken oder Sounds in den Crackerintros. Besonders beliebt schwierig herzustellende Sachen: Wie Titelscreens oder Animationen. Ein Riesengrosser REMIX wie das der Rest der Kulturszene auch gemacht hat. Es lassen sich sogar viele Tropen finden in diesen Demos, die immer wiederkehrend sind etwa Arnold Schwarzenegger aus Total Recall bis selbstverständlich Terminator, hier spielt man dann doppelt damit, dass die Pixelwelten eines Tages ausbrechen könnten ins Reale. Robots in Action. etc Die typischen Visuellen „Tropen“ sind Bälle, Muster, 3D-Muster, 3D-Bälle, Schriftzüge in allen Grössen und Farben, Sterne, Sternenhimmel, dann Vektoren, Drahgittermodelle, Polygonmodell, Texturierte Objekte und 3D-Objekte wie Bälle und dann der Würfel.

// Tipp: Am Anfang gibt es eine Demo (siehe Youtube-Default-Bild) von Scoopex, wo legitimiert wird, warum der Text scrollt.
// ToDo: Tropeninventar anlegen