die Referenz-Frontend für libretro
Plattformübergreifendes, anspruchsvolles Frontend für die Libretro-API. Lizenzierte GPLv3.
Auf einen Blick
- Was ist das?
- Ein plattformübergreifendes Frontend, das libretro-Cores als dynamische Bibliotheken lädt und viele Plattformen sowie Shader-Pipelines unterstützt.
- Für wen ist es gedacht?
- Der Umfang von RetroArch wird durch die libretro-API definiert: Sie übernimmt Audio, Video, Eingabe und Lebenszyklus, während die Cores die eigentliche Emulation oder Darstellung liefern. Die Plattformliste und Konfigurationsoptionen sind im README dokumentiert, aber einige Details wie der vollständige Lizenztext sind in den bereitgestellten Quellen nicht enthalten.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Referenz-Frontend für die libretro-API
RetroArch ist das Referenz-Frontend für die libretro-API. Die libretro-API bietet generische Audio-, Video- und Eingabe-Callbacks. Implementierungen dieser API umfassen Videospiel-Emulatoren und Spiel-Engines, die als dynamische Bibliotheken geladen werden, sogenannte libretro-Cores. Das README besagt, dass libretro völlig offen und für jeden frei nutzbar ist, und dass andere Projekte die Schnittstelle verwendet haben, um Emulatoren und Spiel-Engines zu unterstützen. Der API-Header ist im README verlinkt.
Für RetroArch prüfst du hier Installationsbefehl und Abhängigkeiten anhand des README-Einstiegs und des dort genannten Projektbefehls. Beobachte die konkrete Ausgabe oder Dateistruktur und halte Version, Eingabe und Ergebnis fest; Aussagen zu Leistung, Stabilität oder aktueller Pflege bleiben offen, wenn das README sie nicht belegt.
Binärdateien, Support und Dokumentation
Vorkompilierte Binärdateien werden auf dem Buildbot unter buildbot.libretro.com gehostet. Für Kontakt zu Entwicklern listet das README GitHub Issues, das offizielle Forum, Discord und Reddit mit einem Technical-Support-Flair auf. Dokumentation ist im Documentation Center verfügbar, und Unix-Builds enthalten man-pages. Verwandte Projekte umfassen Shader-Sammlungen (common-shaders, slang-shaders, glsl-shaders), Build-Hilfsskripte in libretro-super und GitHub-Mirrors in libretro-mirrors. Kompilierungsanweisungen sind vom Dokumentationszentrum verlinkt und nicht im README enthalten.
Für RetroArch prüfst du hier Eingabeformat und erzeugte Ausgabe anhand des README-Einstiegs und des dort genannten Projektbefehls. Beobachte die konkrete Ausgabe oder Dateistruktur und halte Version, Eingabe und Ergebnis fest; Aussagen zu Leistung, Stabilität oder aktueller Pflege bleiben offen, wenn das README sie nicht belegt.
Philosophie und bemerkenswerte Funktionen
Das README beschreibt RetroArch als Versuch, klein und schlank zu bleiben, während nützliche Emulatorfunktionen beibehalten werden. Es ist auf Portabilität ausgelegt, mit einer gamepad-zentrierten und Touchscreen-UI sowie einer vollwertigen Befehlszeilenschnittstelle. Zusätzlich hervorgehobene Funktionen umfassen Multi-Pass-Shader-Unterstützung, Echtzeit-Rewind (im Braid-Stil), Videoaufnahme mit FFmpeg und Run-Ahead-Eingabeverzögerungsentfernung. Das Projekt betont auch die einfache Integration in Launcher-Frontends.
Für RetroArch prüfst du hier Konfigurationsdateien und Standardwerte anhand des README-Einstiegs und des dort genannten Projektbefehls. Beobachte die konkrete Ausgabe oder Dateistruktur und halte Version, Eingabe und Ergebnis fest; Aussagen zu Leistung, Stabilität oder aktueller Pflege bleiben offen, wenn das README sie nicht belegt.
Plattformabdeckung und Abhängigkeiten
Das README listet eine lange Liste von Plattformen, darunter Android, Apple iOS, macOS (PPC, x86-32, x86-64), tvOS, Blackberry, DOS, Emscripten, FreeBSD, Haiku, LG webOS, Linux, mehrere Windows-Versionen von NT 3.5 bis 11 und viele Konsolen-Ports wie Nintendo Switch, PlayStation 4, Xbox Series S/X und andere. Die Abhängigkeiten sind minimal: keine echten harten Abhängigkeiten, Windows benötigt nur Win32, Linux hat empfohlene GL/Vulkan-Header und X11 oder EGL/KMS/GBM, macOS benötigt Xcode. Optionale Bibliotheken umfassen nvidia-cg-toolkit und libfreetype2. Audio-Treiber listet ALSA, OSS, RoarAudio, RSound, OpenAL, JACK, SDL, PulseAudio, PipeWire, XAudio2, DirectSound und CoreAudio auf. Zur Laufzeit muss ein libretro-Core vorhanden sein, aber er wird dynamisch geladen, sodass er zur Build-Zeit nicht benötigt wird.
Für RetroArch prüfst du hier Fehlerverhalten und Protokolle anhand des README-Einstiegs und des dort genannten Projektbefehls. Beobachte die konkrete Ausgabe oder Dateistruktur und halte Version, Eingabe und Ergebnis fest; Aussagen zu Leistung, Stabilität oder aktueller Pflege bleiben offen, wenn das README sie nicht belegt.
Grafiktreiber-Anforderungen und Shader
Das README spezifiziert die Mindestunterstützung für Videotreiber: OpenGL 1.1, OpenGL 2.1, OpenGL 3.2 Core, Direct3D 11 mit Shader Model 4.0 und Vulkan 1.0. Die Shader-Unterstützung variiert: OpenGL1 hat keine Shader, OpenGL2 unterstützt Cg (veraltet) oder GLSL, OpenGL3, D3D11 und Vulkan unterstützen moderne Slang-Shader. Die Menütreiber MaterialUI, XMB, Ozone und RGUI sollen mit allen diesen Treibern funktionieren, allerdings fehlen XMB auf OpenGL1 die Shader-Pipeline-Effekte.
Für RetroArch prüfst du hier Version und Wartungszustand anhand des README-Einstiegs und des dort genannten Projektbefehls. Beobachte die konkrete Ausgabe oder Dateistruktur und halte Version, Eingabe und Ergebnis fest; Aussagen zu Leistung, Stabilität oder aktueller Pflege bleiben offen, wenn das README sie nicht belegt.
Konfiguration · libretro retroarch
Die Standardkonfiguration ist in config.def.h definiert, und das README rät davon ab, sie zu ändern, es sei denn, man weiß, was man tut. Eine Beispielkonfiguration wird als systemweite Datei unter /etc/retroarch.cfg installiert. Beim Start erstellt RetroArch eine Benutzerkonfiguration unter $XDG_CONFIG_HOME/retroarch/retroarch.cfg, falls sie nicht existiert. Benutzer müssen nur Optionen anpassen, die von den Standardwerten abweichen. Die Joypad-Konfiguration kann über das integrierte Menü oder durch Bearbeiten von retroarch.cfg erfolgen.
Für RetroArch prüfst du hier Dateipfade und Berechtigungen anhand des README-Einstiegs und des dort genannten Projektbefehls. Beobachte die konkrete Ausgabe oder Dateistruktur und halte Version, Eingabe und Ergebnis fest; Aussagen zu Leistung, Stabilität oder aktueller Pflege bleiben offen, wenn das README sie nicht belegt.
CRT-Auflösungsumschaltung
CRT SwitchRes kann im laufenden Betrieb aktiviert werden, erfordert jedoch einen Neustart, um es zu deaktivieren, und startet RetroArch mit 2560x480@60. Unter Windows müssen zuerst CRTEmudriver und Modellinien installiert werden. Das README listet empfohlene Super-Auflösungen mit 2560 Breite auf (1920, 2560 und 3840 sind die einzigen kompatiblen Super-Auflösungen) und listet Modellinien für NTSC und PAL. Die native Auflösungsumschaltung erfordert einen separaten Satz von Modellinien für bestimmte Konsolen wie SNES, Mega Drive, NES, N64, PSX, Saturn, GBA und Arcade-Systeme. Das README empfiehlt, dass Super-Auflösungen im Allgemeinen bessere Ergebnisse liefern als die native Auflösungsumschaltung, da sich die Auflösung auf der ursprünglichen Hardware innerhalb der Scanzeile ändert. Für MAME stellt die Auflösungserkennung sicher, dass Spiele in der nächstgelegenen verfügbaren Auflösung angezeigt, aber in ihrer nativen Auflösung gezeichnet werden; vertikale Spiele wie DoDonPachi müssen in MAME gedreht werden, bevor CRT SwitchRes aktiviert wird.
Für RetroArch prüfst du hier Schnittstellen zu Drittanbietern anhand des README-Einstiegs und des dort genannten Projektbefehls. Beobachte die konkrete Ausgabe oder Dateistruktur und halte Version, Eingabe und Ergebnis fest; Aussagen zu Leistung, Stabilität oder aktueller Pflege bleiben offen, wenn das README sie nicht belegt.
Lizenzierung
Die Repository-Metadaten weisen die SPDX-Lizenzkennung GPL-3.0 zu. Der bereitgestellte Lizenzauszug besagt, dass im üblichen Pfad keine LICENSE-Datei gefunden wurde, sodass der vollständige Lizenztext und etwaige zusätzliche Bedingungen nicht durch die angegebenen Quellen festgelegt sind. Dieser Artikel trifft keine Aussagen über Garantie oder Support, die über das hinausgehen, was README oder Metadaten sagen.
Für RetroArch prüfst du hier Lizenz und Weitergabe anhand des README-Einstiegs und des dort genannten Projektbefehls. Beobachte die konkrete Ausgabe oder Dateistruktur und halte Version, Eingabe und Ergebnis fest; Aussagen zu Leistung, Stabilität oder aktueller Pflege bleiben offen, wenn das README sie nicht belegt.
Redaktionelles Fazit
Der Umfang von RetroArch wird durch die libretro-API definiert: Sie übernimmt Audio, Video, Eingabe und Lebenszyklus, während die Cores die eigentliche Emulation oder Darstellung liefern. Die Plattformliste und Konfigurationsoptionen sind im README dokumentiert, aber einige Details wie der vollständige Lizenztext sind in den bereitgestellten Quellen nicht enthalten.
Community-Notizen