Der Blitter auf dem Amiga ist für die Programmierung schwierig, da er unscharf (Heisenberg) funktioniert. Er sagt nicht einfach: Wahr oder falsch. Error oder es geht was. Nein er liefert immer irgendwas als Output – egal wie unsinnig der Input etwa ist.
Letztlich ist auch der Amiga mit seinen Special- alias Customs-Chips ein Abschied gewesen von der UrIdee des „mein Code macht alles“. Denn letztlich machte hier sehr viel die Hardware mit Copper oder Blitter (nicht 3D natürlich).
Später kamen noch mehr Spezialchips oder gar 3D-Frameworks dazu. Es stellt sich sogar davor die Frage, ob nicht schon Sprites ein NoGo für Coding-Fundamentalisten sind.
Wenn 3 Wochen Beispiele nicht funktionieren mit dem Blitter, weil die Daten eben nicht im richtigen Memory sind. Aber selbstverständlich funktionierte meine Prozessor-Version davon gut. Kein Wunder. (Vom C64 oder dem Atari ST zum Amiga … Fuck … Da ist immer ein Resultat – egal wie komisch der Input auch sein mag)
Stripes Blitter-Modes … als eine IndustrialStyle-Demos Graffiti-Demo TheDemoMadeOnlyWithOnePicture ThePinkAIDemo Embed Source Code TheDemoSceneGame: MachDirSelberDieDemo – sie ist aber langsam. lösche raus, was es nicht brauch (source-code), sprüche (aus der scene), demos. Punkte, wenn die demo schnell genug, aber nicht zu schnell läuft. und möglichst viele unterschiedliche effekte drin hat. kämpf gegen die glitches … etc. effekte die sich überlagern). party! amiga amiga! Als Amiga Demo selbstverstädnlich! (zeig es den anderen, du bist der beste! greetings …. no code … no games … no crackers … no poilitics … saw before … oh god … nice … ich zeig es denen … ich mach eine plato demo! … no glitsches … demoscene elemente als bilder darüber …. demoscene credit points … ) – an interactive demo … Schatten von ausserhalb – wegclicken … . Möglich auch: du musst die falschen Sachen auf dem Doublescrren (flackernd) wegklicken > mehr Music.
Vielleicht sollte man ins Auge fassen, dass eigentlich Atari ST und Amiga für die Mehrheit der Publisher eine Platform war. Die Mehrheit der Spiele kam auf beiden Systemen heraus und dies zumindest anfangs. Es gab sogar mit Starglider II ein Spiel, das sogar beide Versionen auf einer Diskette veröffentlichte. Es gibt sogar Entwickler*-Stimmen, die sagen, dass die meisten Games zuerst auf Atari ST (zuerst mehr verkauft) entwickelt wurden und dann übertragen. Es gab sogar so etwas wie „Atari ST“-„Emulatoren“ für den Amiga. Ein paar Ports waren dann selbstverständlich technisch dann sehr viel besser. Die Anzahl von Amiga-Only-Spiele ist recht überschaubar.
Sieht man sich die Verkaufszahlen der beiden Computersysteme an, so sind sie eigentlich gemeinsam weit unter den Verkaufszahlen des C64 und vermutlich nur gemeinsam einigermassen erfolgreich gewesen.
// ToDo: Suche nach Verkaufszahlen // ToDo: Rolle der Piraterie // ToDo: Auszählen AtariST-Amiga-Ports und eigene Amiga-Games // ToDo: Nachfrage bei Publishern
Die Heransgehensweise und die Motivation sind höchst unterschiedlich, was die Voraussetzung in der Demoscene oder im Gamedesign sind. Voraussetzung ist natürlich immer, dass die Skills vorhanden sind, das bestmögliche Spiel zu machen (State of the art).
Hier eine Version all Over die verschiedenen Sparten von Gamedesign wie Displays (Visual/Audio), Story, Spielmechanik.
Kategorie
Machbares realisieren
Vision mit aktuellen Mitteln
Vision umsetzen
Möglichkeitsraum
Techn. Möglichkeiten
Techn. Möglichkeiten
Vielleicht gar nicht machbar, warten auf neue Technologie, eventuell nie umsetzbar
Umsetzung
Rahmen des Machbare
Rahmen das Machbare Statt 3D, 2D
Realiserbar ja/nein
Realisierungszeit
Sofort
Sofort
Evt. Jahre
Selbstverstädlich kann das Gesamtprojekt auch aufgeteilt werden in verschiedene Sparten: Etwa im Sound, Visuelles, Spielmechanik. Daraus würde ann noch eine komplexere Matrix entstehen wie „visueller Möglichkeitsraum“, „visuelle Umsetzung“ etc
Es scheint als seien 1/(5+1 unreleased) Games mit einer Maussteuerung entwickelt worden und damit eindeutig angepasst worden an den Maus-Computer als Gerät. Sogar wenn das Arcade-Orginal einen Joystick hatte.
Bei Programmierarbeiten stellt sich immer die Frage (Gerade auch beim BugFixing): Muss man wirklich verstehen, warum etwas nicht geht (Etwa bei HeisenbergProblemen) oder reicht es, dass es irgendwie funktioniert?
Jeder Code enthält frühere Konzept und nicht genutzte oder auskommentierte Funktionalitäten. Man könnte es „Junk“ Code nennen, aber eigentlich ist es weit mehr: Es ist Code aus der Genese des Codes.
Letztlich geht es in Interviews auch darum hier nachzufragen: Was war noch geplant? Was wurde rausgestrichen, weil es Bugs hatte etc.