W świecie retro grania, gdzie fani odtwarzają wspomnienia z ery kartridży i płyt CD, istnieją dwa główne sposoby na ożywienie klasyków: emulacja i statyczna rekompilacja. Oba mają ten sam cel – umożliwić uruchamianie gier zaprojektowanych na stare konsole na nowoczesnym sprzęcie – ale ich filozofia i sposób działania są zupełnie inne.
Spis treści
Emulacja to podejście klasyczne. Emulator symuluje całą oryginalną konsolę – procesor, pamięć, GPU, kontrolery, a czasem nawet system operacyjny – tworząc cyfrową kopię sprzętu. Dzięki temu gra może działać bez żadnych zmian w swoim kodzie, tak jak na oryginale. Statyczna rekompilacja idzie inną drogą: zamiast symulować sprzęt, tłumaczy kod gry na nowoczesny język maszynowy (np. z PowerPC na x86) jeszcze przed uruchomieniem. W praktyce, to jakby przetłumaczyć cały program z jednego języka na drugi – raz, a porządnie.
To kluczowa różnica. Emulator musi ciągle tłumaczyć instrukcje „w locie”, podczas gdy rekompilator robi to raz i może zoptymalizować efekt końcowy pod konkretny sprzęt. Ale – jak to zwykle bywa – coś za coś.
Jak działa emulacja: symulacja wszystkiego, co żyje
Weźmy przykład RPCS3, popularnego emulatora PlayStation 3. PS3 było potworem technologicznym – architektura Cell Broadband Engine łączyła klasyczny procesor PowerPC (PPU) z zestawem dodatkowych jednostek SPU (Synergistic Processing Units), które wykonywały równolegle różne zadania, np. efekty post-processingu czy dźwięk.
RPCS3 musi na bieżąco tłumaczyć instrukcje PPU i SPU na kod zrozumiały dla współczesnych procesorów x86 lub ARM. Używa do tego dynamicznej rekompilacji opartej na LLVM, dzięki czemu część kodu może być optymalizowana w locie. Brzmi świetnie – i jest to imponująca technicznie sztuka – ale to wszystko kosztuje moc obliczeniową. Emulator musi naśladować każde zachowanie sprzętu, nawet te błędy i dziwactwa, które występowały w oryginalnym CPU.
W rezultacie, choć kompatybilność jest ogromna (ponad 3000 gier działających na RPCS3!), każda gra wymaga potężnego komputera, by działać płynnie.
Jak działa statyczna rekompilacja: chirurgiczna precyzja
Z kolei statyczna rekompilacja to podejście chirurgiczne. Nie próbuje odtworzyć całego sprzętu, tylko samą grę. Przykładowo, projekty takie jak Unleash Recompiled (dla Sonic Unleashed z Xbox 360) czy Zelda 64 Recompiled (dla The Legend of Zelda: Majora’s Mask z Nintendo 64) analizują kod gry jeszcze przed jej uruchomieniem.
Oryginalne instrukcje PowerPC lub MIPS są tłumaczone na język C++ lub bezpośrednio na kod maszynowy x86, a niepotrzebne fragmenty są usuwane lub zastępowane natywnymi funkcjami systemowymi. Dzięki temu rekompilowany tytuł działa natywnie na PC, bez interpretacji w czasie rzeczywistym.
To przekłada się na ogromny wzrost wydajności. W Unleash Recompiled gra działa nawet sześć razy szybciej niż w RPCS3, bo kod jest zoptymalizowany tylko dla jednej produkcji. Nie trzeba symulować całego OS-u Xboxa, API DirectX ani dźwiękowych bibliotek Microsoftu – wszystko jest uproszczone i podmienione na nowoczesne odpowiedniki.
Przykłady różnic w praktyce
Na przykładzie PlayStation 3 różnice widać jak na dłoni. Devil May Cry 4 w wersji PC jest ponad dwa razy szybszy niż jego emulowany odpowiednik w RPCS3. Dlaczego? Bo oryginał nie wykorzystywał mocno jednostek SPU – głównie do dźwięku i dekompresji.
Za to Yakuza 0, tytuł późniejszej generacji, korzysta z SPU intensywnie – m.in. do efektu MLAA (Morphological Anti-Aliasing). Na PS3 to była sprytna optymalizacja – GPU renderowało nową klatkę, gdy SPU zajmowały się wygładzaniem krawędzi poprzedniej. Ale w emulatorze RPCS3 taki proces to koszmar: dane muszą przejść z GPU do CPU, być przetworzone przez emulowane SPU, a potem wrócić do GPU. Efekt? Spadki wydajności. Po wyłączeniu MLAA – bum, klatki rosną z 45 do 60 FPS. W Echochrome – z 130 do prawie 1000 FPS!
W projektach statycznych, takich jak Unleash Recompiled, twórcy po prostu hookują kod gry i zastępują ten fragment własnym, nowoczesnym algorytmem wygładzania w C++. Żadnej emulacji SPU, żadnych strat FPS.
Różnice w kodzie – teoria, która naprawdę robi różnicę
Dla ciekawych technicznych detali: weźmy instrukcję PowerPC unsigned division. RPCS3 tłumaczy ją wiernie, z pełną obsługą dzielenia przez zero – bo tak zachowywał się oryginalny procesor. To daje zgodność z każdą grą, ale dodaje niepotrzebny narzut. W Unleash Recompiled tłumacze wiedzą, że Sonic Unleashed nigdy nie dzieli przez zero – więc mogą zignorować ten przypadek. Kod działa szybciej, bo nie ma zbędnych warunków.
Podobnie z instrukcją SIMD VADD FP. RPCS3 musi ją zinterpretować uniwersalnie, a Unleash Recompiled może uprościć ją do natywnej instrukcji addps, wiedząc dokładnie, jak gra z niej korzysta.
W emulatorze każde takie uproszczenie byłoby ryzykiem, bo mogłoby zepsuć inne gry. W statycznej rekompilacji – przeciwnie, to celowy zabieg, który daje potężny przyrost prędkości.
GPU i grafika: największy wróg emulatorów
Emulacja GPU to często największy problem. Na PS3 za grafikę odpowiadał RSX Reality Synthesizer, bliski kuzyn GeForce’a 7800, ale z własnym zestawem komend. Emulator RPCS3 musi tłumaczyć każdy shader RSX na współczesne API, takie jak Vulkan czy OpenGL – i to w czasie rzeczywistym. Każdy błąd lub brak optymalizacji potrafi zabić płynność.
Statyczna rekompilacja podchodzi do tego inaczej. Projekty takie jak Unleash Recompiled hookują bezpośrednio kod renderujący grę i zastępują go wywołaniami DirectX. W praktyce, gra myśli, że wciąż korzysta z oryginalnego GPU, ale w rzeczywistości renderuje obraz przez współczesny interfejs graficzny.
W przypadku Zelda 64 Recompiled, autorzy użyli RT64, silnika bazującego na porcie Super Mario 64 PC. Efekt? Płynność sięga ponad 480 FPS, a gra zyskała obsługę ray tracingu.
Dlaczego rekompilacja N64 to wyższy poziom magii
Konsole takie jak Nintendo 64 były szczególnie trudne do zrekompilowania, bo gry używały tzw. overlays – fragmentów kodu ładowanych do pamięci tylko wtedy, gdy były potrzebne. To pozwalało oszczędzać RAM, ale dziś stanowi koszmar dla analityków.
Emulator radzi sobie z tym dynamicznie – ładuje kod w locie. Rekomplikator musi przeanalizować wszystkie segmenty z góry, jeszcze przed uruchomieniem gry. Wymaga to pełnej dekompilacji, zrozumienia struktury pamięci i powiązań między modułami.
To ogrom pracy, ale efekty są warte wysiłku. Gry N64 po rekompilacji startują błyskawicznie, nie mają „mikroprzycięć”, a w połączeniu z nowoczesnym API graficznym mogą wyglądać jak remastery – bez dotykania kodu gry.
Inżynieria wsteczna – fundament obu światów
Niezależnie od tego, czy mówimy o emulatorze, czy o rekompilatorze, wszystko zaczyna się od inżynierii wstecznej. To proces polegający na analizie binarnego kodu gry – bez dostępu do źródeł.
W przypadku statycznej rekompilacji, inżynierowie deasemblują instrukcje (np. PowerPC dla PS3 lub MIPS dla N64), identyfikują struktury danych, funkcje i punkty wejścia. Potem mapują offsety, odtwarzają logikę gry i tworzą narzędzia do jej „hookowania”. Dzięki temu można zastąpić całe fragmenty kodu – np. przestarzały dekoder wideo – współczesnym, napisanym w C++.
Emulacja też korzysta z inżynierii wstecznej, ale w innym celu. Przykładowo RPCS3 analizuje kod SPU, by rozpoznawać znane wzorce (np. MLAA od Sony) i zastępować je szybszymi implementacjami GPU. Dzięki temu patch działa dla wszystkich wersji gry – bez potrzeby rekompilacji.
To fascynujące, bo pokazuje, jak obie dziedziny – choć różne – korzystają z podobnych narzędzi i wiedzy.
Aspekt etyczny i prawny
Trzeba też wspomnieć o cieniach tego procesu. Inżynieria wsteczna, choć często motywowana pasją i edukacją, balansuje na granicy legalności. W wielu krajach reverse engineering jest dozwolony dla kompatybilności, ale nie dla dystrybucji zmodyfikowanego kodu.
Dlatego projekty takie jak Zelda 64 Recompiled nie udostępniają gotowych plików EXE – użytkownik musi sam dostarczyć własny ROM i uruchomić proces konwersji. Dzięki temu twórcy unikają naruszeń praw autorskich.
To też różni je od emulatorów, które same w sobie są legalne (dopóki nie zawierają BIOS-u konsoli czy fragmentów oryginalnego kodu).
Wydajność, optymalizacja i kompromisy
Emulacja jest uniwersalna – jedna aplikacja obsługuje tysiące gier, często z różnymi aktualizacjami, wersjami językowymi i łatkami. Ale ta uniwersalność kosztuje: każda gra wymaga interpretacji, a każda instrukcja jest potencjalnym punktem spowolnienia.
Statyczna rekompilacja idzie w drugą stronę – jedna gra, perfekcyjnie zoptymalizowana. Twórcy mogą zakładać, że dana funkcja nigdy nie zwróci błędu, że ABI jest spójne, że SPU nie będzie wykonywać dynamicznego kodu. W efekcie, usuwają setki sprawdzeń i filtrów, które w emulatorze są niezbędne.
To sprawia, że rekompilowany tytuł może być wielokrotnie szybszy – czasem 6–8 razy – ale nie nadaje się do uruchamiania innych gier. To jak porównać szwajcarski scyzoryk do skalpela: jeden jest uniwersalny, drugi – stworzony do precyzyjnego cięcia.
Rekomplikacja to też emulacja – ale innego rodzaju
Warto dodać, że granica między tymi podejściami nie jest aż tak sztywna. Statyczna rekompilacja to w pewnym sensie forma emulacji – zamiast symulować sprzęt, emuluje API. To trochę jak projekt Wine na Linuksa: nie udaje Windowsa, tylko implementuje jego interfejsy.
Podobnie działa Zelda 64 Recompiled – gra myśli, że rozmawia z oryginalnym systemem, a w rzeczywistości rozmawia z biblioteką, która „udaje” jego funkcje.
Podsumowanie
Emulacja to uniwersalność, kompatybilność i wierność oryginałowi. Pozwala odpalić wszystko – od Demon’s Souls po LittleBigPlanet – ale wymaga mocnego sprzętu i cierpliwości.
Statyczna rekompilacja to chirurgiczna precyzja, która skupia się na jednej grze, by wycisnąć z niej maksimum wydajności i dodać współczesne usprawnienia – wyższe rozdzielczości, ray tracing, stabilne 60 czy 120 FPS.
W praktyce, te dwa światy się uzupełniają. Emulacja toruje drogę, dostarczając wiedzy o architekturze, którą później wykorzystują projekty rekompilacyjne. Z kolei rekompilacja pokazuje, jak daleko można pójść, gdy skupimy się na jednym tytule i zrozumiemy go do ostatniego bitu.
To piękne połączenie pasji, technologii i inżynierii wstecznej – dowód na to, że retro granie to nie tylko nostalgia, ale też prawdziwa sztuka techniczna.
