Dnes bych chtěl hovořit o tom, jak snížit input lag v Retro Arch u emulovaných her.
Pokud někdo chce tl;dr (too long, didn't read) verzi článku jak to provést, tak je to takhle: V Retro Arch vlezte do menu "Latency" a nastavte "Hard GPU Sync" na "ON", "Frame Delay" na "3ms" a "Run-Ahead" na "Second Instance Mode." A pro ty zvědavější bych se rád rozepsal trochu víc do detailů.
První se nabízí otázka, co je to vůbec input lag. Input lag je zpoždění mezi stisknutím tlačítka a následným vyvoláním akce. Když stisknete třeba na klávesnici písmeno "A" v poznámkovém bloku, chvíli trvá, než se ono "A" objeví na obrazovce. Je to natolik krátká doba, že se vám to může zdát "okamžitě", ale reálně zabere nějaký čas, než ten impuls z klávesnice doputuje do PC a operační systém ho nějak přeloží a monitor nějak vykreslí.
Spousta starších konzolí jako SEGA Mega Drive nebo SNES měla původně minimální input lag. Pokud jste zapojili konzoli do CRT televize a rozehráli nějakou hru, hraní bylo velice plynulé. Bylo to pochopitelně dané tím, že tvůrci jednotlivých her je už od začátku vyvíjeli konkrétně pro tuhle danou konzoli s ohledem na její hardware s tím, že bude zapojena do CRT televize (která je sama o sobě rychlejší, než současné monitory).
Nicméně pokud nemáte původní konzole a CRT televizi, nezbývá vám než hrát hry na emulátoru. Emulátory jsou mnohem pohodlnější a výrazně levnější. Ačkoliv hraní na původním hardware je v očích celé řady hráčů "nadřazeno" emulátorům, buďme upřímní - kdo má čas, prostor a peníze na to si doma budovat retro herní muzeum, že jo?
Emulátory však mají větší input lag a hry v nich typicky reagují malinko pomaleji. Možná si říkáte, že to není takový problém a řešit input lag je možná dobré pro nějaké speedrunnery, kde záleží na každém frejmu, ale takový běžný hráč to může mít ukradené, ne? Nicméně jsem zjistil, že na tom záleží fakt hodně. Je spousta her, které mi vůbec nešly a připadal jsem si, že jsem totální poleno.
Největší šok pro mě byl Super Metroid, který se mi hrál fakt dost špatně. Ve hře je spousta speciálních akcí a předmětů, které vám dávají různé schopnosti, ale mně vůbec nešly používat. Např. v jedné fázi hry se dá sehnat "Grapple Beam", který umožňuje vystřelit paprsek, kterým se můžete chytnout za strop a zhoupnout se přes propast jako Indiana Jones na laně. S touhle věcí jsem měl obrovský problém - většinou se mi nedařilo se s paprskem trefit, případně jsem se chytil jen na chvíli a následně se paprsek "přetrhl" a já jsem zahučel dolů.
Viděl jsem na YT video, ve kterém se jeden youtuber rozhodl zkusit z legrace takový experiment. Ukecal svou přítelkyni, která vůbec nehraje hry a považuje je za "ztrátu času", aby zkusila hrát Super Metroid na původním SNESu. Ač jí to ze začátku moc nešlo, brzy se do toho dostala a dokonce celou hru dohrála. Přišlo mi to zvláštní. Slečna, co nikdy nehrála hry je lepší než já?! Tak jsem pročetl pár Reddit diskuzí, jestli někdo měl stejný problém s Grapple Beam a skutečně - našel jsem topic, kde se na to někdo ptal, proč je ta věc tak na prd. A hodně lidí zmiňuje, že za to může právě input lag, což byla ta chvíle, kdy jsem si ho začal ve hrách všímat a řešit, jak ho minimalizovat.
Udělal jsem malý průzkum a přišel jsem tedy na tohle... Nejlepší je použít Retro Arch. Někteří tenhle "emulátor" moc nemusí, protože je to takový skoro až "parazit" emulátorů, jelikož sice rozjede skoro každou konzoli ve vesmíru (dokonce má v sobě i Dosbox), ale žádnou reálně neemuluje sám, nýbrž využívá jádra z ostatních emulátorů. Lze ho nainstalovat skoro do čehokoliv - Windows, Linux (tím pádem i Steam Deck), MacOS, Raspberry PI, Sony PSP, Android, iOS, PS2, PS3, PS4, do různých zařízení od Anbernic a já nevím do čeho všeho.
Mimochodem, můžete si Retro Arch i zcela zdarma přidat do knihovny na Steamu. Bohužel Steam verze je trochu ořezaná, ale to nevadí, protože v sekci "guides" (návody) je popsán způsob, jak ho uvést do jeho maximálního potenciálu. V podstatě stačí jen stáhnout chybějící cores a hodit do složky, plus pak info o nich, aby se zobrazovaly správně jejich názvy v UI.
Retro Arch má v nastavení položku "Latency", kde si za pomocí různých nastavení můžete zmenšit input lag. První je Hard GPU Sync, který je však trochu náročný na grafickou kartu. To znamená, že na herním PC tahle fičura funguje bez problémů, ale na nějakém Raspberry Pi nebo na handheldu od firmy Anbernic nemusí tak úplně fungovat. Prostě potřebujete na to trochu výkon. Sorry.
Další je Run-Ahead. K dispozici je "Single Instance Mode", "Second Instance mode" a "Preemptive Frames Mode" (v předchozích Retro Arch verzích tam byla jen čísla, tuším). Podle všeho je nejlepší Second Instance Mode, protože je to taková zlatá střední cesta.
Pak je tu Frame Delay, který jsem si hodil na 3ms.
Tahle nastavení se můžou lišit dle konzole, kterou chcete emulovat. Taktéž se liší dle toho, jaké máte zařízení. Možná dokonce i dle specifické hry. Některá nastavení můžou dojebat třeba synchronizaci zvuku a obrazu a podobně... Chce si to s tím trochu pohrát.
Rád bych dodal, že u některých cores / jader mohou tahle nastavení úplně chybět a přesunout se přímo do nějakého nastavení právě onoho jádra. S každým jádrem se celkově může UI v nastavení Retro Arch trochu změnit a obsahovat jiné položky...
S nastavením, které by mělo minimalizovat input lag, jsem se rozhodl si znovu zahrát Super Metroid - navíc už byl čas, protože jsem ho pár let nehrál. Takže jsem se dal do akce... A najednou jako nějakým kouzlem mi to šlo od ruky - celou hrou jsem prošel bez jakéhokoliv problému a většinu bossů jsem zvládl porazit hned na první nebo druhý pokus. Zvládl jsem to celé dohrát asi za šest hodin během několika dní. Ani s Grapple Beam jsem neměl problém - jasně, vyžaduje to trochu cviku a trochu skillu, ale najednou se jeho používání nezdálo nemožné.
Ale co když je to celé jen v mé hlavě? Co když jsem se prostě jen zlepšil v Super Metroid, protože jsem ho hrál už potřetí? A to vedlo k otázce: dá se input lag vůbec nějak měřit? Dá se nějak zjistit kolik ho máte?
S kamarádem jsme se tedy rozhodli, že ho nějak změříme. Prvním krokem je, že potřebujete kameru, co umí natáčet rychlostí 240 snímků za sekundu. Tuším, že by tuhle rychlost měly umět i některé smartphony, kde si můžete přepínat FPS v nastavení, ale naše cihly to bohužel neumí. Kamarád však měl "dashcam" z auta, kde to nastavit šlo.
K experimentu jsme použili hru Sonic The Hedgehog... jakou jinou, že? Kamarád natočil, jak stisknu tlačítko na Xbox gamepadu, (raději zapojený do PC přes šňůru, protože bezdrát má možná větší latenci?) a ježek Sonic vyskočí. Tahle metoda se ukázala být... blbá, protože na tom videu není úplně jednoznačně vidět, kdy přesně dané tlačítko stisknu. Budete se divit, ale ten pohyb prstu je takový... ne tak úplně zřejmý.

Nejdříve jsme zkoušeli změřit rozdíl mezi stisknutím tlačítka na Xbox ovladači a reakcí Sonica - nic moc metoda
Kamarád však přišel s jiným nápadem. Co když do PC nacpeme přes USB Arduino a naprogramujeme ho, aby v pravidelných intervalech stisklo samo klávesu A. To má výhodu i v tom, že když Arduino danou operaci provede, tak se na něm rozsvítí dioda.
K měření jsem použil program VLC player - samozřejmě. Zapauzoval jsem video a klávesou E se video posune vždy o jeden frame. Posunoval jsem ho, dokud se nerozsvítila dioda na Arduinu. Pak jsem posunoval po framech dokud se Sonic nezačal koulet (tj. neobjevil se první sprite animace výskoku) a každý tento frame spočítal.
Ukázalo se, že s GPU Sync a Second Instance Mode to trvá šest snímků. Když se tahle nastavení povypínala, trvalo to šestnáct snímků.
To tedy znamená, že defaultně bez všech nastavení je zpoždění ve hře 67 milisekund, zatímco když je všechny aktivujete, je to 25 milisekund. Došlo tedy ke zrychlení o 42 milisekund. A už to není jen v mé hlavě - nyní máme i tvrdá data - černé na bílém!
A teď si připadám jako idiot, že jsem skoro dvě dekády života hrál emulované hry víceméně "špatně" - doufám, že nejsem jediný, kdo nechápal, jak zásadní u hraní je, aby byla co nejmenší latence. Celá věc i trochu zvedla mé sebevědomí... myslel jsem si, že mi hry nejdou a jsem v nich špatný, ale ukázalo se, že mi sice nejdou a jsem v nich špatný, ale není to zase taková tragédie :)






Wau! Díky za super článek. Hned jsem vyzkoušel a rozdíl je sakra znát. Zkoušel jsem u her na Atari 2600.
Já na Retroarch emuluju už řadu let. Přijde mi to jako nesnadnější řešení, ale spousta lidí na to nadává přesně kvůli input lagu. Já to třeba nepoznám ani v mlátičce.
„že bude zapojena do CRT televize (která je sama o sobě rychlejší, než současné monitory)“
Tohle je trochu slozitejsi. V podstate kdyz se na CRT neco rozsvitilo, bylo to okamzite, problem byl s vyhasinanim, to travalo dele nez dneska na alespon prumernych LCD. Proto taky vetsina her mivala pozadi tmavsi a strely svitily.
Input lag samotneho monitoru/TV – co vlezlo do CRT, to okamzite slo na obrazovku. U LCD se to resi pres vselijaky processing, ktery zdrzuje – muzes zkusit zmerit input lag pri doporucenem rozliseni a pak do toho cpat neco jineho, meritelne to je.
Input lag ovladacu – proste cena za USB, nez se to zpracuje, neco to zabere. Tenkrat to slo do tech stroju taky primo. Bylo by zajimave otestovat, kdyby se ovladace pripojily pres PRT port (na linuxu – windows bych vynechal, protoze od w10 je to s paralel/serial portama na presdrzku).
Pak jeste graficke karty – postprocessing, buffering atd. Proste dalsi vrstva funkci, co chce omezit. Vetsina emulatoru se do nastaveni grafiky nehrabe, tak to pro ne nastavit v ovladacich na pevno. Nastesti u emulatoru vyuzivajicich libretro (retroarch mezi ne patri), se to nejak extra resit nemusi (staci to mit v ovladacich grafiky nastaveno na urcovani aplikaci).
„Některá nastavení můžou dojebat třeba synchronizaci zvuku a obrazu“
Dalsi vec, o ktere by se mohlo neco napsat – zvuk. Retro stroje maji specificke zvukove obvody, ktere se taky museji emulovat. Prave na tohle, aby z toho neco zahralo, je potreba par signalu nasbirat a to se zrovna moc urychlit neda. Ve vysledku jde zvuk z emulatoru oproti originalu mirne opozdeny (proto asi ten 3ms delay).
ps. Vortex – vyzkousej si na par dni original stroj a pak to rozhodne poznas ;)
Trochu jiné téma, ale tady z těch „postprocessingů“ aktuálně rostu s kombinací starší soundbar / různé typy přehrávaného obsahu na TV. Klasické DVB-T je ok. Stream z iVysílání – o půlsekundy mimo. Multimediální přehrávače (VLC, Kodi, Nova) – podle nastavení, podle obsahu. Streamovací platformy – nesedí to úplně přesně, ale na těch pár desítek ms jsem si zvykl. Problém je to častý, obecný a ne vždy obecně řešitelný. Jak to bylo jednodušší, když prostě „od pantáty vedly dráty“ :)
Originál strojů mám plný pokoj a samozřejmě jsem jich testoval většinu i na CRT monitorech/TV a… Prostě to fakt nejsem schopný poznat, nebo registrovat. Případně jsem schopný se asi rychle adaptovat. Těžko říct, jak to je?
já bych řekl, že třeba u Sonica to pocitově jde poznat… s vysokým input lagem je takovej trochu těžkopádnější a pomalejší, jako by najednou měl vyšší hmotnost
Tak jsem si ty parametry pozapínal na DY Energy Star a zatím to vypadá dobře, v emulátorech NESu a Mega Drive nepozoruji pokles výkonu :)
Kamarád, se kterým jsem to testoval měl ještě pár poznámek :)
Na testování input lagu je potřeba použít Arduino Leonardo (nebo klon) protože ATmega32u4 se může chovat jako klávesnice přes USB (což třeba ATmega328P v Arduino UNO neumí)
Testovací program funguje jednoduše – rozsvítí diodu na Arduinu, stiskne klávesu (v tomto případě „a“), počká 100ms, vypne diodu a pustí klávesu.
Kompletní zdrojový kód:
#include
void setup() {
// put your setup code here, to run once:
Keyboard.begin();
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
// put your main code here, to run repeatedly:
//pocka 5 vterin po zacatku
delay(5000);
//zapne LED
digitalWrite(LED_BUILTIN, HIGH);
//Stiskne klavesu a
Keyboard.press(‚a‘);
//pocka 100ms
delay(100);
//vypne LED
digitalWrite(LED_BUILTIN, LOW);
//pusti klavesu a
Keyboard.release(‚a‘);
//pocka 5s na konci
delay(5000);
}
Výpočet input lagu:
latence = počet naměřených snímku od zapnutí diody po první snímek animace / počet snímků za vteřinu v nahraném videu
latence = 6 / 240 = 0,025 = 25ms
Do měření vstupují další faktory jako například obnovovací frekvence monitoru takže se výsledky můžou mírně lišit.