1. #1

    Registriert seit
    15.03.2015
    Beiträge
    135
    Thanked 12 Times in 11 Posts

    Standard Überlegungen zu Emulatoren für Spielekonsolen

    Yo! Es gibt da ein paar Dinge die ich gerne wissen würde und hoffe mir kann jemand helfen:

    1. Gibt es irgendwelche (rechtliche, ...) Hindernisse beim entwickeln von Emulatoren?
    Hintergrund: Wie die die sich darüber informieren wissen gibt es inzwischen... nennen wir es pre-beta-emualtoren für XBox360, PS3 und 3DS... und Wii U. Aber diese Konsolen sind längst outdated. Niemand hat mit den neueren Konsolen angefangen obwohl die Nachfrage doch gigantisch sein müsste. Hat wirklich einfach nur niemand Lust so ein Projekt zu starten oder gibts da andere Hindernisse?

    2. Wäre es möglich Emulatoren kommerziell zu entwickeln?
    Hintergrund: Soweit ich weiß sind Emulatoren so etwas wie eine Grauzone. Solange man also keine gecrackte Firmware oder so mitliefert oder auf sonstige nicht erlaubte Dinge zurückgreift könnte man so einen Emulator dann kommerziell und auch offiziell entwickeln? Damit würde die Motivation enorm steigen und Fortschritte wären rapide! Und ganz nebenbei wären dann endlich die ganzen nutzlosen Geräte wie PS3, XBox360 ... ausgehebelt.

    3. Was haltet ihr generell von Emualtoren?
    Hintergrund: Im Prinzip sind diese ganzen Konsolen ja auch nichts weiter als PCs. Das einzige was diese irgendwie... "Besonders macht" ist die Steuerung. Und vielleicht dass man 100% der Leistung für die Spiele hat. Aber ständig kommen neue raus die man sich immer wieder kaufen muss. Wenn man sich aber gleich einen guten Computer kauft reicht der selbst bei grafisch anstrengenden Spielen für mehrere Jahre! Und die ganzen Controller kann man inzwischen per USB anschließen. Also wozu überhaupt Konsolen?

    4. Gibt es eine Programmiersprache die für Emulatoren am geeignetesten ist?
    Hintergrund: Ich hab viele Emualtoren gesehen die mit C/C++ geschrieben wurden. Und nur ein "expermenteller" GBA Emulator verwendet C#. Sind imperative Sprachen da irgendwie besser oder wäre es mit C# und objektorientierten Konsorten vielleicht noch einfacher?

  2. #2
    Avatar von DMW007
    Registriert seit
    15.11.2011
    Beiträge
    6.080
    Thanked 9.118 Times in 2.995 Posts
    Blog Entries
    5

    Standard AW: Überlegungen zu Emulatoren

    Grundprobleme bei der Entwicklung von Emulatoren

    Das Hauptproblem wird sein, dass es sich um Proprietäre Software handelt. Zwar basiert die PlayStation 4 beispielsweise auf Unix (FreeBSD), was wiederum Open Source ist. Allerdings ist der von Sony entwickelte Fork proprietär, also nicht quelloffen. Dadurch wird es deutlich schwieriger, dies zu portieren. Die Spiele sind es genau so wenig. Mehr als Reverse Engineering wird da nicht übrig bleiben. Und das ist bei einem kompletten Betriebssystem natürlich eine Herausforderung. Hier reden wir von Millionen Codezeilen. Alleine mit den Controllern dürfte es schwierig werden, da eine breite Kompatibilität herzustellen. Das sind dann alles noch so Kleinigkeiten, die noch mal für einiges Kopfzerbrechen sorgen.

    Und gerade weil es keinen Quellcode/Dokumentation gibt, ist das ganze natürlich auch SEHR aufwändig. Zumal hier sicher auch verschiedene Kopierschutztechniken einem in die Suppe spucken dürften. Ein inoffizieller Emulator hängt daher zwangsweise immer hinter dem originalen System hinterher: Die aufwändigen Arbeiten können schließlich erst nach Veröffentlichung durch den ursprünglichen Hersteller erfolgen. Ähnliches kannst du bei Projekten wie Mono beobachten, die das ebenfalls proprietäre .NET Framework auf Linux portieren: Microsoft veröffentlicht eine neue Version, Mono schaut sich was die Funktionen machen und baut sich unter Linux nach. Daher hinkt Mono immer ein paar .NET Versionen hinterher. Wobei Microsoft da mit dem Open Source .NET Core mittlerweile deutlich offener geworden ist, aber das ist ein anderes Thema.

    Dazu kommt, dass man auf Windows natürlich kein Unix nativ zum Laufen bekommt. Höchstens in einer VM. Ob das gerade bei den neueren Konsolen zu einer angemessenen Performance führt, ist fraglich. Bei den älteren Konsolen ist das kein so großes Problem, weil sie viel leistungsschwächer waren. Zeitgleich sind die Computer leistungsfähiger geworden. Der hierbei entstehende Overhead ist in der Praxis also nicht relevant. In modernen Spielekonsolen ist das anders, die Hardware da drin bewegt sich ja mittlerweile durchaus auf das Niveau eines Mittelklassen-Computers.

    Kommerzielle Vermarktung

    Emulatoren kommerziell zu vermarkten dürfte nicht funktionieren. Damit die Spiele laufen, muss der Emulator ja 1:1 das jeweilige System nachbilden. Ohne Erlaubnis vom Hersteller gibt das schnell urheberrechtliche Probleme. Denn der hat natürlich kein Interesse an Emulatoren die andere reich machen, sondern er möchte seine eigenen Konsolen verkaufen. Bei den alten Konsolen interessiert es die Hersteller meist weniger, vor allem wenn sie diese selbst nicht mehr verkaufen. Denn die wissen ja auch, dass mit einer EOL-Konsole nur noch ein begrenztes Spieleangebot zur Vefügung steht. Wer neuere Spiele auf einer Konsole möchte, muss und wird also sowieso die neueren Modelle kaufen.

    Technische Sicht und Probleme bei der Emulator-Entwicklung

    Bei der Entwicklung von Emulatoren bewegt man sich im Bereich der Low Level-Programmierung, also sehr hardwarenah. Hier wird traditionell viel C, in OOP-Richtung bestenfalls C++ verwendet. Aber auch Assembler ist vertreten, meist beim Kernel. Hier geht es meist weniger um Einfachheit, als um große Flexibilität und Performance. Je näher es zur Hardware geht, um so größere Auswirkungen hat ineffizient programmierte Software. Mit C/C++ kann man gut um einzelne Bytes ringen, etwa mit Zeigern (Verweise auf eine Variable statt sie zu kopieren, zum Beispiel beim Übergeben von Werten an eine Funktion) oder anderen Schweinereien wie Inlineassembler (Assembler-Code aus einer höheren Sprache wie C heraus ausführen). Dadurch wird der Code zwar schnell, aber eben auch kompliziert. Beispielsweise kommt es häufig zu Zeigern die irgendwo ins Nirvana zeigen, weil der Zeiger über 9 andere Zeiger auf eine Variable zeigt, die verändert oder entfernt wurde.

    Zudem bist du hier natürlich mehr oder weniger Hardware-Abhängig. Am schlimmsten ist Assembler, da variieren dein Befehlssatz anhand Chipsatz, Prozessor und so weiter. Mal eben den Code auf dem Laptop laufen lassen oder gar jemandem weitergeben ist also nicht. Bei der Anzahl verschiedener Hardware-Konstellationen ein Fass ohne Boden. Daher schreibt man bei Betriebssystemen in der Regel nur den Kernel in Assembler. Das Betriebssystem selbst wird in C/C++ geschrieben, und greift auf den Kernel zu - Also eine Art Abstraktionsschicht. Denn für Sprachen wie C gibt es Kompiler, die den Code in die Maschinensprache des jeweiligen Zielsystemes übersetzen. Ich muss mich als Entwickler also zumindest nicht mehr um die Hardwarearchitektur- und Konstellation kümmern.

    Lov Level vs High Level Sprachen


    Je weiter du in Richtung High Level Entwicklung gehst, um so mehr Abstraktionsschichten gibt es, die Aufgaben dieser Art für dich übernehmen. Für dich als Entwickler wird es also unwichtiger, auf welcher Hardware und auch auf welchem Betriebssystem die Software später läuft. Beispiel: Sprachen wie Java bieten dir ein plattformunabhängiges Framework für verschiedene Aufgaben. Beispielsweise kannst du mit dem gleichen Code unter Windows und Linux etwas in eine Datei schreiben. Java stellt dir auch eine Konstante für das Trennzeichen von Pfaden (Backslash \ unter Windows, Slash / unter Linux und allen auf Unix-Basierenden Systemen wie OS X von Apple) zur Verfügung. Du schreibst deinen Code also einmal, und er wird überall funktionieren - ohne dass du Präprozessor-Anweisungen für verschiedene Plattformen benötigst, und der Code am Ende 5x so lang ist. Kann man an Programmen wie JDownloader sehen, da läuft die gleiche Codebasis auf unterschiedlichen Betriebssystemen.

    Grundsätzlich ist es daher sinnvoll, auf einem so hohen Level wie möglich zu entwickeln: Es beschleunigt die Entwicklung, macht die Software plattformunabhängiger sowie in der Regel auch stabiler. Also Emulatoren am besten in .NET oder Java programmieren? Wenn man den Anfang meines Beitrages noch im Kopf hat, wird man sich folgende Frage stellen: Wir wollen ein Betriebssystem, also fast schon das hardwarenaheste das es gibt, mit einer Hochsprache entwickeln, die am anderen Ende mehrere Abstraktionsschichten zum darunter liegenden Betriebssystem besitzt - klingt, als würde es nicht so richtig zusammen passen. Ich will damit nicht sagen, es ist unmöglich. Viel mehr die typische Informatiker-Antwort: Es kommt darauf an, und zwar auf einige Faktoren:

    Für welche Architektur wurde die Software entwickelt?

    Du musst bedenken, dass es für Spielekonsolen keine einheitliche Plattform gibt. Es ist also nicht wie im Desktop-Bereich, wo man sagen kann: Fast 90 Prozent der Nutzer verwenden Windows, wenn ich meine Software z.B. in .NET schreibe, läuft die also grundsätzlich mal bei 9 von 10 Leuten. Bei der Playstation 4 hast du einen Unix-Unterbau, auf der Xbox sieht es schon wieder ganz anders aus. Da läuft ein Windows-Kernel, und mittlerweile als Betriebssystem ein angepasstes Windows 10. Mit anderen Worten: VÖLLIG unterschiedlich. Und da es kein Vanilla Windows 10 ist, kann man nicht mal darauf ausgehen, dass klassische Windows 10 Anwendungen da ohne Anpassungen drauf laufen.

    Noch komplizierter wird es, wenn jetzt noch verschiedene CPU-Architekturen dazu kommen. Das haben wir in der Konstellation immerhin nicht, sowohl Xbox als auch PlayStation verwenden soweit ich weiß die verbreitete x86-Architektur. Also immerhin schon mal in der Hinsicht gute Chancen, das auf einem x86-Computer zum laufen zu bekommen. Mit der Nintento Wii dagegen sieht es beispielsweise ganz anders aus: Die Konsole setzt auf die PowerPC-Architektur. Für die Wii geschriebene Software wird man also nicht mal eben auf einem klassischen PC zum Laufen bekommen. Kann man sich vorstellen wie klassischer PC und Raspberry: Da hat man auch zwei unterschiedliche Prozessorarchitekturen. Daher lässt sich die Desktop-Version eines Windows genau so wenig auf einem Raspberry installieren wie Raspbian auf einem Desktop-PC. Stattdessen müssen die Systeme an die jeweilige Architektur angepasst werden, wie man es etwa mit Debian => Raspbian oder Windows 10 => Windows IoT gemacht hat. Debian ist aber Open Source und Windows IoT stammt von Microsoft, d.H. die hatten dafür ihren Quellcode zur Verfügung. Hast du bei der Wii nicht.

    Wie alt ist die Software?

    Aktuellere Spiele sind natürlich wesentlich umfangreicher und komplexer als die jahrzehnte alten C64-Spiele. Und zur damaligen Zeit war der Einsatz von Kopierschutzmechanismen noch weit weniger allgegenwärtig wie heute. Im Gegenteil, vieles war sogar recht offen und konnte einfach verändert werden. Das trifft auch auf andere Systeme wie Spielautomaten zu. Kurz gesagt werden einem beim emulieren eines alten Systemes sehr wahrscheinlich weniger Steine in den Weg geworfen, wie bei einem neuen.

    Zurück zu C#/.NET


    Es gibt noch weitere Punkte, aber ich denke das reicht erst mal um einen Eindruck zu verschaffen, welche Komplexität das Thema hat. Was Emulatoren in .NET angeht kann ich mir vor allem bei älteren Systemen vorstellen, dass man diese in einer Art VM startet und über .NET darauf zugreift. Hardwarenahe Entwicklung ist nicht mein Spezialgebiet, aber ich bezweifle, dass hier komplett auf .NET gesetzt wird. Vermutlich wird es eine Kombination verschiedener Sprachen sein, bei denen .NET eher in Richtung User-Interface eingesetzt wird. Wie das im Detail funktioniert wird dir wahrscheinlich nur jemand erklären können, der in dieser Konstellation aktiv an Emulatoren entwickelt. Wenn dich das interessiert würde ich mal auf der Homepage des von dir angesprochenen Emulators schauen, ggf. im Support-Bereich nachfragen.

    Wobei dich das aber in Richtung emulieren aktueller Konsolen ohnehin nicht weiter bringen wird. Wie schon oben im Post erklärt, setzt die PS4 auf ein angepasstes Unix. Wenn du nicht einige Millionen Zeilen Unix neu schreiben willst, wäre hier der erste Ansatz daher an das Betriebssystem ran zu kommen und dies auf einem Computer zum laufen zu kriegen. Klingt einfach, wird es aber nicht, weil das so nicht vorgesehen ist. Ich würde es mal mit Klonen der Festplatte versuchen, und zwar auf ein System, das hardwaremäßig der PS4 möglichst ähnlich ist. Abgesehen von Treiberproblemen kann ich mir aber auch gut vorstellen, dass die ihr OS nicht auf der Platte sondern einem gesonderten Speicher haben. An den ranzukommen wird interessant. Dürfte kaum machbar sein, ohne an das Unix ranzukommen. Mit mal eben ein paar Stunden rumspielen und dann läuft das wirst du hier nicht weit kommen.


  3. The Following 2 Users Say Thank You to DMW007 For This Useful Post:

    Darkfield (19.11.2016), Negok (11.11.2016)

  4. #3

    Registriert seit
    02.01.2013
    Beiträge
    879
    Thanked 458 Times in 313 Posts

    Standard AW: Überlegungen zu Emulatoren für Spielekonsolen

    Noch kurz was zu Assembler. Emulatoren müssen ja die Prozessoren der Konsole nachbilden (CPU, Grafikprozessoren, und andere komplexere Komponenten). Hierbei darf man nicht zu viel Zeit verschwenden, da sonst die emulierten Prozessoren Code langsamer abarbeiten als die echten. Aber Spiele, die langsamer als in der Originalkonsole laufen will niemand spielen. Je schneller die Hardware in der Konsole ist, die man emulieren will, umso schneller muß die Emulation laufen, d.h. umso wahrscheinlicher ist es, daß c/c++ zu viel Overhead hat und man zumindest Teile der Prozessoremulation in handoptimiertem Assembler schreiben muß. Sowohl bei CPU wie auch bei Grafikprozessoremulation kann man evtl. auch die PC-Grafikkarten unterstützend nutzen (CUDA etc.). Ich habe vor langer Zeit einmal einen Sinclair Spectrum Emulator geschrieben, das war sehr einfach, weil das System überschaubar war. Einen PS3-Emulator oder so etwas zu schreiben ist hingegen sauschwer, weil das inzwischen hochkomplexe Systeme sind... die ja auch nicht so dokumentiert sind, daß man sie einfach komplett nachbilden kann. Da muß man wohl viel Reverse-Engineering investieren, um überhaupt rauszufinden, wie die Systeme funktionieren.

    Millionen Zeilen Unix neu schreiben o.ä. muß man nicht. Das ist ja der Kniff von Emulatoren, daß sie mit den Binärdateien der Spiele funktionieren. Genauso funktionieren sie auch mit den Binärdateien der Betriebssysteme, da ist ja kein Unterschied.

  5. The Following User Says Thank You to freulein For This Useful Post:

    Negok (11.11.2016)

  6. #4
    Avatar von DotNet
    Registriert seit
    10.06.2015
    Beiträge
    661
    Thanked 316 Times in 185 Posts

    Standard AW: Überlegungen zu Emulatoren für Spielekonsolen

    Zitat Zitat von freulein Beitrag anzeigen
    Millionen Zeilen Unix neu schreiben o.ä. muß man nicht.
    So wie ich es verstanden habe, bezog sich die Aussage mit dem FreeBSD neu schreiben auf eine Native Windows-Portierung, um die Notwendigkeit eines Unix-Unterbaus zu verdeutlichen. Das scheint mir zutreffend zu sein. Ein PS4-Emulator müsste das Betriebssystem emulieren, also in dem Fall das Sony-Eigene Betriebssystem, welches auf FreeBSD aufbaut. Ob das in einem virtuellen Computer funktionieren könnte, ist für mich nicht beurteilbar. Ich habe noch nie Spiele in einer VM gespielt. Wäre gut möglich, dass hier zu viel Overhead erzeugt wird. Wenn das funktioniert, braucht man wohl definitiv ein System mit ordentlich Power.

    Im Krieg gibt es keine Gewinner, nur Verlierer!

  7. #5

    Registriert seit
    10.05.2015
    Beiträge
    22
    Thanked 7 Times in 6 Posts

    Standard AW: Überlegungen zu Emulatoren für Spielekonsolen

    Natürlich ist es auch möglich kommerzielle Emulatoren zu entwickeln. Bleem! ist da ein ganz gutes Beispiel.

    Diese haben den Streit gegen Sony sogar damals gewonnen, aufgrund der hohen ausgaben musste die Firma dann aber doch dicht machen.

    Auch Sonys PS2,PS3 als auch die Microsoft Xbox 360 sowie die Xbox One nutzen eigens entwickelte Emulatoren für ihrer Abwärtskompatibilität. Da Abwärtskompatibilität immer als Feature angegeben wird falls auch vorhanden, wird dessen Emulator eben auch verkauft, Indirekt.

Ähnliche Themen

  1. Frage zu Emulatoren
    Von Kokujo im Forum Windows
    Antworten: 2
    Letzter Beitrag: 02.07.2016, 18:41
  2. Emulatoren für Mac OS X?
    Von Pflanzenfreund im Forum Emulator
    Antworten: 2
    Letzter Beitrag: 06.11.2013, 16:31
Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.