Już w pierwszych sekundach gry na NES-ie lub jego polskim klonie – Pegasusie – wielu graczy zauważało irytujące migotanie sprite’ów. Postacie przez ułamki sekund znikały z ekranu, pociski stawały się niewidzialne, a całe sceny zamieniały się w chaotyczne stroboskopowe widowisko. Dla ówczesnych graczy był to po prostu „urok” konsol tamtej epoki – coś, do czego się przyzwyczajało tak samo jak do pikselowej grafiki czy ośmiobitowego dźwięku. Niewielu jednak zdawało sobie sprawę, że za tym pozornie przypadkowym zjawiskiem kryła się bardzo konkretna, techniczna przyczyna zakodowana głęboko w architekturze sprzętu.
To nie była kwestia złego wykonania gry ani błędu w kodzie – to nieuchronna konsekwencja twardych ograniczeń sprzętowych z lat 80., z którymi programiści musieli się mierzyć każdego dnia swojej pracy. Procesor graficzny NES-a, znany jako PPU (Picture Processing Unit), dysponował ściśle określonym limitem obiektów, które był w stanie wyrenderować jednocześnie w pojedynczej poziomej linii skanowania ekranu. Kiedy gra przekraczała ten limit – a w gorących momentach rozgrywki działo się to nieuchronnie – konsola po prostu przestawała rysować nadmiarowe sprite’y, co obserwator widział właśnie jako migotanie lub chwilowe znikanie obiektów.
Zjawisko było szczególnie dotkliwe w dynamicznych scenach: podczas starć z bossami otoczonymi rojami pocisków, w momentach wielkich eksplozji, gdy ekran dosłownie męczył wzrok od efektów wizualnych, czy w trybie kooperacji dla dwóch graczy, gdzie liczba aktywnych obiektów automatycznie się podwajała. Kultowe gry takie jak Contra, Mega Man 2 czy Super Mario Bros. cierpiały na to najbardziej właśnie dlatego, że były wyjątkowo akcyjne – ich projektem było wypychanie sprzętu poza granice możliwości, co z jednej strony dawało niesamowitą jak na tamte czasy intensywność rozgrywki, z drugiej zaś wywoływało właśnie te charakterystyczne wizualne artefakty.
Co ciekawe, doświadczeni programiści tamtej ery nie siedzieli z założonymi rękami – opracowali szereg sprytnych technik, by problem przynajmniej częściowo zamaskować lub uczynić mniej uciążliwym. Migotanie bywało celowe i kontrolowane: zamiast pozwolić, by sprite po prostu znikał losowo, programiści sprawiali, że znikał regularnie co kilka klatek, co dawało wrażenie pewnej przewidywalności i było łatwiejsze do zaakceptowania przez oko gracza niż całkowite, nieregularne wypadanie obiektów z ekranu.
Dziś, dzięki zaawansowanej emulacji i filtrom korekcyjnym dostępnym w programach takich jak RetroArch czy Mesen, możesz przeżyć te klasyczne tytuły bez tego problemu – emulatory potrafią uśredniać klatki i eliminować migotanie niemal całkowicie, zachowując jednocześnie autentyczny wygląd gry. Zanim jednak sięgniesz po te udogodnienia, warto zrozumieć, z czego dokładnie wynikał ten fenomen. Rozbijmy go zatem na czynniki pierwsze – oto 7 kluczowych przyczyn migotania sprite’ów i sposoby, w jakie ówcześni programiści próbowali je maskować.
Czym były sprite w konsolach NES i Pegasus?
Zanim zrozumiemy, dlaczego sprite’y migotały, warto najpierw wyjaśnić, czym w ogóle były i jaką rolę odgrywały w architekturze graficznej NES-a oraz jego polskiego klonu – Pegasusa.
Sprite to niezależny, ruchomy obiekt graficzny wyświetlany na tle statycznego lub przewijanego tła, które w żargonie technicznym nazywało się po prostu backgroundem. O ile tło stanowiło jednolitą, stosunkowo nieruchomą warstwę – krajobraz, ściany lochów, niebo – o tyle sprite’y były tym wszystkim, co się na nim poruszało i żyło. To właśnie w tej kategorii mieściły się postacie gracza i jego przeciwników, wszelkiego rodzaju pociski wystrzelone z broni czy rzucone przez wrogów, a także krótkotrwałe efekty wizualne takie jak błyski eksplozji, iskry czy kłęby dymu. Innymi słowy: wszystko, co nadawało grze dynamikę i poczucie akcji, istniało właśnie w postaci sprite’ów.
Zarządzanie nimi leżało w gestii dedykowanego układu graficznego, który w NES-ie nosił nazwę PPU, czyli Picture Processing Unit. To właśnie ten chip odpowiadał za odczytywanie danych o sprite’ach z pamięci i rysowanie ich we właściwych miejscach ekranu w odpowiednim momencie – klatka po klatce, linia skanowania po linii skanowania, z precyzją, której wymagał sygnał telewizyjny.
Każdy sprite miał ściśle określone, niezmienne rozmiary. PPU obsługiwał dwa tryby: sprite’y o wymiarach 8 na 8 pikseli, używane najczęściej do mniejszych obiektów jak pociski czy drobne efekty, oraz sprite’y o wymiarach 8 na 16 pikseli, które pozwalały na odrobinę bardziej szczegółowe postacie. Paleta kolorów była równie surowo ograniczona – każdy sprite mógł korzystać z zaledwie czterech kolorów jednocześnie, przy czym czwarty „kolor” był zawsze transparentny, co pozwalało na wyświetlanie tła znajdującego się za spritami. Te pozornie proste reguły miały jednak ogromne konsekwencje dla tego, jak dużo obiektów mogło znaleźć się na ekranie naraz – i właśnie tutaj zaczyna się historia migotania.
Gdzie leżała przyczyna ?
Głównym winowajcą migotania sprite’ów była architektura samego PPU, który renderował obraz w sposób charakterystyczny dla ówczesnej technologii telewizyjnej – linia po linii, z góry na dół ekranu. Każda z tych poziomych linii skanowania miała twardy, nienaruszalny limit: mogło się na niej pojawić maksymalnie osiem sprite’ów jednocześnie. Nie było tu żadnej elastyczności ani mechanizmu awaryjnego – jeśli w danym miejscu ekranu programista chciał wyświetlić dziewiąty obiekt, PPU po prostu go ignorował i przechodził do kolejnej linii. To właśnie ten fundamentalny limit był bezpośrednią przyczyną migotania, które gracze obserwowali na ekranach swoich telewizorów.
Drugim ograniczeniem, które działało w parze z limitem linii skanowania, była pojemność pamięci OAM, czyli Object Attribute Memory. To właśnie tam przechowywane były wszystkie dane o sprite’ach – ich pozycja pozioma i pionowa na ekranie, oraz atrybuty takie jak kolor czy odbicie lustrzane. Problemem był fakt, że OAM mieściła dane zaledwie sześćdziesięciu czterech sprite’ów łącznie. W spokojnych scenach limit ten był trudny do osiągnięcia, ale w gorących momentach rozgrywki konsola dobijała do niego błyskawicznie.
Było to szczególnie odczuwalne w grach, które z założenia stawiały na intensywną akcję i dużą liczbę jednoczesnych obiektów na ekranie. Contra, Mega Man 2 czy gry z „Kuniem”. cierpiały na migotanie najbardziej właśnie dlatego, że ich projektanci celowo wypychali sprzęt poza granice możliwości – walki z bossami otoczonymi chmurami pocisków, wielkie eksplozje rozsadzające pół ekranu czy tryb kooperacji dla dwóch graczy, w którym liczba aktywnych sprite’ów automatycznie rosła, regularnie przekraczały zarówno limit OAM, jak i limit ośmiu obiektów na linię skanowania.
Warto jednak podkreślić, że migotanie nie było błędem projektowym ani niedopatrzeniem inżynierów Nintendo. Było świadomym kompromisem, wynikającym z realiów ekonomicznych tamtej epoki. W latach 80. pamięć była towarem luksusowym, moc obliczeniowa procesorów graficznych – znikoma w porównaniu z dzisiejszymi standardami, a koszt produkcji konsoli musiał pozostać na poziomie, który pozwalał dotrzeć z produktem do masowego odbiorcy. NES miał być tani i dostępny, a to oznaczało konieczność podejmowania trudnych decyzji o tym, z czego zrezygnować.
Jak sobie radzono z tym ograniczeniem ?
Programiści tamtej epoki nie pozostawali jednak bierni wobec tego ograniczenia i opracowali kilka sprytnych metod jego maskowania. Najpopularniejszą techniką była rotacja sprite’ów między klatkami – zamiast pozwolić, by nadmiarowe obiekty po prostu nie pojawiały się losowo, kod gry świadomie zarządzał kolejnością ich wyświetlania tak, by w jednej klatce rysować jedne obiekty, a w następnej inne. Dla ludzkiego oka efektem było migotanie, ale przynajmniej kontrolowane i przewidywalne, a nie chaotyczne.
Innym podejściem było ograniczanie liczby aktywnych przeciwników, łączenie kilku małych obiektów w jeden większy sprite zajmujący mniej wpisów w OAM, czy wreszcie staranne projektowanie poziomów tak, by najbardziej zatłoczone momenty nie nakładały się na siebie w tej samej linii skanowania. Niektóre studia radziły sobie z tym lepiej, inne gorzej – i właśnie ta różnica w umiejętnościach programistycznych często decydowała o tym, jak bardzo dany tytuł był podatny na migotanie.
Co możemy z tym dzisiaj zrobić ?
Współcześni gracze sięgający po te klasyczne tytuły za pośrednictwem emulatorów takich jak Mesen, puNES czy RetroArch mają do dyspozycji narzędzie, które całkowicie eliminuje opisany problem. Kluczową funkcją jest opcja wyłączenia sprzętowego limitu sprite’ów, znana jako „Remove Sprite Limit” – emulator po jej aktywacji ignoruje oryginalne ograniczenie ośmiu obiektów na linię i renderuje wszystkie sprite’y jednocześnie, bez żadnego pomijania. Efekt jest natychmiastowy: migotanie znika całkowicie, a obraz staje się stabilny i czytelny. Emulatory oferują również filtry graficzne, skalowanie do wyższych rozdzielczości oraz symulację ekranu kineskopowego CRT, choć te opcje poprawiają jedynie komfort wizualny, nie usuwając samej przyczyny problemu.
Decyzja o włączeniu tej opcji nie jest jednak tak oczywista, jak mogłoby się wydawać. Usunięcie limitu sprite’ów oznacza, że gra nie działa już dokładnie tak, jak na oryginalnym sprzęcie, co dla purystów retro jest kwestią zasadniczą. Co więcej, niektóre gry zostały zaprojektowane z myślą o tym ograniczeniu i mogą zachowywać się nieoczekiwanie po jego wyłączeniu – na przykład balans trudności może ulec zmianie, jeśli pociski, które na NES-ie migotały i chwilowo znikały, nagle stają się stale widoczne i łatwiejsze do uniknięcia. Dla jednych to poprawa, dla innych – zdrada oryginalnego doświadczenia.
Podsumowując – klątwa czy czar NES-a?
Podsumowując, migotanie sprite’ów to nie bug, lecz feature – nieunikniona konsekwencja genialnie oszczędnej inżynierii Nintendo, która pozwoliła na stworzenie rewolucyjnych gier w epoce, gdy każdy bajt i cykl procesora się liczył. Dzięki emulatorom jak RetroArch czy Mesen możesz dziś grać bez tego „uroku”, ale pytanie brzmi: czy naprawdę tego chcesz?
A Wy, drodzy retrogracze? Czy migotanie sprite’ów na NES-ie lub Pegasusie przeszkadzało Wam w tamtych szalonych sesjach z Contra czy Mega Man 2, czy macie do niego ciepły sentyment jako nieodłączny element nostalgii z lat 80.? Włączacie opcję „remove sprite limit”, by gra była płynna jak nigdy, czy broniliście oryginalnego doświadczenia, nawet kosztem chaotycznego stroboskopu? Podzielcie się w komentarzach swoimi historiami – jaka gra sprawiła, że narzekaliście na ten efekt (lub kochaliście go najbardziej)? Czekam na Wasze wspomnienia i dyskusję!
