mame.app

Input-Lag in MAME senken: RunAhead und GroovyMAME

Bild & Tuning 09. Dezember 2025 · 6 Min. Lesezeit

Kurz gesagt

Frame Delay in MAME, RunAhead im RetroArch-Core und GroovyMAME mit echter Synchronisation senken die Latenz oft unter die der Original-Hardware, kosten aber Rechenleistung.

Inhalt
  1. Woher Input-Lag in der Emulation kommt
  2. Frame Delay in MAME richtig einstellen
  3. RunAhead im RetroArch-Arcade-Core
  4. GroovyMAME mit frame_delay und Switchres
  5. VSync, G-Sync und Tearing
  6. Latenz grob messen und gegenprüfen
  7. Kompromiss zwischen Latenz und Leistung

Wer nach Jahren wieder an ein Original-Cabinet mit echter Platine sitzt, merkt den Unterschied sofort: Der Schlag im Prügelspiel kommt gefühlt schneller raus als am Emulator daheim. Das ist keine Einbildung. Zwischen deinem Tastendruck und dem sichtbaren Ergebnis auf dem Bildschirm stapeln sich in einer typischen MAME- oder RetroArch-Installation mehrere Frames Verzögerung. Die gute Nachricht: Mit drei sehr unterschiedlichen Werkzeugen kannst du den MAME Input-Lag reduzieren, teils sogar unter das Niveau der alten Hardware. Dieser Guide bringt die drei getrennten Welten zusammen und sagt dir ehrlich, was welcher Aufwand bringt.

Woher Input-Lag in der Emulation kommt

Die Verzögerung entsteht an mehreren Stellen, die sich addieren. Der Controller selbst hat eine Abtastrate, oft alle 8 bis 16 Millisekunden. Das Betriebssystem und der Grafiktreiber puffern. Der Emulator berechnet einen kompletten Frame, bevor er ihn ausgibt. Und die klassische vertikale Synchronisation hält den fertigen Frame noch einen ganzen Bildaufbau lang zurück, damit nichts zerreißt.

Dazu kommt ein Faktor, den viele übersehen: die Original-Arcade-Spiele hatten selbst schon interne Latenz. Ein Spiel liest den Joystick zu Beginn eines Frames und zeigt die Reaktion erst ein oder zwei Frames später. Diese eingebaute Verzögerung bildet MAME korrekt nach. Genau hier setzt RunAhead an, während Frame Delay und GroovyMAME an der Ausgabekette arbeiten. Wenn du sauber optimieren willst, lohnt sich vorher ein Blick darauf, wie das Eingabesystem überhaupt tickt: siehe MAME: das Tab-Menü und die Eingaben.

Frame Delay in MAME richtig einstellen

frame_delay ist die einfachste Waffe im nativen MAME. Normalerweise berechnet MAME einen Frame und wartet dann auf den nächsten Bildschirm-Refresh. Frame Delay dreht das um: MAME wartet erst einen Teil des Frames ab und startet die Emulation so spät wie möglich, sodass der fertige Frame kurz vor der Anzeige ankommt. Das spart fast einen kompletten Frame Latenz.

So gehst du vor:

  • Öffne deine mame.ini und setze syncrefresh 1 sowie waitvsync 1, damit MAME sauber am Monitor-Refresh hängt.
  • Setze frame_delay zunächst auf einen niedrigen Wert wie 3. Der gültige Bereich reicht von 0 bis 9.
  • Starte ein anspruchsvolles Spiel und taste dich nach oben. Solange die Emulation bei voller Geschwindigkeit läuft, ist der Wert sicher.

Die Falle: Frame Delay funktioniert nur, wenn dein Rechner den Frame in der verbleibenden Zeit fertig rechnet. Bei fordernden Treibern (etwa manche 3D-Systeme oder Sega-Model-Boards) fängt es bei hohen Werten an zu ruckeln, weil MAME den Refresh verpasst. Dann gehst du einen oder zwei Schritte zurück. Frame Delay braucht zudem echtes Hardware-VSync, sonst bringt es nichts. Details zu den Optionen stehen in der offiziellen MAME-Dokumentation.

RunAhead im RetroArch-Arcade-Core

RunAhead ist ein völlig anderer Ansatz und lebt in RetroArch, nicht im Standalone-MAME. Statt an der Ausgabe zu drehen, versteckt RunAhead die eingebaute Latenz des Spiels. RetroArch rechnet pro Bild mehrere Frames im Voraus, speichert intern einen Savestate, spult zurück und zeigt den Frame an, der deinen Eingaben schon voraus ist. Für dich fühlt es sich an, als würde das Spiel früher reagieren.

Einrichtung im FBNeo- oder MAME-Core:

  • Öffne im Schnellmenü den Punkt „Latenz“.
  • Aktiviere „Run-Ahead zur Latenzreduzierung“ und stelle die Zahl der Frames auf 1.
  • Schalte „Zweite Instanz verwenden“ ein. Das verhindert Audio-Knackser, kostet aber CPU, weil der Core faktisch doppelt läuft.

Ein Frame nimmt meist schon die spürbare interne Verzögerung weg. Zwei Frames können sich in einzelnen Titeln lohnen, mehr führt oft dazu, dass Reaktionen im Spiel gar nicht mehr stattfinden, weil du Frames wegwirfst, die eigentlich Gegner-Animationen enthielten. Wichtig: RunAhead braucht funktionierende Savestates. Der FBNeo-Core ist hier sehr zuverlässig, der aktuelle MAME-Core unterstützt nicht jeden Treiber gleich gut. Neuere RetroArch-Versionen bieten zusätzlich „Preemptive Frames“ als Alternative, die günstiger für die CPU ist. Die genaue Mechanik erklärt die Libretro-Dokumentation zu RunAhead. Wenn du dich noch fragst, ob RetroArch oder das native MAME der bessere Unterbau ist, hilft dir der Vergleich unter MAME gegen RetroArch.

GroovyMAME mit frame_delay und Switchres

GroovyMAME ist ein spezialisierter MAME-Fork von Calamity, gedacht für Leute mit CRT-Röhre oder dem Anspruch auf minimale Latenz. Zwei Zutaten machen den Unterschied. Erstens die integrierte Switchres-Bibliothek, die für jedes Spiel eine passgenaue Modeline erzeugt, sodass der Bildschirm exakt in der originalen Auflösung und Bildrate läuft. Zweitens ein deutlich robusteres frame_delay, das mit dieser echten Synchronisation zusammenarbeitet.

Der Effekt ist beachtlich: Läuft GroovyMAME an einer CRT über eine passende Grafikkarte, synchronisiert es Emulation und Bildaufbau so eng, dass die Gesamtlatenz unter die der Original-Platine fallen kann. An einem modernen LCD ohne exakte Modeline bleibt der Gewinn kleiner, aber frame_delay in Kombination mit syncrefresh bringt auch dort etwas. GroovyMAME nutzt dieselben frame_delay-Werte, verträgt aber dank besserer Timing-Kontrolle meist höhere Einstellungen als das Standard-MAME. Setze auch hier auf einen mittleren Wert und steigere, bis die ersten übersprungenen Frames auftauchen. GroovyMAME wird im Software-Bereich des arcadecontrols.com-Forums gepflegt, dort findest du auch Setups für die passende CRT-Ausgabe.

VSync, G-Sync und Tearing

VSync ist der Kompromiss zwischen Bildqualität und Latenz. Ohne Synchronisation bekommst du Tearing, also horizontale Risse im Bild, dafür minimale Verzögerung. Mit klassischem VSync verschwindet das Tearing, aber du zahlst mit bis zu einem ganzen Frame Puffer. Frame Delay und GroovyMAME holen genau diesen Puffer wieder rein, deshalb funktionieren sie nur mit aktivem Hardware-VSync sinnvoll.

Ein Monitor mit variabler Bildwiederholrate, also G-Sync oder FreeSync, ist der elegantere Weg. Er passt den Refresh an die Emulation an, verhindert Tearing und spart den VSync-Puffer. Wichtig ist, die Bildrate ein paar Bilder unter der Maximalfrequenz des Monitors zu deckeln, damit du im VRR-Bereich bleibst und nicht ins reguläre VSync zurückfällst. Die messtechnisch belegten Einstellungen dafür beschreibt der Artikel G-SYNC 101 von Blur Busters. Für Puristen bleibt die echte CRT über GroovyMAME die Referenz, weil dort gar kein Zwischenpuffer entsteht.

Latenz grob messen und gegenprüfen

Zahlenspielereien ohne Messung führen leicht in die Irre. Die einfachste Methode braucht nur ein Smartphone mit Zeitlupenfunktion, idealerweise 240 Bilder pro Sekunde. Filme deine Hand am Knopf und den Bildschirm gleichzeitig. Dann zählst du in der Aufnahme die Frames zwischen dem sichtbaren Tastendruck und der ersten Reaktion im Spiel. Bei 240 fps entspricht jeder Frame gut vier Millisekunden.

Mach die Messung immer mit demselben Spiel und derselben Aktion, sonst vergleichst du Äpfel mit Birnen, weil jedes Spiel eine andere interne Latenz hat. Miss einmal im Ausgangszustand, dann nach jeder Änderung. So siehst du schwarz auf weiß, ob Frame Delay 6 wirklich zwei Frames gegenüber Frame Delay 2 bringt oder ob der Wert nur Ruckler produziert. Achte darauf, dass der Encoder deines Controllers nicht selbst zur Bremse wird. Ein sauber verkabelter Zero-Delay-Encoder gehört zur Grundausstattung, siehe Arcade-Stick mit Zero-Delay-Encoder.

Kompromiss zwischen Latenz und Leistung

Alle drei Ansätze kosten Rechenleistung, und zwar an unterschiedlichen Stellen. Frame Delay verkürzt das Zeitfenster für die Emulation, deshalb braucht es CPU-Reserven, um den Frame rechtzeitig fertig zu bekommen. RunAhead rechnet den Core mehrfach, mit zweiter Instanz sogar doppelt, was schwächere Systeme an die Grenze bringt. GroovyMAME ist am genügsamsten bei 2D-Klassikern, verlangt aber die passende Ausgabekette mit CRT oder exakter Modeline.

Diese Reihenfolge ist pragmatisch: Fang mit sauberem VSync und einem moderaten Frame Delay an, das ist der beste Gewinn für den geringsten Aufwand. Läuft dein Setup über RetroArch, ist ein Frame RunAhead im FBNeo-Core fast geschenkt und der spürbarste Einzelschritt gegen die eingebaute Spiel-Latenz. Den letzten Millimeter holst du nur mit GroovyMAME an einer echten Röhre, und der Aufwand dafür ist deutlich höher. Wer ohnehin am Bildlook feilt, kombiniert das mit den Tipps aus CRT-Shader und Scanlines. Nicht jede Latenzquelle lässt sich schlagen, aber unter das Gefühl der Original-Hardware zu kommen ist mit etwas Geduld realistisch.

Input-LagRunAheadGroovyMAMEFrame DelayLatenz

mame.app ist unabhängig und erhält für Empfehlungen kein Geld. Angaben zum Recht sind eine allgemeine Einordnung, keine Rechtsberatung. Software und Rechtslage können sich ändern.


Passende Guides