Saturn vs. PlayStation vs. Nintendo64

Sega Saturn, Sony PlayStation, Nintendo 64. Która z tych konsol jest najlepsza?  Ale co to znaczy „najlepsza”? Wiadomo, najważniejsze są gry – a każda z tych konsol posiada sporą ilość tytułów, obok których nie można przejść obojętnym. Ponieważ ocena gier jest kwestią gustu, poniższym wpisem postaram się pokrótce scharakteryzować najpopularniejsze konsole V generacji od strony technicznej.

Sega Saturn

Według danych technicznych konsola posiada duże możliwości obliczeniowe. Oczywiście podane na wikipedii możliwości wyrenderowania 500tys. gołych wielokątów na sekundę, oraz 200tys. teksturowanych nie znajdują odzwierciedlenia w grach – musimy pamiętać, że są to wartości teoretyczne, prawdopodobnie możliwe do osiągnięcia w przypadku gdyby konsola nie musiała robić nic innego. A jak wygląda to w praktyce? Podczas targów E3 w 1995r. jeden z programistów ElectronicArts określił wydajność Saturna w grach na poziomie 60 tysięcy wielokątów na sekundę. Biorąc pod uwagę fakt, że mało który deweloper potrafił wykorzystać obydwa procesory konsoli, uważam że bezpiecznie możemy tą ilość zwiększyć dwukrotnie. Dużym atutem Saturna są efekty teł generowanych za pomocą układu VDP2 – stosując (bardziej zaawansowany) odpowiednik „Mode7” z SNES’a możemy wykorzystywać tła do generowania podłoża w różnego rodzaju grach oszczędzając tym sposobem niezbędne na innych konsolach wielokąty. Ciekawym rozwiązaniem wydają się być czworokątne polygony – znacznie upraszczają one siatkę modeli 3D (łatwiejsze projektowanie), oraz są bardziej odporne na mniejszą precyzję obliczeń (łamanie polygonów) oraz brak korekty perspektywy (pływające tekstury). Dzięki większej ilości dostępnej pamięci video, Saturn może używać największego dostępnego na konsolach V generacji rozmiaru tekstur, przy czym mają one często większą paletę kolorów niż te używane na konsoli Sony, co szczególnie widać w przypadku tytułów ekskluzywnych. Nie do pogardzenia jest również dzięki większej pamięci video możliwość użycia wysokich rozdzielczości (najwyższa rozdzielczość podczas gry na konsolach V generacji to 704x480 w grze Virtua Fighter 2). Główną wadą Saturna jest użycie dwóch procesorów głównych, co niesamowicie skomplikowało wydajne programowanie, w rezultacie mocno zniechęcając deweloperów do tworzenia gier na tej platformie. Ewolucję tego rozwiązania współcześnie stosuje się w nowoczesnych komputerach podnosząc wydatnie ich wydajność, jednak w czasie kiedy zostało zaimplementowane w konsoli Sega Saturn, była to nowinka którą mało kto potrafił wykorzystać. Kolejne wady to skomplikowane obsługa przezroczystości, upośledzone cieniowanie Gourauda w wyniku, czego najczęściej stosuje się cieniowanie płaskie (cieniowanie Gourauda pierwotnie zostało wymyślone do cieniowania trójkątów – czworokątny poligon mocno komplikuje sprawę, dodatkowo możliwość użycia tego cieniowania na Saturnie ograniczono jedynie do tekstur z 15bitową paletą kolorów), konieczność programowania efektów dostępnych sprzętowo u konkurencji... Wszystkie te wady dodatkowo odpychały twórców od pisania gier na Saturna.

Sony PlayStation

Dane techniczne na wikipedii to jedno wielkie pomieszanie z poplątaniem. Zacznijmy z przytupem - 1.5mln polygonów na sekundę robi wrażenie? I nie jest to liczba wyciągnięta z miejsca gdzie słonce nie dochodzi. Wartość ta pochodzi z reklamy video obecnej na jednej z płyt „Demo One” dołączanych do konsoli. Jak możemy przeczytać w różnych miejscach, taka ilość polygonów jest renderowana przez koprocesor GTE. Zaraz, zaraz, przecież GTE nie renderuje polygonów, tylko przelicza wierzchołki. I prawdopodobnie wartość 1.5mln odnosi się do wierzchołków, które potrafi ten układ przeliczyć, dzieląc na „trzy” (ponieważ każdy polygon na tej konsoli ma trzy wierzchołki) otrzymujemy możliwość przeliczenia 500tys. trójkątów. Oczywiście przy założeniu, że konsola nie zajmuje się niczym innym. Chwilę później marketingowcy Sony trochę spuścili z tonu – na pudełku od modelu SCPH-5502 możemy znaleźć informację o 360tys. cieniowanych płasko wielokątach na sekundę. Znalazłem również informację o 180tys. teksturowanych i cieniowanych metodą Gourauda. A co na ten temat mają do powiedzenia deweloperzy? Wspomniany przy okazji Saturna programista EA oceniał wydajność konsoli na 80-90tys., na pudełku z grą „Battle Arena Toshinden” znajdziemy informację o 90tys. Natomiast jeden z programistów pracujących przy grze Crash Bandicoot w jednym z wywiadów przyznał, iż pojedyncza scena w grze składa się z około 1800 wielokątów, co przy 30 klatkach animacji w jakich pracuje gra, daje wynik 54tys. Dużym plusem konsoli jest duża łatwość w programowaniu. Twórcy gier dość szybko opanowali techniki użycia dużych ilości teksturowanych wielokątów stosując dodatkowo ciekawe efekty specjalne. Oszczędzając moc potrzebną do generowania dużej liczby wielokątów, szczególnie przy projektowaniu rozległych scen 3D, programiści bardzo często używają tekstur jedynie do pokrycia obiektów pola gry, a postaci/obiekty ruchome wypleniają prostymi kolorami cieniowanymi Gouraudem (cieniowanie płaskie, mimo iż dużo szybsze, nie daje zadowalających efektów i w grach na PlayStation jest używane bardzo rzadko). Ze względu na ograniczoną ilość pamięci video, tekstury w grach na PlayStation często mają jedynie 16 kolorów, dlaczego więc gry wyglądają tak dobrze? Jako jedyna z całej trójki, konsola Sony posiada sprzętowy „dithering” obrazu, służący do symulacji płynnych przejść między kolorami. Całość opiera się na „specjalnych” właściwościach standardowych kabli AV oraz w mniejszym stopniu właściwościach telewizorów kineskopowych. Ze wglądu na słabą jakość kabli AV sąsiadujące ze sobą pixele mieszają się między sobą barwami tworząc w przypadku ditheringu wrażenie płynnych przejść miedzy kolorami (z tego samego sposobu zwiększenia palety kolorów korzystała Sega w przypadku konsoli MegaDrive/Genesis). Czar pryska po podpięciu konsoli kablami S-Video lub RGB, co gorsza do nowoczesnych odbiorników HD – płynne przejścia kolorów znikają, natomiast potęguję się efekt pixelozy (ten sam efekt dotyka tekstur z ditheringiem symulujących przezroczystość na Saturnie i PlayStation). Z powodu małej precyzji obliczeń oraz braku korekty perspektywy, w celu zniwelowania niekorzystnych efektów graficznych, na konsoli Sony wykorzystano możliwość wyrenderowania dużej ilości polygonów, poprzez dzielenie dużych obiektów na jak największą ilość wielokątów. Przy braku obecności bufora Z, PlayStation bardzo dobrze radzi sobie w „ciasnych” scenach (np. mordobicia 3D), podczas których może być widoczna większa ilość wielokątów (występuje mało przysłaniających się obiektów). Natomiast dużo słabiej wygląda generowanie dużych, rozległych terenów – duże obiekty muszą być dzielone na mniejsze, a moc jest dodatkowo marnowana na zasłonięte obiekty, dlatego też w grach, w których występują duże przestrzenie, są one dość „puste”.

Nintendo 64

Przeglądając parametry techniczne, oraz czytając o możliwościach w dziedzinie generowania grafiki 3D, Nintendo 64 jawi się jako wydajnościowy potwór, mogący pożreć na śniadanie Saturna wraz z PlayStation bez popitki. Jednak przeglądając gry stworzone na tę konsolę, możemy odnieść wrażenie, że coś poszło nie tak. Najczęstszym zarzutem odnośnie grafiki gier na N64 jest mała ilość, różnorodność oraz słaba jakość (rozdzielczość) tekstur. Winą za ten stan rzeczy zwykło się obarczać zastosowanie jako nośnika gier kartridża o zbyt małej pojemności w stosunku do nowoczesnej w tych czasach płyty CD (nawet największy wyprodukowany do Nintendo 64 kartridż o pojemności 64MB pomieści jednie 10x mniej danych niż standardowa płyta CD). Oczywiście jest to wierutna bzdura – być może pojemność nośnika danych w przypadkach ilości oraz jakości tekstur mogła mieć znaczenia na samym początku życia konsoli, gdy stosowane były bardzo małe ilości pamięci (4MB i 8MB). Posiadająca ładne i różnorodne tekstury gra Banjo-Kazooie została wydana na zaledwie 16MB nośniku. W grach wydanych na kartridżach o pojemności 32MB pojawiają się takie atrakcje jak syntezowana mowa wysokiej jakości a nawet muzyka w formacie mp3. Na nośniku o pojemności 64MB (Resident Evil 2) znaleziono nawet miejsce na wstawki video. Kolejnym argumentem zrzucającym winę z nośnika mogą być gry, które używały Expansion Pak do generowania grafiki w wysokiej rozdzielczości – w tym przypadku na kartridżu zapisywano dwa rodzaje tekstur, osobne dla niskiej i wysokiej rozdzielczości. Tak naprawdę jedyne, co straciło N64 z powodu braku napędu CD to brak ścieżek audio oraz dużej ilości wstawek FMV.

3 Grzechy główne Nintendo 64, a wszystkie związane z pamięcią.

Wszelkimi obliczeniami związanymi z generowaniem grafiki 3D na N64 zajmuje się procesor graficzny (GPU). Tak zwana sprzętowa obsługa transformacji i oświetlenia (Hardware T&L) była z powodzeniem stosowana w automatach arcade od 1993r., a N64 jest pierwszym urządzeniem domowym w którym ją zastosowano. Nowinka ta w przypadku komputerów klasy PC pojawiła się dopiero pod koniec roku 1999 w postaci karty GeForce 256. Głównym powodem przeniesienia obliczeń z procesora głównego na GPU, było odciążenie tego pierwszego, celem wykorzystania zwolnionych zasobów do przeliczenia tak ciekawych rzeczy jak fizyka środowiska czy też sztuczna inteligencja. Dzięki takiemu rozwiązaniu bardzo wydajny jak na swoje czasy procesor główny N64 dużo odpoczywa, co niestety nie jest związane z tym że nie ma on nic do „roboty” – otóż ten bardzo zaawansowany układ został pozbawiony bezpośredniego dostępu do pamięci, dlatego też w celu pobrania potrzebnych do obróbki danych musi on łaskawie prosić się o przekazanie ich przez procesor RCP (który oczywiście jest w tym czasie bardzo zajęty obróbką grafiki).

4KB pamięci podręcznej na tekstury. Z jednej strony to dwa razy więcej niż posiada PlayStation,  na którym nawet średnio rozgarnięty programista potrafił sobie poradzić z tym limitem. Na Nintendo 64 także jest możliwe ominięcie tego limitu (i niektórzy deweloperzy z tego korzystali), ale jest dość, a nawet bardzo trudne do osiągnięcia (czytaj – programiści w większości to lenie i im się nie chciało). Sprawy nie ułatwiał zakaz używania tekstur z paletą barw poniżej 16bit (niektóre gry, np. The Legend of Zelda Majora’s Mask używają tekstur 24bit). Osobiście uważam, że mieszanie w razie potrzeby tekstur 8bit oraz 16bit w wielu przypadkach mogłoby znacznie podnieść atrakcyjność gier na N64.

Przeglądając dane techniczne Saturna oraz PlayStation możemy zauważyć podział pamięci na główną (RAM), video, układu dźwiękowego, bufora odczytu CD… W przypadku Nintendo 64 zastosowano nowatorskie rozwiązanie z powodzeniem stosowane w późniejszych generacjach konsol, jakim jest zunifikowana pamięć RAM o pojemności 4MB (mniej więcej tyle samo pamięci w sumie posiada Saturn a PlayStation dokładnie o 0.5MB mniej). Dzięki takiemu rozwiązaniu to programista decyduje, jaka ilość pamięci zostanie wykorzystana jako „główna”, pozostałą część przeznaczając na pamięć video (N64 nie posiada dedykowanego układu dźwiękowego, dlatego dane dźwięku są przechowywane i obrabiane w pamięci głównej). Jednakże, aby tego typu rozwiązanie dobrze funkcjonowało, w konstrukcji konsoli musimy zastosować typ pamięci o odpowiedniej szybkości, i tak też się stało- zastosowane w konsoli pamięci Rambus DRAM pracują z zawrotną jak na ówczesne czasy prędkością 562.5MB/s. Decydując się na ten konkretny typ pamięci architekci Nintendo zostali skutecznie skuszeni odpowiednio niską ceną zakupu zaoferowaną przez producenta. Niewiele myśląc wysoka wydajność w połączeniu z niska ceną musi oznaczać, że gdzieś jest jakiś „haczyk”. W tym przypadku mamy do czynienia z ogromnym „hakiem”, którego dziwnym trafem panowie z Nintendo nie zauważyli. Przy niekwestionowanej szybkości, pamięci RDRAM okazały się cechować również dość dużą latencją, czyli czasem dostępu do poszczególnych obszarów (komórek) pamięci. Inaczej mówiąc, jeśli pobieramy/zapisujemy dane jednym ciągiem pamięć odwdzięcza się pełną prędkością (o ironio, rozwiązanie to świetnie sprawdza się przypadku odtwarzania wstawek video), natomiast, jeśli co chwile musimy zmieniać miejsce, z którego pobieram/zapisujemy dane, podczas takiej zmiany układ niesamowicie zwalnia. Obrazowo mówiąc, Nintendo kupiło samochód rozpędzający się od „zera” do „setki” w ciągu sekundy, nie zważając na fakt, iż podczas pokonywania zakrętów musi on za każdym razem zwalniać do niedorzecznej prędkości 10km/h. Ponieważ w pamięci RAM N64 przechowuje kod gry, aktualne parametry gry, modele 3D, tekstury, bufor Z, bufor ramki, dane dźwięku, dużej ilości skoków w obrębie pamięci nie da się uniknąć. Jak wynika z wywiadów z programistami najbardziej obciążającą pamięć funkcją konsoli jest bufor Z, który jest niestety automatyczną funkcją układu graficznego. Z rozwiązaniem problemu radzono sobie podobnie jak na PlayStation stosując obiekty teksturowane w połączeniu z obiektami wypełnianymi kolorem z cieniowaniem Gourauda (przy czym zabieg ten na konsoli Sony służył odciążeniu GPU, a na konsoli Nintendo służy odciążeniu pamięci). Mimo różnego rodzaju kombinacjom często nie udawało się w znaczący sposób odciążyć układu, czego efektem są (czasem mniej, czasem bardziej widoczne spadki płynności animacji) – otóż GPU renderując daną scenę, wyniki tej operacji zapisuje w buforze ramki, czyli w pamięci, jeśli w danym momencie pamięć jest mocno obciążona procesor graficzny nie ma jak/gdzie zapisać danych wynikowych. W wyniku tak niekorzystnej sytuacji dochodzi do jednego z największych absurdów w historii konsol – Nintendo 64 potrafi wygenerować więcej grafiki niż potrafi wyświetlić.

Expansion PAK – czyli proteza pamięci.

Czym jest „Expansion PAK”? To nic innego jak dodatkowa kość pamięci dokładnie tego samego typu co skrytykowany powyżej, instalowana w przeznaczonym dla niej porcie konsoli. Do czego służy? Jak możemy zaobserwować na listach atrakcji oferowanych przez gry obsługujące dodatkową pamięć, Expansion PAK umożliwia aktywowanie wyższej rozdzielczości, użycie lepszej jakości tekstur, oraz poprawy płynności animacji. O ile pierwsze dwie funkcje nie wymagają większej analizy (wyższa rozdzielność oraz większa liczba lepszej jakości tekstur po prostu wymagają większej ilości pamięci), tak już poprawa płynności animacji wydaje się być nietypową funkcją jak na coś, co jest tylko dodatkową pamięcią. Z opisanego poniżej rozwiązania korzysta niewiele gier, i osobiście spotkałem się z nim jedynie grając w „Quake II”. Uruchamiając grę z Expansion PAK, nie dostajemy opcji użycia wysokiej rozdzielczości, natomiast nasze oczy mogą cieszyć się dużo lepszą jakością tekstur, oraz zauważalnie płynniejszą animacją. Jak się domyślam (więc nie jest to oficjalna informacja) udało się to uzyskać przeznaczając pamięć wbudowaną w konsoli na RAM, a dodatkowe 4MB z Expansion PAK działa jako pamięć video, dzięki czemu obydwie kości mogą w pewien sposób pracować niezależnie od siebie.

W przypadku konsol konkurencji opisy zaczynałem od informacji na temat wydajności generowania wielokątów. Jak więc wygląda to na N64? Nintendo nigdy nie było skłonne chwalić się tego typu parametrami, deweloperzy gier również nie byli zbyt wylewni w tym temacie. Pierwsze dane mówiły o 150tys. wielokątów z użyciem wszystkich dostępnych efektów. Programista Boss Studios, na forum Beyond3D stwierdził, że w grze „World Driver Championship” udało się uzyskać ponad 100tys. polygonów na sekundę, przy czym była to liczba większa niż w grach oferowanych na konsolę PlayStation. Aktualne dane na Wikipedii, mówią o 100tys. wielokątów na sekundę w trybie „Fast” oraz 500-600tys. wielokątów w trybie „Turbo”. Powstaje pytanie, czym są, oraz czym różnią się tryby „Fast” oraz „TURBO”?

Ocean możliwości, ocean niedostępności.

W tym miejscu chciałbym opisać ostatnią już innowacje zastosowaną w konsoli N64. Otóż procesor graficzny RCP jest układem reprogramowalnym. Nie zagłębiając się w szczegóły można przyjąć, że dysponując odpowiednimi narzędziami oraz wiedzą, deweloperzy gier mogli poprawiać pracę efektów sprzętowych GPU, kasować je i zastępować nowymi/innymi. Przy czym słowami kluczami w tym przypadku są „odpowiednie narzędzia” oraz „wiedza”, którymi Nintendo nie dzieliło się zbyt chętnie (przy czym trudność w opanowaniu reprogramowania GPU przewyższająca nawet trudność programowania Saturna, skutecznie zniechęcała nawet tych, którzy dostali błogosławieństwo od wielkiego „N”). Większość programistów musiała zadowolić się standardowym udostępnionym przez Nintendo „wsadem” GPU nazwanym „Fast3D”. Wspomniany wcześniej „wsad TURBO” został stworzony przez projektanta układu RCP, oferował on wysoką wydajność przy jakości grafiki „PlayStation” (wyłączone rozmycie tekstur, mniejsza precyzja obliczeń, brak korekty perspektywy, brak bufora Z), przy czym nie został on udostępniony żadnemu z deweloperów.

W praktyce jedynie trzy zespoły deweloperskie potrafiły wykorzystać możliwości reprogramowania GPU.

RARE – podejrzewam, że odpowiednie narzędzia dostali na samym początku, i własne programy sterujące RCP na pewno zostały już wykorzystane podczas tworzenia gier „Diddy Kong Racing” oraz „Banjo-Kazooie”. W przypadku tej drugiej pozycji mamy do czynienia z funkcją multitekstur czyli nakładania dwóch lub więcej tekstur na obiekt z różnymi możliwościami mieszania ich, co znacznie poprawia wizualia gry.

Boss Studios – własne „wsady” GPU wykorzystano w grach „World Driver Championship” oraz „Stunt Racer 64”. Dzięki wyłaczeniu bufora Z oraz poprawie pracy innych efektów sprzętowych udało się uzyskać nieosiągalną wydajność w generowaniu i wyświetlaniu wielokątów.

Factor 5 – osobiście uważam, że to właśnie ta ekipa potrafiła najlepiej wykorzystać możliwości reprogramowania GPU. Szczególnie widać to w dwóch grach. Pierwsza to „Indiana Jones and the Infernal Machine” – gra szokuje niesamowitą jakością tekstur oraz efektów świetlnych (lepszych niż w wersji PC), do tego mamy do czynienia z wysoką rozdzielczością przy zachowaniu przyzwoitej płynności animacji. Całość uzyskano po raz kolejny wyłączając bufor Z, napisania od nowa obsługi kolorowych świateł, oraz największa niespodzianka – użycia kartridża z grą jako dodatkowej pamięci RAM (dane obiektów, tekstur, muzyki nie były kopiowane do pamięci RAM tylko bezpośrednio pobierane z nośnika przez CPU oraz GPU). Rozwiązanie to było możliwe dzięki dużej szybkości odczytu danych z kartridża (tylko 2x mniejsza niż prędkość RAM N64) i gdyby konsola była wyposażona w napęd CD tak wyglądająca gra nie mogłaby powstać. Drugą pozycją jest „Star Wars: Battle for Naboo” gdzie udało się wygenerować podczas gry największą na konsolach V generacji liczbę wielokątów (nieoficjalnie mówi się o 180tys. polygonów na sekundę).

Powyższy tekst stanowi podsumowanie bardziej obszernego artykułu, opisującego poszczególne etapy tworzenia scen 3D w grach na najpopularniejszych konsolach V generacji. Zainteresowanych tematem zapraszam do lektury: http://retroage.net/poradniki-techniczne/10294