Der Video, das Mittel jener Zeit, um eigene Realitäten festzuhalten. Eine Fahrt an die
Part 1:
Part 2
Part 3
Der Video, das Mittel jener Zeit, um eigene Realitäten festzuhalten. Eine Fahrt an die
Part 1:
Part 2
Part 3
„Wie setzt man Sprites vom C64 um die 25×21 Pixel gross sind, der Amiga aber nur 16*x Pixel als Sprites zulässt? Die Grösse bringt man ja hin aber sonst (16×21 Pixels)?“
Die Antwort von einem bekannten Portierer von damals paraphrasiert: „Da benutzt Du den Blitter“.
Und ja so hart kann man es aussprechen. Mit dem Amiga und seinen Customchips endet auch ein Teil der direkt Hardware basierten Idee von Sprites und der Hardware basierung und Spezialisierung im Allgemeinen.
Der Amiga ist damit auch Teil der sich langsam fortsetzenden Virtualisierung der Digitalisierung ab Mitt der 80er Jahre.
Gibt es goto auch in C, Java oder C#? Da denkt man nein, das kann nicht sein. Das war doch das Argument gegen Assembler – nie wieder GOTOs und damit schwer les-, wart- und erweiterbaren Code. Schon gar nicht bei Sprachen mit VM wie Java oder C#.
Und dann meint CW bei einer Diskussion am Abendessen – alles Coder*: Doch das gibt es weiterhin. Und ein Blick ins Netz – altmodische Google-Suche – zeigt: Ja es gibt es als GOTO/Labels-Komplex. Es ist etwas nachdem man gar nicht sucht, wenn man denkt, es gibt es nicht.
Die Begründungen dafür (es nennt sich nun Goto/Label) sind die alten: Wie kommt man möglichst schnell aus einer tiefen Verschachtelung raus.
https://www.geeksforgeeks.org/goto-statement-in-c
Und noch unglaublicher Java:
https://www.geeksforgeeks.org/g-fact-64
Keine Gotos scheinen zu kennen Javascript, Python.
Das sind natürlich im ersten Moment schlechte Nachrichten, weil es nun diese Möglichkeit wieder gibt und im zweiten Gute: Man kann es im SizeCoding eigentlich wieder nutzen.
Statt
timeToWait(100);
timeToWait( int z ) {
for (int i=0;i<z;i++) {
// [...]
}
}
Das hier – die Sprungmarke timeToWait direkt als Zählblockmarke:
Die Gefährlichkeit liegt natürlich in der Lesbarkeit, Wartung und bei Erweiterungen des Codes.
Es ist eigentlich eine alte Frage: Wo ist dieser Space, der im Computer entsteht? Wo ist der Regelraum?
Selbstverständlich gab es früh die Schnittstelle zwischen dem „digitalen“ Regelraum ins ‚Analoge‘ – so wurde der Cyberspace auch analogisiert – Plotter (Zeichnender Stift) waren nicht umsonst sehr beliebt als Displays von früher digitaler (meist algorithmischer) Kunst, es wurde gedruckt (Rasterdrucken) oder sogar in Luftschwingungen übersetzt als Musik. All das ist eine Veränderung in der ‚analogen‘ Welt – hier ist alles klar.
Aber der Rest? All die digitalen Bilder – existieren nur im Moment. Sie sind eine Realisierung des Konstruktivismus. Aber wenn sie ‚laufen‘, wo sind sie? Wo leben all diese NPC, wo bewegt sich mein Avatar. Wo ist der Text der Webseite? Leben die Avatare / NPCS – wie einige Kinder glauben im Display – früher im Fernseher? Eingequetscht wie in LittleComputerPeople im Haus im computer und verkleinert – und ja früher waren die Fernseher (CRT) breit und gross – aber bei Flatscreens? Da wird es eng – dieses digitale Nichts.
Zu dieser Frage gibt es keine einfache Antwort. Es geht nicht um die analoge Erklärung: „Ach hier hast du den Speicher etc“, sondern es geht um die Frage: Wo in der analogen Welt befindet sich dieser Raum, in dem wir tausende von Stunden verbringen. Wo ist er verortet, wenn er denn verortet werden muss.
Rechtlich hat diesen Cyberspace längst die analogen juristischen Welten eingeholt und kolonialisiert. Er ist rechtlich und sozial ein Teil der Gesellschaft geworden. Aber darüber hinaus?
Betrachtet man die ersten Crackerintros, Demos und Games ist die Sache noch viel offener.
WeiterlesenEine Demo ist im besten Fall ein multimediales Produkt. Das heisst, die Grafik wie die Musik sind maximal auf einander abgestimmt. Dies ist in seiner Art nur möglich, weil es bei den meisten Demos weder um interaktive noch um zufallsbasierte Demos handelt. Dadurch wird ein klassisches Staging und Vertonung theoretisch möglich. Selbstverständlich gibt es auch die Möglichkeit direkt von der Musik Daten auszulesen und Effekte abzuleiten, aber auch hier wird oft eine direkte lineare Verknüpfung „realisiert“.
Könnte es sein, dass unser heutiges Design massiv vom Buchdruck und der Idee des „Eine Welt – ein Buch“ (zwischen zwei Buchdeckeln) inspiriert ist? Das die Gutenberggalaxies weit radikaler war auch in Sachen Gestaltung (Zumindest die Zentralperspektive hat der Buchdruck ja massiv gepushed (Giesecke)). Das Buch als Konzept, das so viel vom heiligen Buch mit dem einen (dreifaltigen) Gott als gemeinsames transzendentalen Signfikats mitgenommen hat? Dass also eine kleine eigene Logik möglich ist, aber eben nicht verschiedene? Und Design ist letztlich nicht mehr als visuelle Regeln Und zu viele Regeln sind unruhig, schwer lesbar bis subversiv? Dann wäre im Design das transzendentale Signifikat die mögliche Einheit (in der Vielheit)?
Betrachtet man die Versuche des Aufbrechen des klassischen Buches etwas in den 70er Jahren, so wird auch oft gerade das Design verändert und die Dinge geraten ins Wanken. Es gibt ja auch einige Beispiele dazu in Sachen Schriftgestaltung und Schriftnutzung auch aus dieser Zeit (Was passiert wenn man unendlich viele Schriften auf einmal hat vs. der alte Setzkasten?.
// ToDo: Plakate als ein offenes Buch mit einer Seite?
// ToDo: Das Einheitliche und das Schöne waren selbstverständlich immer Kategorien, die sich in so „Leitsätzen“ wie „Der schöne Geist im gesunden Körper“
Ist das Entwickeln von Demos ähnlich wie Basteln?
Kann man einfach rumbasteln, bis es gut wird?
Dafür spricht, dass man Demos immer verändern, erweitern kann. Als Entwickler* kann man sich ganz auf die Mikromechanik konzentrieren und von einem Trick vom Bottom-Up weitergehen. Man* kann darum etwas neues Herumbauen. Oder konkret ausbauen.
Die Demos müssen sich letztlich auch nicht daran halten, was sie hätten werden sollen. Das weiss ja nachher niemand, was hätte rauskommen sollen. Sie sind also viel „Produkt offener“. Es ist immer ein: „So ist es nun gut“-möglich oder ein „Lässt sich das noch gut inszenieren?“. Selbstverständlich spielen auch hier – wie etwa in Games – die existierenden Effekte eine Rolle und Demos werden damit verglichen. Dennoch scheint es einfacher. Selbst einfach Spiele wie PacMan sind recht komplex. Und selbst einfache Demos von Heute sind natürlich selbst in einfachen Effekten recht komplex. Dies gilt natürlich besonders komplexere Demos mit viel Verwaltungsaufwand (viele Sprites, DoubleBuffering).
Games sind im ersten Moment auch so. Allerdings spielt hier die Motivationsmechanik eine grosse Rolle und es geht nicht nur um visuelle Effekte, diese ist eher Ausdruck von der Spielmechanik als umgekehrt. Hier können zwar auch existierende Spielemechaniken erweitert werden. Das Problem dabei: Spiele sind Systeme und sobald man was ändert, verändert sich auch das Spiel. Insofern ist das Programmieren und anschliessende Ausbauen doch anders.
Die sicheren If-Bedingungen in Demos sind die Stages oder Effektezähler, denn nur so lassen sich wirkliche Übergänge verschiedene Stages/Effekte aneinanderhängen.
Die einfachste Lösung ist selbstverständlich – ein Timer und daran angehängt Ifs oder Cases für die Parameter.
Da gibt es keine Wiederholung, keinen Rahmen rundherum wie bei Games (Title, Menu etc). Es gibt kein GameOver. Keine Wiederholung. Fakten/Constraints, die eine Demo sehr viel einfacher machen in ihrer Konstruktion/Programmierung. Hier ist alles wie beim klassischen Film ( <> interaktive Demos). Die Zeit geht nur vorwärts in eine Richtung. Ihr Konsum ist linear – eventuell mit dem klassischen Literaturtrick, dass die letzte Zeile das Gelesene in ein anderes Licht rückt, aber mehr nicht. Dabei ist alles kontrollierbar und ausgeweitet wie ein Filmer letzthin sagte: „Ich verkaufe meinen Blick auf die Welt“. In diesem Sinn verkaufen viele Demoscener* ihren noch stärker konstruierteren Blick des Cyberspaces an die Welt.