or at the very end for downloading as a large local website.
Behind the idea of a C64-MultiColorCamera is the “interesting” organization of the display/memory of the C64 (and also other 8Bit computers see Apple/Atari XE etc). These video memory concepts were more or less a hardware compression method to save expensive RAM. The multicolor (graphic) screen was 160×200 pixels. The video screen and thus the memory was not simply continuous, but was additionally “furrowed” or structured. The screen consisted of 4(x)*8(y) blocks with their own color logic. Only 4 colors were allowed – but the background color was the same for all of them! So there were actually only 3 designable colors in one block! The 4 colors can be selected from the 16 predefined colors. A block contained only 4 possible colors from 0-4, which required 2^2 per pixel or in other words a 1/4 byte. This makes a more colorful image possible than just 4 colors on the screen. The disadvantage is that it is difficult to create an image that works visually. It requires massive adjustments to this constantly changing (Sudoku) logic (manual rendering). This often results in small blocks with more uniform colors and therefore areas.
So sehr man den Vice-Emulator mögen kann. Er hat – zumindest auf dem Mac – keine Presettings. Es geht also nicht, einfach ein XYZ.PRG auf das Fenster zu ziehen und loszulegen.
Vorher muss das Ganze konfiguriert werden. Wer sich sowas ausdenkt und nicht mal die Cursor-Tasten per Default aktiviert. Ja der ist halt kein Menschenfreund.
// Alles in einem Byte – alle Kollisionen – untrennbar
Das es mit der Hardware-Collision nicht sehr weit her sein muss, zeigen eindrücklich die Hardware-Collisionsroutinen des C64. Hier gibt es die Routinen: Sprite-vs-Sprite und Sprite-vs-Background. Die Sprite vs Background fragt wirklich letztlich nur den Hintergrund ab. Die (pixelgenau) Sprite-vs-Sprite-Routine liefert einfach ein geflatetes Byte mit dem aktuellsten Collisionsstand. Also etwa (von links nach rechts zu lesen): 01011001
Das erste Sprite kollidiert gerade mit dem 4. oder das 4te und das 5te oder das Fünte mit dem ersten.
Das Ganze ist also maximal ambigue und deswegen auch nicht wirklich nutzbar und so – zumindest einige Blog-Artikel – auch nicht wirklich genutzt worden dann. Dabei ist auch hier die Frage – waren das Problem die Kosten? Ein Byte pro Kollision von Spritex mit allen anderen Sprites würde ja nur 7 Bytes mehr benötigen (1 verwendet man ja schon)! Der C64 ist ja bekanntlich eine auf Kosten optimierte Computerspielmaschine.
// Insofern schwierig zu verwenden etwa im Sizecoding, wo man dann nicht durch eine zweite Methode bestimmen kann, wer da mit wem kollidiert.
Dies hier sind einige Notizen zu einem Cafe-Gespräch rund um den C64 und Amiga. Damals wie heute. Die Gesprächsnotizen sind anonymisiert, weil das Gespräch weder aufgenommen wurde und es liegt auch keine Bestätigung zur Veröffentlichung vor. All dies wird in einem zweiten Gespräch nachgeholt werden. Dennoch sind die einzelnen Punkte gewichtig genug, sie als Fragen festzuhalten.
Einige, der diskutierten Themen:
Ein neues C64-Game
Es geht darum, wie komplex es heute ist ein neues C64-Game zu machen. Gerade wenn es sich noch an einen Klassiker anlehnt. Was darf übernommen werden, was nicht? Durch den Kontakt zu den Urhebern wird klar, die Rechte sind immer noch da und werden noch benutzt, etwa für RetroKonsolen.
Interessante Diskussion zur Frage, wie das Artwork des Titelbildes entstand und wie hier zuerst das analoge Bild entstand und erst danach die C64 Version erstellt wurde. Allgemein die Frage, wie arbeitet man heute zusammen – direkte Instant-Kommunikation, Emails.
Kurz vor dem Release wurde klar: Das Spiel ist zu Nahe am Orginal. Praktisch alles muss überarbeitet werden (Font bis Figur und Name) – in einem Monat.
Es geht auch um die Frage, der höheren Programmiersprachen. Wann und wo kommt und kam Basic zum Einsatz. Welche Basics gab es. Dies ist umso wichtiger, als dass der Gesprächspartner noch heute im Bereich Basic-Games unterwegs ist. Auch fürs nächste Projekt für den C64 arbeitet der Gesprächspartner wieder mit Basic als Grundlage, weil einfach Assembler für Management-Spiele nicht machbar ist oder zumindest masochistisch ist. Die Diskussion dreht sich auch noch darum, dass es Entwickler gab (vor allem grosse Entwickler?), die auf schnellen PCs kompiliert haben und das Ganze dann auf dem C64, Amiga ausprobiert haben.
Wechsel C64-Amiga oder die Aneignung der Amiga Technologie
Es gibt eine Diskussion darüber wie der Übergang von C64 zu Amiga lief. In der CHLudens Experimentellen Archeologie wurde klar, dass dies nicht ein einfacher Übergang war. In den Berichten von Damals wird es als „Befreiung“ – ein neuer „Möglichkeitsraum“ gesehen – die Probleme kommen eher nicht vor. Der Amiga hat – mit dem 68k – Dinge sehr vereinfacht: „endlich“ Rechnen mit Zusammenzählen, Multiplikation, Division. Das sei schon fantastisch gewesen. Wir sind uns auch einig, dass die 256er Grenze in den Bytes aufgehoben wurde, und das viel vereinfacht hat.
Es gibt im Netz angeblich unendlich viele Webseiten zur Homecomputerscene. Wenn es dann aber darum geht, Code zu sehen etc, herauszufinden, wie die Probleme in echt gelöst wurden, ist das Angebot dann fade oder man muss alles zusammensuchen. In diesem Sinn ist die folgende Webseite recht interessant, es gibt Interviews und auch Hintergrundinfos.
Gehört eigentlich in jede Ausstellung zu gestern, die Verkaufsboxen. Alles in einem: Branding, Werbung, Inhalt, Comic, Game, Action und Mythos: „Piloten Kit“
Arcade vs Homecomputer: Knöpfe vgl. Consolen Simulation des zweiten Knopfs: Zynaps, R-Type und Co. Specialinterfaces wie Paddle, Drehknopf etc. Immer weniger vorhanden vgl.
Pro – nur diese Art von Concept – Standardisierung – Westen ohne Experiment vs vorallem japanische Arcades > Experimente
Contra – nur diese Art von Concept – Standardisierung > wenig Neuerung meist Mapping
Weiterentwicklung am PC: WASD-Joystick oder Cursor-Joystick und Mouse
// Todo: Der Lange Knopfdruck // Todo: Vectrex mit analogem Joystick
Die einfachste Art für eine Ausstellung das Color-Sudoku (8*16 Boxen mit je 3 neuen Farben) erfahrbar zu machen, ist direkt an einem Monitor ein Geflecht darüber zu legen. So dass man sieht wie das ganze ‚funktioniert‘. Eine andere Möglichkeit wäre natürlich eine App für ein Mobile Phone, wo man die Welt durch C64 (oder Apple)-Augen sehen könnte.
Wer nach dem C64 erwartete, es wird nun alles einfacher mit den Homecomputer 16/32-Bittern ab 1985, der wurde eher beim Atari ST glücklich oder vom Sinclair QL. Das waren Computer mit viel RAM und einem fantastischen Prozessor (Motorola 68000), der endlich auch auf Entwickler zugeschnitten war und nicht tot gespart war wie der 6502. Der Atari ST war billig, den Jack Tramiel trieb auch hier sein Spiel für billig und für die Massen, darum wurde an Grafik aber vorallem an Audio gespart (Der Amiga war ja auch mal als Atari Produkt im Gespräch, endete aber bei Commodore).
Der Amiga eingeführt kurz nach dem Atari ST 1985+ war das Homecomputer-Highend-Produkt (neben dem Macintosh und anderen 68000er based Workstations) und am Anfang auch eher teuer (mit wenig RAM 256k), erst der Amiga 500 (1987+) änderte dies grundlegend.
Als Entwickler* sieht die Sache dabei im ersten Moment super aus: Wow, der Amiga, der kann soviel, soviel mehr als der C64 und auch als der Atari ST. Die Facts sind überragend, verschiedenste Bildschirmmodis, die Möglichkeit den Bildschirm mit verschiedenen Screens zu füllen, Hardwarescrolling, Sprites, digitalisierter Sound und sogar Aufgaben können an den Co-Prozessor abgegeben werden. Zudem ist die Grafik skalierbar über Bitplanes. Pro Bitplane kann man die dargestellten Farben vergrösseren. 1 Bitplane 2 Farben, 2 Bitplanes 4 Farben bis zu 5 Bitplanes mit 32 Farben und mit Spezialmodis noch mehr. Was allerdings auch sehr viel mehr Rechnzeit braucht. Aber was will Entwickler* mehr?
Hier muss vermutlich ein Unterschied eingeführt werden zwischen: Entwickler* für die Demoscene und Entwickler* für die Gamedesignscene. Für Erstere* ist der Amiga bis heute eine technische Herausforderung – ein Instrument aus dem bestehenden noch mehr herauszuholen. Die grosse Challenge oder ein Spiel. Für Zweitere* ist der Amiga nur Mittel zum Zweck. Natürlich gab und gibt es auch Mischformen, wie man an vielen Games als technischen Meisterleistungen schnell erkennt. Aber eben nicht unbedingt.
Betrachtet man viele der 8Bit Computer im visuellen Bereich, so sind diese geprägt von massiven Einschränkungen sowohl in Auflösung wie auch Farbmöglichkeiten – gezwungermassen durch Rechenleistung und vorallem RAM-Preise.
Demgegenüber waren die Displays Fernseher/Monitore eher klein und die Pixel eher verschwommene gefüllte Kreise (CRT-Technik, Lochraster) als klar definierte Rechtecke wie bei heutigen grossen Display. Das ergab dann ein fast schon an Glasmalerei erinnerndes Erlebnis. Diese Aspekte wurden auch von einigen Designern* ausgenutzt, indem Farben bewusst gewählt wurden, die ineinander übergingen oder das Gegenteil damit dazwischen wahrnehmungsphysiologisch eine nicht existierende Farbe ‚entstand‘.
Kunsthistorisch muss man vermutlich weit zurückgehen, um solche Einschränkungen bei einem Medium zu finden, jenseits von Monochromen-Printsystemen oder Monochromfernsehern also technischen Systemen.
Welches Visuelle System verwendet schon festgelegt 16 Farben (im Multicolormode), die wiederum in 8×8 Pixelblöcken (Planes) aufgeteilt werden auf 40*11 Blöcken, in denen man wiederum nur 3 Farben bei einer Hintergrundfarbe wählen kann?
Die Colorconstraints in diesem Bild rot markiert. Die Linien zeigen die einzelnen Blöcke mit den Einschränkungen:
Die Auswirkungen dieser Einschränkungen werden auch schnell sichtbar und klar in den Artworks. Es ist eine Art Stil entstanden, der gezwungnermassen farbig grössere Flächen bildet. Dabei ist die Sujetwahl oft recht stereotyp und versucht manuell bestehende Bilder manuell zu digitalisieren statt die Einschränkungen aktiv zu nutzen. Viele dieser Bilder sind also eher Zukunftsgewandt als sich aktiv etwa mit Kunstrichtungen gerade jener Zeit auseinanderzusetzen (die ebenfalls teilweise sehr abstrakt unterwegs waren):
Fast in allen analogen Farbsystemen (aufbauend auf Farbpartikel) lassen sich Farben mischen. Im Falle des C64 nicht und dies ist keine selbstgewählte Einschränkung.
Man findet solche Einschränkungen vermutlich eher als Selbstbeschränkungen von einzelnen Künstlern und Kunstrichtungen etwa in der Abstrakten Malerei. Aber auch da ist mir noch kein Künstler* bekannt, der so rigoros sich an diese Art von FarbenSudoku (8x8Pixel mit 0+3 Farben) gehalten hat.
Dies zeigt sich auch exemplarisch im Falle der Retrogames, die ihr Retro in der Palettenwahl und grösse der Pixel sehen, aber nicht in den Restriktionen dieser ursprünglichen Systeme. Deswegen sollte man diese RetroArt/Games eher als „NeoRetro“ bezeichen.
// ToDo: Eine Augmented Reality App, die die Welt durch die Multicolor-Linse etwa das C64 „digitalisiert“ // ToDo: Klare Abklärung/Auseinandersetzung mit der 70er/80er Jahre Kunstscene
