Virtuelle Retro-Hardware

... verschieben geht ja immer noch. [Tante Edit:] ich habe den Thread jetzt erst einmal aus der Coder-Ecke in den Konsolen-Bereich verschoben, weil sich das Thema etwas anders entwickelt hat, als erwartet – es geht doch mehr um eine Retro-Konsolen-Emulation, als um ein API zur leichten Erstellung von Retro-Games (u.a. für moderne Konsolen und Mobile Devices). (Soll aber nicht heißen, dass das nicht auch diskutiert werden darf). Jetzt aber los:

Im Thread "Eigenes Konsolen-Unternehmen hier in Deutschland?" habe ich eine Idee (mehr ist es leider nicht) formuliert, die nichts mit Hardware, sondern mit Software-Entwicklung zu tun hat, weswegen ich sie dort mal ausgliedern möchte. Um den anderen Thread nicht zu zerreißen, wiederhole ich hier meinen Text und die Antworten darauf. Ich weiß nicht, ob die Idee das Rad zum hundertsten mal erfindet oder ob daran etwas unique oder überhaupt gut ist:

------

Ich denke, Hardware ist überhaupt nicht (mehr) das Problem. Hardware, auf der man Spiele zum Laufen bekommt, gibt es wie Sand am Meer in jedem Haushalt und in jeder Hosentasche. Was wäre denn der Vorteil, wenn man weitere Hardware produzieren würde – selbst wenn das in Deutschland oder zumindest Europa geschehen würde? Man würde doch nur noch mehr Elektroschrott (von morgen) erzeugen. Was ist denn an der vorhandenen Hardware verkehrt? Ich glaube, man hat hier das Bauchgefühl, dass die eigenen Wünsche von der Spiele-Industrie ignoriert werden und man sich in dem Angebot an Software-Titeln nicht (mehr) wiederfindet. Zu viel 3D, zu viel online, zu komplex, zu wenig Spielspaß. Habe ich das evtl. richtig analysiert?

Dann sollte die Antwort auf die Frage, bzw. die Lösung des Problems nicht in der Hardware gesucht werden, sondern eher im Bereich Software-Entwicklung. Es gibt ja eine Menge an aktuellen "Retro-Spielen" auf unterschiedlichen Plattformen (ich selbst stelle ja immer mal wieder zusammen was ich für das iPhone so finde), allerdings müssen sich die Entwickler um den Pixel-Look etc. immer selbst kümmern. Was haltet ihr von der Idee, eine standardisierte Retro-"Hardware" zu definieren und diese dann nicht zu bauen, sondern gleich zu emulieren, sodass (Indy- und Hobby-) Spiele-Entwickler eine technologische Basis haben, auf der sie ihre Projekte realisieren können? Man hätte dann ein SDK für Mac/Linux/Windows zur Verfügung und hätte eine ungewöhnliche, virtuelle Zielplattform mit meinetwegen 200 x 200 Pixeln, 64 festen Farben, Rasterroutinen, soundso vielen Sprites und Tonkanälen etc. (und einfach zu nutzenden Möglichkeiten, diese Fähigkeiten anzusprechen) Und für diese virtuelle Hardware stellt man dann Emulatoren für die unterschiedlichsten echten Hardwares (Settop-Boxen, PCs, Smartphones, Konsolen, Tablets, TV-Sticks ...) zur Verfügung. Gut, das wäre jetzt etwas ganz anderes, als dem Threatstarter vorschwebte – aber evtl. löst es genau das Problem, das er gesehen/gefühlt hat.

Zitat von finchy

Das ist ein interessanter Punkt und wäre vlt. einen eigenen Thread wert. Zudem der wahrscheinlich bisher einzige Lösungsansatz in diesem gesamten Thread für die nur mit Unzulänglichkeiten gespickte Idee einer eigenen Konsole.

Zitat von Mac Bacon

Ich denke Deine Analyse des ursprünglichen Problems trifft ins Schwarze. Von der Lösung halte ich aber nichts, denn: Der "Retro"-Anteil diverser modener Spiele beschränkt sich offensichtlich auf einen pixeligen Look und 2D-Grafik, d.h. auf Design-Aspekte. Keiner der Programmierer dürfte aber sonderlich erpicht auf echte Limitierungen sein, wie z.B. eine geringe Auflösung, Maximalzahl Farben, Maximalzahl Sprites etc.
Außerdem dürfte moderne Hardware so etwas wie Rasterroutinen weder ermöglichen noch benötigen; und Sprites werden vermutlich auch rein in Software gemacht.

Ergo: Wenn überhaupt, läuft es auf Software-Libraries hinaus. Aber da gibt es sicher schon etwas.

Zitat von BladeRunner

Grade Limitierungen können den Reiz am Programmieren zumindest für den Hobbiisten erhöhen, da sie eine Herausforderung darstellen. Wir machen regelmäßig Programmierwettbewerbe, und der Kernbestandteil ist es diverse Limits vorzugeben, so z.b maximale Dateigrößen für Grafiken oder eine Limitierung auf eine Taste zum Steuern o.ä.
Wir haben auch schon einen vcs2600-Kontest gemacht,hier waren nur 128 Byte für Variablen / Befehle und 4kb für feststehende Inhalte (GfX etc) als "ROM" erlaubt. Auflösung etc wurden auch vorher festgelet. Die Ergebnisse waren sehr lustig und die Teilnehmer waren insgesamt positiv von den Limitierungen angetan.

Im professionellen Sektor sieht das natürlich wieder ganz anders aus.

Zitat von 1st1

Genau das hast du auf jeder Demo-Competition in der Demo-Szene... http://www.sillyventure.eu/comp,en

Zitat von Bogogil

Eine virtuelle Retro Konsole ist dagegen eine interessante Idee. Zumindest verspricht sie viel eher ein Erfolg zu werden.

Vielleicht können ja mal ein paar Coder was dazu sagen – wie findet ihr die Idee von einer virtuellen Retro-Hardware? Gibt es sowas schon? Ist wirklich eine Emulation der richtige Weg oder würde es mehr Sinn machen, eine Engine als API zu entwickeln, die jeder interessierte verwenden und dann für Zielplattformen kompilieren kann? Gibt es einen "Markt" (nicht im Sinne von Finanzen) dafür? Könnt ihr euch vorstellen, dass Coder sowas nutzen würden oder wollen die lieber ihre Retro-Beschränkungen selber wählen? Könnte man da eine kleine Szene zum Leben erwecken, die Demos und Spiele dafür/damit entwickeln und vielleicht an Compos teilnehmen? Vorteil von Spielen für diese virtuelle Hardware wäre ja, dass sie auf vielen Endgeräten laufen würden (sofern es den Emu bzw. die Engine dafür gibt), egal ob Android-Handy, Pandora, PC/Mac, iPad, gehackte Konsole, Ouya... Man könnte die entstehenden Spiele mit einem Label (made for/with Retro-Engine) auszeichnen und die Spezifikationen kommunizieren ...

Aber selbst, wenn man die Idee gut finden sollte – wer hätte Interesse, so eine Engine oder Emulation zu spezifizieren und vor allem zu entwickeln? (denn ich bin ja nur ein kleiner Retro-Designer, kein Programmierer)

Zitat von sauhund

ich sehe da ehrlichgesagt den sinn nicht

Hatte ich mir schon gedacht – aber vielleicht gibt es ja noch andere Stimmen dazu. Und wie gesagt: Ich bin nicht böse, wenn "man" zu dem Ergebnis kommt, dass es sich um eine Schnappsidee handelt – ich möchte dennoch näher erläutern, warum meines Erachtens ein kleiner Funken von Sinn drinsteckt:

Warum überhaupt? Dämliche Frage in einem C64-Forum. Weil man es kann? Weil man Langeweile hat? Weil man nicht nach draußen oder ins Bett will? ...

Was wäre an der neuen virtuellen Hardware (bzw. einer Retro-Engine) besser als an einer existierenden Retro-Hardware bzw. deren Emulation? Zum einen hätte man sie evtl. selbst in einem demokratischen Prozess entworfen und wäre damit an einem gemeinsamen Schöpfungsprozess beteiligt. Dann wäre die "Hardware" von den Beschränkungen genauso, wie man sie gerne hätte. Natürlich muss es deutliche (vor allem sicht- und hörbare) Beschränkungen bzw. Spezifikationen geben – sonst kann man das ganze ja auch lassen – aber es muss keine Beschränkungen geben die einem aus heutiger Sicht völlig sinnlose Knüppel zwischen die Beine schmeißen oder die wegen damaliger Designfehler entstanden sind. Warum soll man z.B. einen Sprite-Multiplexer schreiben, wenn die Anzahl der Sprites "groß genug" ist? Für das Endergebnis ist es unerheblich, ob ich z.B. 64 Sprites durch aufwändiges Multiplexen realisieren, oder, wie selbst bei recht frühen Konsolen, einfach genügend Sprites "da sind". Es sieht genau so aus – aber das Entwickler-Leben ist einfacher. Also kurz, durch geschickte Vorgaben und natürlich tolle, fertige Bibliotheken/APIs spart man sich als Entwickler viel Arbeit, die einem sonst niemand honoriert. Übrigens kann man die Spezifikationen ja auch so wählen, dass ein findiger Bastler/Löter daran Spaß haben könnte, eine native Hardware zu entwickeln – aber das ist definitiv kein "Muss".

Was wäre der Vorteil gegenüber eigenen Vorgaben bzw. einer eigenen Engine für ein Retro-Spiel? Bisher wird das ja so gehalten, für "League of Evil", "Canabalt", "Tiny Tower" oder "Super Crate Box" hat sich jeder Entwickler seine eigene Vorgaben ausgedacht und das ist ja auch total OK. Für eine gemeinsame Plattform könnte aber sprechen, dass man sich zum einen nicht jedesmal (und jeder) neu Gedanken über die "wünschenswerten Beschränkungen" machen müsste. Zum anderen könnten Tools oder APIs dafür sorgen, dass das Programmieren nicht unnötig kompliziert ist und man das Rad mehrfach erfinden müsste. Scrollroutinen (auch mit Parallax), Rotationsroutinen, Soundroutinen, Tile-Verwaltung, Sprite-Engine, optimierte Farbpalette etc. könnten ja dank der Engine existieren und der Entwickler könnte sich mehr auf den Inhalt konzentrieren. Zum dritten könnte unter den Entwicklern für diese "gemeinsame Plattform" eine Art Community entstehen, wie sie auch bei den Demo-Codern für bestimmte Plattformen zu finden ist. Man könnte dank der gemeinsamen Vorgaben meinetwegen auch eine jährliche Compo, ähnlich der RGCD-Compo, initiieren.

Warum überhaupt Vorgaben? Weil sie ein Feld abstecken und eine Herausforderung darstellen. Warum portiert jemand ein Spiel vom Atari 2600 oder einer 16-Bit-Konsole auf einen C64 oder einen Atari 800? Weil man die Herausforderung sucht. Der frühere Grund, ein Spiel zu portieren (größere Kundenbasis) ist doch obsolet – heute kann sich jeder quasi jede Hardware für ein paar Euro zulegen und wenn nicht, dann nimmt man einen Emulator, um meinetwegen ein exklusives Atari800-only-Game zu zocken. DAFÜR muss man nicht wirklich den Aufwand betreiben, einen Port zu schreiben. Das macht man, weil man die Zielplattform mag und seine eigenen Fähigkeiten und die der Zielplattform zeigen möchte. Wenn man aber die Zielplattform selbst mit-definiert hat, warum sollte man die nicht auch mögen und zeigen, was sie (und man selbst) kann? Zudem erzeugen Einschränkungen auch einen bestimmten "Look" – man kann nun mal ein ZX-Spektrum Spiel meistens von einem C64-Spiel unterscheiden. Und so sollte natürlich auch die zu definierende Retro-Engine dafür sorgen, dass die darauf laufenden Spiele einen gemeinsamen, typischen (natürlich coolen) "Look" bekommen.

Ich hatte unter anderen deshalb eine quadratische Auflösung in die Runde geworfen: Sie wäre recht typisch und wiedererkennbar – bis auf einige Handhelds (Gameboy ...) verwendet kaum ein System eine (annähernd) quadratische Fläche. Zudem gäbe es keine Auflösungsänderung, wenn man mobile Devices dreht und man hätte auf Touch-Devices Platz für (nicht oder nur wenig den Inhalt überlappende) virtuelle Controls (die natürlich auch von der Engine dargestellt werden, wenn man sie auf der Zielplattform benötigt). Auf einem TV hingegen könnte man die freie Fläche für eine Bezel-Darstellung (siehe MAME) oder Splitscreen verwenden. Aber wie schon gesagt – das könnte auch alles ganz anders aussehen, wenn Interessierte einen anderen Vorschlag machen.

Ich kann halt nur die Idee vorstellen – alles steht oder fällt mit möglichen Unterstützern, die aus der Entwickler-Ecke kommen sollten. Wenn sich da niemand findet, ist die Idee ganz einfach gestorben – nicht schlimm, ich habe da ja außer ein bisschen Herumspinnen bisher keine große Zeit hineinstecken müssen.

Ok, dann ist die Sache gestorben – war ja nur so ein Gedanke. Weitermachen ...

Zitat von Kroko

Also läuft es am Ende nur darauf raus, dass man andere Spezifikationen haben könnte aber davon gibt es auch schon genug ...

Du hast dahingehend recht, dass es in erster Linie "nur andere" Spezifikationen wären. Aber was macht denn eine "andere" Plattform aus, wenn nicht in erster Linie andere Spezifikationen? Darin könnte ja der Spaß liegen, vor allem, wenn sie sich nicht zu ähnlich, sondern etwas besonderes wären, z.B. verhältnismäßig geringe Auflösung bei gleichzeitig recht vielen Farben oder aber Stereo-Sound aber nur mit je 2 Stimmen für Musik plus 2 Stimmen für Geräusche oder 1 MB direkt adressierbares RAM aber ohne weitere Nachlade-Möglichkeiten. Wie gesagt – die Vorgaben erzeugen die Maschine und dafür bekommt man als Ergebnis einen besonderen Look (ich meine das nicht nur optisch), vor allem, wenn es einige Spiel für die Plattform gäbe.

Zitat von sauhund

man kann nie genug sprites haben, genug texturspeicher, genügend audio stimmen, background layer, usw usf. wenn es restriktionen gibt, dann müssen die wie ich finde auch irgendwie sinnvoll nachvollziehbar sein, idr weil sie die hardware eben vorgibt.

Ich finde, es liegt gerade der Witz darin, Beschränkungen zu definieren – damit die "Plattform" einen Look, ein bestimmtes Feeling und eine Identität bekommt. Und ja, sie sollten nachvollziehbar sein. Es würde z.B. wenig Sinn machen, 8 Sprites als Maximum zu definieren, wenn man die Einschränkung mit einem Multiplexer weitgehend außer Kraft setzen könnte – das erhöht nur den Aufwand, bringt aber für das Retro-Feeling wenig. Ich würde deshalb aber nicht komplett auf eine Einschränkung bzgl. der Sprite-Anzahl oder des dafür zur Verfügung stehenden Speichers verzichten wollen – weil man sonst einfach alles tun kann, was man will und somit die Grundidee gefährdet wäre. Man muss die Vorgaben halt schlau wählen, damit so eine Sache nicht ad absurdum geführt wird – da ist halt Augenmaß gefordert und man darf nicht immer gleich das Kind mit dem Bade ausschütten.

Zu deinem Punkt, Vorgaben müssten zwingend von der realen Hardware vorgegeben sein: Wie erklärst du dir den Zuspruch bei Compos, die eben nicht durch die Hardware erzwungene Grenzen als Limit vorgeben, z.B. 1K/4K-Compos o.ä. – meinst du, der restliche Speicher im C64 wird für MS Word oder Firefox gebraucht oder es soll auch mal Spiele oder Demos geben, die auf Geräten laufen, denen jemand einen Großteil des RAMs geklaut hat? In der PC-Demo-Szene gibt es doch auch teilweise künstlich gesetzte Beschränkungen und es macht einigen Leuten Spaß, genau damit auszukommen.

Zitat von Kroko

Wir könnten einfach den C64 als Deine virtuelle Platform nehmen (und mal so tun als würde es ihn nicht wirklich geben)

Der Witz bei meiner Idee wäre ja, dass das Ergebnis der entstehenden Spiele durchaus eine andere sein könnte als bei den Spezifikationen des C64. Zum anderen wäre es ein großartiger Vorteil, dass es standardisierte APIs und Hi-Level-Tools gäbe (das war zumindest Teil meiner Idee), die einem eine Menge Arbeit abnehmen würden, die man beim C64 selber erledigen muss. Für manche Genres könnte ich mir sogar simple Klick-Baukästen vorstellen, um z.B. "einfache" Adventures à la Zelda 1 zu kreieren.

Aber ich will (und kann) ja niemanden überreden – wenn sich dafür außer enthuSI (und Nichtcoder) niemand erwärmen kann, dann fällt die Idee (zumindest hier) nun mal nicht auf sonderlich fruchtbaren Boden. Evtl. sähe das in einem Android/iOS/Pandora/PSX-Entwicklerforum anders aus aber so wichtig ist mir die Sache persönlich nun auch nicht, dass ich damit wochenlang hausieren gehen würde – ich habe ja nichts davon und schreibe hier nur aus Spaß an der Freude. Wegen mir muss es so eine virtuelle Hardware auch gar nicht geben – es war halt nur als Ausweg gedacht, um eine Option für die aufzuzeigen, die immer noch neue Hardware entwickeln wollen, die dann doch nur die üblichen Emus abspielt, die es woanders auch schon gibt. Es ging ja darum, dass einige den Status Quo bei den Spielen offensichtlich nicht gut finden und etwas ändern wollen – wenn man mit dem zufrieden ist, was es schon gibt, braucht man sich natürlich nicht bewegen. Mir reicht auch weitgehend aus, was schon auf dem Markt ist – meine Idee war für jene gedacht, denen es nicht so geht.

Zitat von sauhund

allerdings ist auch bei demo compos der anteil derer die sich solchen künstlichen beschränkungen unterwerfen eher gering, und dazu noch rückläufig.

Kann sein, ich bin in dem Thema "Demos" nicht so drin (finde richtige Spiele interessanter). Aber laut dieser heise-Ankündigung für die "Evoke" sind die 4K-Intros und die 64K-Intros zwei der drei "Hauptkategorien" bei den PC-Demos. Zudem gibt es die NEUE Wettbewerbskategorie "Pixel Graphics", bei der mit einer bestimmten 16-Farb-Palette gearbeitet werden muss (von welchem Homecomputer-Grafikchip mit 16:9-Ausgabe beliebiger Auflösung stammt die Palette?). Kann ja sein, dass die Compos wegen mangelnder Akzeptanz den Bach runtergehen (vielleicht ist aber auch die Evoke irrelevant) aber für mich sieht das so aus, als gäbe es doch noch Leute, die Spaß daran haben, sich an komplett virtuellen Vorgaben zu reiben (oder habe ich relevante, Windows-kompatible 4- oder 64KB-PCs in den Märkten übersehen?)

Wie gesagt, ich habe aufgrund der Antworten hier nur wenig Hoffnung, dass aus meiner Idee ein Projekt wird – aber aus aktuellem Anlass der Evoke-Einladung wollte ich den Einwand doch noch kommentieren. Irgendwie hatte ich doch gehofft, mit dieser (aus meiner Sicht witzigen) Idee ein paar Unterstützer mehr aus dem Entwickler-Lager zu finden "aber es hat nicht sollen sein". Wenigstens haben sauhund und ich dafür gesorgt, dass keine Kalendersprüche als Thread-Abschluss herhalten müssen.

Danke ALeX, so einen konkreten Vorschlag hatte ich zu diesem Zeitpunkt noch gar nicht erwartet – aber schön, dass damit schon mal ein Vorschlag auf dem Tisch liegt, selbst wenn es der einzige bleiben sollte. Deine Antwort lässt ja auch eindeutig deine Vorliebe für einen Emulator, statt eines APIs o.ä., erkennen – u.a. wahrscheinlich weil wegen der größeren Hardware-Nähe immer noch eine Realisierung in echter, spezifischer Hardware möglich scheint. Bei einem Emu wäre natürlich die Frage nach einer konkreten CPU relevant – 6502, Z80, 68000, AVR oder was exotisches? Und wie viel MHz sollte die CPU ungefähr haben? Gibt es evtl. auch einen Verfechter der API-Idee?