Charakterystyka programowania Nintendo 64
Charakterystyka programowania Nintendo 64 opisuje elementy pisania oprogramowania dla systemu gier Nintendo 64 (N64).
Historia
Konsola Nintendo 64 została wydana w 1996 roku. W tamtym czasie The Economist opisał system jako „niezwykle złożony”. Mówiono, że trudności były połączeniem niedopatrzenia ze strony projektantów sprzętu, ograniczeń grafiki 3D, ograniczeń technologicznych tamtych czasów i problemów produkcyjnych.
Gdy Nintendo 64 dobiegło końca swojego cyklu życia, szef ds. Rozwoju sprzętu, Genyo Takeda, odniósł się do wyzwań programistycznych, używając słowa hansei ( po japońsku : 反 省 „refleksyjny żal”). Takeda powiedział: „Kiedy tworzyliśmy Nintendo 64, myśleliśmy, że logiczne jest, że jeśli chcesz tworzyć zaawansowane gry, staje się to technicznie trudniejsze. Myliliśmy się. Teraz rozumiemy, że liczy się prędkość przelotowa, a nie chwilowy błysk szczytu moc."
Pamięć
Konsola wykorzystuje pamięć Rambus DRAM o dużej przepustowości, ale o dużych opóźnieniach . Jest hostowany przez koprocesor rzeczywistości (RCP) mający wewnętrzne połączenie między procesorem sygnału rzeczywistości, procesorem wyświetlania rzeczywistości i interfejsami we/wy (w tym mikroprocesora).
Istnieje fizyczna przestrzeń adresowa, do której mapowana jest większość zasobów, w tym Game Pak, instrukcja RSP i lokalna pamięć danych , ale nie ma lokalnej pamięci tekstur RDP ani pamięci podręcznej procesora. Interfejsy RSP, RDP i IO mają własny silnik DMA, programowalny przez rejestry, które są widoczne w fizycznej przestrzeni adresowej. RSP może adresować tylko swoją pamięć lokalną i może zaprogramować swój silnik DMA. Silnik RDP DMA obsługuje bufory poleceń (tzw. listy wyświetlania); RDP ma dodatkowy interfejs pamięci do uzyskiwania dostępu do buforów wideo i danych, który może bezpośrednio pobierać dane z lokalnej pamięci RSP za pośrednictwem oddzielnej ścieżki danych.
Procesor R4300 jest podłączony do RCP przez interfejs mikroprocesora i może wykonywać zaprogramowane operacje we/wy za pośrednictwem pamięci podręcznej i interfejsu pamięci.
Procesor wyświetlania rzeczywistości
Procesor Reality Display to rasteryzator i moduł cieniujący o stałym potoku, z buforowaniem Z, wysyłający bufor ramki dla interfejsu wideo w celu zeskanowania do wyświetlacza.
Pamięć podręczna tekstur
Pamięć podręczna tekstur miała rozmiar 4 KB . Jego mały rozmiar skłonił programistów do rozciągnięcia małych tekstur na stosunkowo większej przestrzeni. Dwuliniowe filtrowanie konsoli tylko je rozmywa. Gdy mipmapowanie , wymagania dotyczące szerokości tekstury i dodatkowe miejsce na poziomy mipmap ograniczają największy poziom mipmap do 2 KB. Pod koniec cyklu rynkowego Nintendo 64 niektórzy programiści wstępnie obliczyli swoje tekstury, używając wielowarstwowego teksturowania i małych fragmentów tekstur, które były mocno zaciśnięte, aby symulować większe tekstury. Przykłady tego obejścia można znaleźć w Rare Perfect Dark , Banjo-Tooie , Conker's Bad Fur Day , aw Factor 5 Indiana Jones and the Infernal Machine . Niektóre gry o nierealistycznej estetyce wykorzystują jednokolorowe cieniowanie Gourauda zamiast teksturowania na niektórych powierzchniach (np. Super Mario 64 ).
Dużą siłą była kaseta N64. Używamy kasety prawie jak normalnej pamięci RAM i przesyłamy strumieniowo wszystkie dane poziomów, tekstury, animacje, muzykę, dźwięk, a nawet kod programu podczas działania gry. Z ostatecznym rozmiarem poziomów i ilością tekstur, pamięć RAM N64 nigdy nie byłaby nawet na tyle odległa, aby zmieścić się na jakimkolwiek indywidualnym poziomie. Tak więc technologia kartridży naprawdę uratowała sytuację.
— Factor 5, Doprowadzenie Indy do N64 , IGN
Szybkość wypełnienia
Wiele gier na Nintendo 64 ma ograniczoną szybkość wypełniania, a nie geometrię. Na przykład buforowanie Z , gdy jest włączone, stanowi znaczną część dostępu do pamięci, w przeciwnym razie potrzebnej do tekstur i bufora ramki. Optymalizacja jest możliwa poprzez wypchnięcie tej funkcji do RSP i procesora przy użyciu niestandardowego mikrokodu. Znacząca optymalizacja wydajności może zostać znaleziona za pomocą mikrokodu odpowiedniego dla każdej gry. Liczba wielokątów na sekundę Nintendo 64 wynosi około 160 000 z włączonymi funkcjami sprzętowymi. Niektóre z bardziej wielokątnych gier na Nintendo 64 to World Driver Championship , Turok 2: Seeds of Evil i Indiana Jones i piekielna maszyna .
Procesor sygnału rzeczywistości
Procesor sygnału rzeczywistości (RSP) akceptuje mikrokod , dzięki któremu programista może uzyskać dostęp do różnych operacji, tworzyć nowe efekty i optymalizować szybkość lub jakość. RSP to procesor RISC, mniej wydajny niż procesor, ale z 8-procesorowym 16-bitowym silnikiem wektorowym. Efektywne użycie tego silnika jest regulowane przez mikrokod, który definiuje małą sekwencję instrukcji dla każdej złożonej instrukcji. Promując funkcję niestandardowych mikrokodów, Nintendo początkowo odmówiło udostępnienia informacji o tym, jak korzystać z powiązanych narzędzi mikrokodów. Wynikało to z obawy, że zostanie skopiowany przez ich konkurentów. Jednak w ciągu ostatnich kilku lat konsoli Nintendo udostępniło informacje o mikrokodzie kilku programistom. Oficjalne narzędzia do kodowania Nintendo są proste, bez debuggera i słabej dokumentacji.
Domyślny mikrokod SGI dla Nintendo 64 nazywa się „Fast3D”, który według niektórych programistów był słabo sprofilowany do użytku w grach. Chociaż generuje ponad 100 000 wielokątów o wysokiej dokładności na sekundę, ten mikrokod jest zoptymalizowany bardziej pod kątem dokładności niż szybkości, co ucierpiało na wydajności. Mikrokod „Turbo3D” Nintendo umożliwia 500 000–600 000 wielokątów o normalnej dokładności na sekundę. Jednak ze względu na degradację graficzną Nintendo oficjalnie odradzało jej używanie. Firmy takie jak Factor 5 , Boss Game Studios i Rare byli w stanie napisać niestandardowy mikrokod, który podobno obsługuje ich silniki gier lepiej niż standardowy mikrokod SGI .
Jednym z najlepszych przykładów niestandardowego mikrokodu jest port N64 firmy Factor 5 gry komputerowej Indiana Jones and the Infernal Machine . Zespół Factor 5 dążył do trybu wysokiej rozdzielczości 640 × 480 ze względu na jego wyrazistość wizualną. Mówiono, że maszyna działała na granicy możliwości podczas pracy w rozdzielczości 640 × 480. Nie można było użyć bufora Z, ponieważ sam zużywał i tak już ograniczoną szybkość wypełniania teksturami. Aby obejść 4 KB pamięci podręcznej tekstur, programiści wymyślili niestandardowe formaty tekstur i narzędzia. Każda tekstura została przeanalizowana i dopasowana do najlepszego formatu tekstury pod kątem wydajności i jakości. Wykorzystali kasetę jako strumień tekstur source, aby wycisnąć jak najwięcej szczegółów w każdym środowisku i obejść ograniczenia pamięci RAM. Napisali mikrokod do oświetlenia w czasie rzeczywistym, ponieważ mikrokod dostarczony przez SGI nie był zoptymalizowany do tego zadania, a ponadto chcieli mieć więcej oświetlenia niż wersja na PC. Mikrokod Factor 5 umożliwia niemal nieograniczone oświetlenie w czasie rzeczywistym i znacznie zwiększa liczbę wielokątów. W końcu mówi się, że wersja na N64 jest bogatsza w funkcje niż wersja na PC i jest uważana za jedną z najbardziej zaawansowanych gier tego urządzenia.
Factor 5 ponownie użył niestandardowego mikrokodu w grach takich jak Star Wars: Rogue Squadron i Star Wars: Episode I: Battle for Naboo . W Star Wars: Rogue Squadron zespół zmodyfikował mikrokod silnika krajobrazu, aby tworzyć obce światy. W przypadku Star Wars: Battle for Naboo wykorzystali to, czego nauczyli się od Rogue Squadron , i sprawili, że gra działała w rozdzielczości 640×480, wprowadzając również ulepszenia dotyczące cząstek i silnika krajobrazu. Bitwa o Naboo ma duży zasięg rysowania oraz duże ilości śniegu i deszczu, nawet w trybie wysokiej rozdzielczości.
W rzeczywistości gry N64 z trybami wysokiej rozdzielczości (480i) rzadko działały w rozdzielczości 640x480, w przypadku gier Factor 5 wysoka rozdzielczość była zamiast tego ustawiona na 400x440, Turok 2, Turok 3 i Turok Rage Wars używały 480x360, podczas gdy Perfect Dark używał 640x222 w NTSC , 448x268 w systemie PAL.