Geneza mocy GameCube. Jak fioletowa kostka pozostała najbardziej niedocenioną konsolą swojej generacji
GameCube miał fioletową obudowę, uchwyt do przenoszenia i płyty wyglądające jak miniaturki właściwych nośników. W epoce czarnych, agresywnie reklamowanych multimedialnych kombajnów sprawiał wrażenie zabawki. Pod plastikiem kryła się jednak znakomicie przemyślana architektura. Nie była najmocniejsza w każdej kategorii, nie obyła się bez wad, ale zaprojektowana tak, żeby można było z niej wiele wycisnąć. GameCube nie imponował liczbami, ale zachwycał pod wieloma względami. Przeczytajcie jego techniczną historię.
Trudno o konsolę, której reputacja tak bardzo rozminęła się z tym, co siedziało w środku. GameCube sprzedał się w liczbie 21,74 mln egzemplarzy, a więc wyraźnie słabiej nawet od Nintendo 64, które osiągnęło 32,93 mln. PlayStation 2 przekroczyło 160 mln sztuk, a pierwszy Xbox, mimo znacznie krótszej obecności na rynku, dobił do około 24 mln. Piękna kostka została więc w tyle. Dziś pamiętamy ją głównie przez pryzmat kapitalnych gier Nintendo, nietypowego pada, uchwytu oraz płyt, które łatwiej było zgubić niż poważnie zarysować. Znacznie rzadziej mówi się o tym, jak rozsądnie zbudowano jej wnętrze.
Nie znaczy to, że GameCube był skrytym potworem mocniejszym od wszystkiego wokół. Xbox miał większą i bardziej elastyczną pamięć, programowalne shadery, dysk twardy oraz dużo większe możliwości. PlayStation 2 dysponowało z kolei niesamowitą przepustowością lokalnej pamięci układu graficznego oraz jednostkami wektorowymi, które w rękach najlepszych programistów pozwalały dokonywać cudów. Porównywanie samych megaherców, liczby wielokątów i gigaflopsów prowadzi więc donikąd. Architektury tych konsol różniły się zbyt mocno, aby jedna większa liczba rozstrzygała całą dyskusję.
GameCube zasługuje na uznanie z innego powodu. Nintendo postanowiło zbudować sprzęt, który rzadziej dławił się własnymi ograniczeniami i pozwalał stosunkowo szybko dotrzeć do znacznej części deklarowanej wydajności. Jego moc nie brała się wyłącznie z procesora Gekko ani układu graficznego Flipper. Rodziła się pomiędzy nimi: w sposobie przesyłania poleceń, organizacji pamięci, krótkich czasach dostępu oraz wyspecjalizowanych blokach zdejmujących z programistów część najcięższej pracy. GameCube był w dużej mierze odpowiedzią na problemy Nintendo 64. Sprzętem zaprojektowanym przez ludzi, którzy wiedzieli już, gdzie poprzednia konsola potrafiła bez ostrzeżenia wyłożyć się na zakręcie.
Zbudować anty-Nintendo 64
Nintendo 64 nie było słabą maszyną. W odpowiednich rękach potrafiło generować obrazy, które pod koniec lat 90. trudno było pogodzić z pojemnością kartridża i skromną ilością pamięci. Problem polegał na tym, że dostęp do tej mocy wymagał wyjątkowo uważnego programowania. Satoru Iwata wspominał po latach, że dodanie jednego efektu lub podniesienie jakości grafiki mogło nagle zniszczyć płynność całej sceny, a twórcy nie zawsze wiedzieli, który fragment systemu właśnie się zatkał. Kiedy wszystko udało się odpowiednio nastroić, N64 było niezwykle szybkie. Gdy choć jeden element układanki przestał pasować, wydajność spadała i zaczynało się mozolne szukanie przyczyny.
Genyo Takeda, stojący na czele projektu nowej konsoli, chciał zerwać z takim podejściem. Nie interesował go układ GPU czy CPU, który osiąga rewelacyjny wynik w idealnie przygotowanym demie, ale w normalnej grze wymaga ciągłego omijania pułapek. Zadanie przekazane partnerom było proste tylko na papierze: stworzyć szybką maszynę, z której programiści rzeczywiście będą mogli korzystać. Bez jednego efektownego podzespołu dominującego nad resztą, bez kosztownych akrobacji potrzebnych do utrzymania płynności i bez wydajności dostępnej wyłącznie dla kilku najlepszych zespołów na świecie. To ważne, ponieważ GameCube nie powstawał z myślą prezentacji technologicznej pychy. Nintendo otwarcie mówiło, że zamiast bezużytecznej wydajności szczytowej woli wynik możliwy do utrzymania podczas prawdziwej rozgrywki. Firma chciała również skrócić produkcję i ograniczyć rosnące koszty tworzenia gier. Łatwość programowania nie była więc miłym dodatkiem do potężnej konsoli. Stanowiła jeden z najważniejszych warunków całego projektu.
Pierwsze prace rozpoczęły się w 1998 roku pod kryptonimem Dolphin. Za serce graficzne odpowiadało ArtX, niewielka firma założona przez byłych pracowników Silicon Graphics. Nie byli to przypadkowi inżynierowie. Część zespołu wcześniej pracowała nad Project Reality, z którego narodziło się Nintendo 64. Na jego czele stał Wei Yen, wcześniej kierujący działaniami SGI związanymi z Nintendo. Japończycy wrócili więc do ludzi znających zarówno mocne strony poprzedniej konsoli, jak i rachunek wystawiony programistom za jej mniej udane decyzje. W 2000 roku ArtX zostało kupione przez ATI za około 400 mln dolarów. To stąd wzięło się logo ATI umieszczone na GameCube, ale nie należy mylić Flippera z konsolową odmianą któregoś z Radeonów. Układ projektowano od podstaw dla Nintendo, a w chwili przejęcia zasadnicza część prac była już ukończona. Dopiero później ludzie ArtX odegrali ważną rolę przy powstaniu R300, czyli architektury wykorzystanej między innymi w słynnym Radeonie 9700. Flipper nie był jego pomniejszoną wersją, choć oba projekty łączyła część wyjątkowo zdolnego zespołu.
Lista partnerów była zresztą dłuższa. IBM przygotował procesor Gekko, MoSys dostarczył technologię pamięci 1T-SRAM, NEC produkował Flippera w procesie 180 nm, a Matsushita odpowiadała za technologię napędu optycznego. Nintendo musiało połączyć pomysły kilku firm i dwa odmienne sposoby myślenia. Inżynierowie z Doliny Krzemowej chcieli pokazywać, co potrafi ich najnowsza technologia. Takeda pilnował, aby żaden element nie urósł kosztem równowagi, ceny i potrzeb gier. Sam wspominał, że nakłonienie partnerów do schowania technicznej dumy do kieszeni należało do najtrudniejszych etapów prac.
Najlepiej pokazuje to zmiana specyfikacji dokonana przed premierą. Początkowo procesor Gekko miał działać z częstotliwością około 405 MHz, natomiast Flipper z częstotliwością 200 MHz. Ostatecznie CPU przyspieszono do około 485 MHz, a GPU zwolniono do 162 MHz. Na pierwszy rzut oka wyglądało to jak krok wstecz w najważniejszym dla graczy miejscu. W rzeczywistości Greg Buchner z ATI tłumaczył, że to twórcy gier poprosili o szybszy procesor, a oba układy musiały pracować w relacji opartej na całkowitym mnożniku. Nintendo przeszło więc z proporcji 2:1 na 3:1. Flipper nie został spowolniony dlatego, że nie osiągał zakładanego zegara, tylko postanowiono zmienić balans całej maszyny. To pozornie niewielki szczegół, ale kapitalnie streszcza sposób myślenia stojący za GameCube. Nintendo nie broniło efektownie wyglądającej tabeli. Posłuchało programistów i przesunęło zasoby tam, gdzie były bardziej potrzebne. Szybszy Gekko lepiej radził sobie ze sztuczną inteligencją, fizyką, animacjami, przygotowywaniem geometrii i obsługą logiki gry. Flipper miał natomiast dość wyspecjalizowanych bloków oraz lokalnej pamięci, aby przy 162 MHz nadal sprawnie wykonywać własne zadania.
Jednocześnie konsola miała pozostać mała i niedroga. W Stanach Zjednoczonych kosztowała na premierę 199 dolarów, o 100 dolarów mniej od PS2 i Xboxa. Gekko zajmował zaledwie około 43 mm² i pobierał niecałe 5W, a wiele funkcji systemu zintegrowano we Flipperze. Z zewnątrz powstała kostka o wymiarach mniej więcej 15 x 11 x 16 cm, z uchwytem, który dla jednych był uroczym detalem, a dla innych ostatecznym dowodem, że Nintendo wyprodukowało zabawkę. Technicznie niewielka obudowa wynikała jednak z bardzo konsekwentnego projektu, a nie z chęci zrobienia plastikowego pudełka na drugie śniadanie.
Moc, która nie mogła dłużej czekać
Gekko był 32-bitowym procesorem PowerPC opartym na rodzinie 750, kojarzonej również z komputerami Apple jako generacja G3. Nie miał nic wspólnego z magicznymi „128-bitami”, które w tamtym czasie producenci przypinali do niemal wszystkiego, co posiadało odpowiednio szeroki rejestr lub magistralę. Pracował z częstotliwością 485 MHz, dysponował dwiema jednostkami całkowitoliczbowymi, jednostką zmiennoprzecinkową, obsługą wykonywania instrukcji poza kolejnością oraz rozbudowanym przewidywaniem rozgałęzień. Kiedy jedna operacja czekała na dane, procesor mógł rozpocząć inną, niezależną pracę, zamiast bezczynnie odliczać cykle.
Do tego dochodziły pamięci podręczne: po 32 KB L1 na instrukcje i dane oraz 256 KB zunifikowanej L2 umieszczonej bezpośrednio na układzie. Połowę cache danych L1 można było skonfigurować jako 16-kilobajtowy scratchpad, czyli niewielki obszar ręcznie zarządzanej, bardzo szybkiej pamięci. Gekko otrzymał również jednostkę DMA oraz bufor write-gather, pomagający zbierać polecenia graficzne w większe porcje przed wysłaniem ich do Flippera. Brzmi mało widowiskowo, ale właśnie takie elementy decydowały, czy procesor i GPU faktycznie pracują, czy głównie czekają na kolejną paczkę danych. Najciekawszym dodatkiem były instrukcje Paired Singles. Jeden 64-bitowy rejestr mógł przechowywać dwie 32-bitowe liczby zmiennoprzecinkowe, a Gekko wykonywał na nich równoległe działania. W uproszczeniu: zamiast liczyć osobno dwie współrzędne wektora, procesor mógł zająć się obiema podczas jednego cyklu. Przyspieszało to operacje na macierzach, transformowanie geometrii, animacje, obliczenia fizyki oraz część efektów przygotowywanych przed wysłaniem danych do GPU. Nie znaczy to, że Gekko renderował grafikę za Flippera. Po prostu został zaprojektowany tak, aby szybko przygotowywać materiał, którym układ graficzny miał się później zająć.
Sam procesor nie tłumaczy jednak, dlaczego GameCube osiągał tak dobre rezultaty. Najważniejszym elementem całej maszyny była pamięć. Nintendo po doświadczeniach z N64 uznało, że nie wystarczy szeroka magistrala i wysoki wynik w gigabajtach na sekundę. Gry nie przenoszą wyłącznie długich, pięknie ułożonych bloków. Bez przerwy sięgają po małe fragmenty geometrii, animacji, kodu, parametrów obiektów i tekstur rozrzucone w różnych miejscach. Jeśli każdy taki odczyt zaczyna się od długiego oczekiwania, nawet szybki CPU przez sporą część czasu nie robi kompletnie nic. Dlatego 24 MB głównej pamięci, nazwanej Splash, wykonano w technologii 1T-SRAM firmy MoSys. Jej przepustowość sięgała 2,6 GB/s, ale ważniejsze było opóźnienie wynoszące około 10 ns. Dla porównania używanego przez Iwatę, cała pamięć zachowywała się trochę jak dodatkowy, ogromny poziom cache. Nie chodziło o to, że GameCube miał najszerszą autostradę. Chodziło o możliwie szybkie otwieranie kolejnych wjazdów. Przy częstych, niewielkich i losowych odczytach różnica mogła być ogromna.
Trzeba przy tym uważać na nazwę. 1T-SRAM nie była klasyczną pamięcią SRAM, w której każdy bit wykorzystuje sześć tranzystorów i nie wymaga odświeżania. Technologia MoSys korzystała z gęstszych, podobnych do DRAM komórek oraz dodatkowej logiki, cache i kontrolera ukrywającego operacje charakterystyczne dla pamięci dynamicznej. Z punktu widzenia pozostałych podzespołów zachowywała się jednak podobnie do SRAM: oferowała szybki dostęp losowy bez konieczności ciągłego uwzględniania banków, odświeżania oraz innych szczegółów organizacji DRAM. Było to rozwiązanie sprytne, ale nie magiczne.
Skromna pojemność pozostawała pierwszym poważnym ograniczeniem GameCube. Oficjalnie Nintendo mówiło o 40 MB pamięci systemowej, tylko że nie wszystkie megabajty były sobie równe. 24 MB szybkiej 1T-SRAM stanowiło właściwy obszar roboczy. Kolejne 16 MB to ARAM, czyli pomocnicza pamięć DRAM przeznaczona przede wszystkim na dźwięk i buforowanie mniej pilnych danych. Łączyła się z systemem przez wąską, 8-bitową magistralę, a transfer DMA do głównego RAM-u osiągał około 60–70 MB/s. Można było składować tam animacje, grafikę i fragmenty kodu, ale trzeba było wcześniej przerzucić je do szybkiej pamięci. Nie był to odpowiednik 64 MB zunifikowanej pamięci Xboxa. Factor 5 przekonało się o tym podczas produkcji Star Wars Rogue Leader. Twórcy porównywali ARAM do niewielkiego ROM-u i napisali własny system pamięci wirtualnej, aby łatwiej mapować znajdujące się tam dane. Rozwiązanie pozwoliło nawet przenosić do wolniejszego obszaru wybrane części kodu i uniknąć ręcznego przygotowywania nakładek. Z jednej strony pokazuje to elastyczność sprzętu. Z drugiej - jeżeli studio tworzące grę startową musiało zbudować dodatkową warstwę zarządzania, trudno udawać, że 40 MB pamięci GameCube tworzyło wygodną przestrzeń.
Jeszcze ciekawiej robiło się we Flipperze. Układ pracował z częstotliwością 162 MHz, ale był czymś więcej niż zwykłym GPU. Łączył silnik graficzny, kontroler pamięci, procesor dźwięku oraz obsługę wejścia i wyjścia. Miał 51 mln tranzystorów, z czego około połowę przeznaczono na 3 MB wbudowanej pamięci 1T-SRAM. To najlepszy dowód na priorytety ArtX. Zamiast poświęcić cały dostępny krzem kolejnym jednostkom liczącym wielkie liczby do folderu reklamowego, firma zainwestowała znaczną część układu w to, aby najważniejsze operacje nie musiały wyjeżdżać do pamięci zewnętrznej. Dwa megabajty tworzyły EFB, czyli wbudowany bufor obrazu i głębi. Tam wykonywano między innymi testy głębi, zapisywanie koloru, mieszanie przezroczystości oraz antyaliasing. EFB miał wystarczającą przepustowość, aby obsłużyć cztery piksele w jednym cyklu. Gotowy obraz kopiowano później do zewnętrznego bufora w głównej pamięci, skąd pobierał go układ wyjścia wideo. Dzięki umieszczeniu koloru i głębi wewnątrz Flippera typowe operacje nie musiały stale rywalizować o dostęp do głównej magistrali.
Pozostały 1 MB stanowił TMEM, czyli lokalna pamięć tekstur. Można było wczytać do niego wybrane mapy w całości albo wykorzystać część przestrzeni jako sprzętowy cache. Jeśli potrzebnego fragmentu tekstury nie było pod ręką, układ próbował pobrać go z głównej 1T-SRAM odpowiednio wcześnie, zanim dane dotarły do etapu nakładania tekstur. Flipper obsługiwał też kompresję S3TC, dzięki której powierzchnie zajmowały mniej miejsca i wymagały mniejszej liczby transferów. Te rozwiązania nie zwiększały magicznie 24 MB RAM-u, ale pozwalały znacznie sprawniej nim gospodarować.
Potok graficzny Flippera składał się z kilku wyspecjalizowanych części. Command Processor odczytywał polecenia i dane wierzchołków. Transform Processor zajmował się przekształceniami geometrii, oświetleniem wierzchołków, odrzucaniem niewidocznych powierzchni oraz przygotowywaniem współrzędnych tekstur. Rasterizer zamieniał trójkąty w piksele, Texture Processor pobierał i filtrował tekstury, a Pixel Engine odpowiadał między innymi za głębię, mieszanie kolorów i antyaliasing. Pomiędzy nimi pracował element, który w dużej mierze określił charakter grafiki GameCube - Texture Environment Processor, znany jako TEV.
Flipper nie miał programowalnych shaderów pikseli w rozumieniu GeForce’a 3 i układu NV2A z Xboxa. TEV był rozbudowanym procesorem stałofunkcyjnym, pozwalającym łączyć do ośmiu tekstur w maksymalnie 16 etapach. Każdy etap pobierał kolory, wartości alfa, stałe oraz wyniki wcześniejszych operacji, a następnie mieszał je według określonego równania. Programista nie mógł napisać zupełnie dowolnego programu, ale z przygotowanych klocków dało się składać zaskakująco skomplikowane materiały: bump mapping, mapy detali, projekcyjne cienie, cel-shading, refleksy, maski, rozbudowaną mgłę czy nietypowe efekty oświetlenia.
Julian Eggebrecht z Factor 5 porównywał TEV do wielkiej tablicy połączeń. Można było poprowadzić przez nią kilka warstw, obracać je względem siebie, modyfikować, wykorzystywać wyniki poprzednich etapów i dopiero na końcu wyprodukować kolor piksela. Nie był to pełnoprawny shader, ale stwierdzenie, że GameCube „nie potrafił generować shaderów”, prowadzi do błędnych wniosków. Nie miał nowoczesnego modelu programowania shaderów. Potrafił jednak uzyskiwać wiele podobnych efektów inną drogą, często z bardzo dobrą wydajnością. Każdy dodatkowy etap kosztował oczywiście czas. Rasterizer przetwarzał cztery piksele na cykl, więc przy 162 MHz teoretyczny fill-rate wynosił 648 mln pikseli na sekundę. Dotyczyło to jednak najprostszego wariantu z jednym etapem TEV. Dwa etapy obniżały tempo do 324 mln, cztery do 162 mln, osiem do 81 mln, a szesnaście do około 50 mln pikseli. To doskonały przykład, dlaczego pojedyncza liczba ze specyfikacji prawie nigdy nie opowiada całej historii. GameCube mógł generować ogromne ilości prostych pikseli albo mniejszą liczbę bardziej złożonych. Cudów nadal nie było.
Nintendo zachowywało zresztą nietypową ostrożność przy liczbie wielokątów. Oficjalnie podawało od 6 do 12 mln trójkątów na sekundę w warunkach zbliżonych do prawdziwej gry, a więc z teksturami, oświetleniem i złożonymi modelami. Sam Transform Processor mógł w określonych konfiguracjach osiągać od 20 do 32 mln wielokątów, ale był to wynik szczytowy zależny od liczby włączonych funkcji. Zamiast wystawiać do walki największą cyfrę, producent próbował opisać poziom, który dało się zobaczyć na ekranie. Po latach brzmi to wręcz egzotycznie.
EFB także wyznaczał konkretne granice. Mieścił maksymalnie obraz o rozdzielczości 640 x 528 z 24-bitowym kolorem i 24-bitowym buforem głębi. Sprzętowy antyaliasing korzystał z trzech próbek na piksel, poprawiając krawędzie i ograniczając migotanie, ale zmniejszał precyzję bufora głębi do 16 bitów. Obraz wyższy niż 240 linii nie mieścił się wtedy w jednym przebiegu i wymagał podzielenia pracy. GameCube obsługiwał 480p w części gier, lecz był sprzętem zaprojektowanym dla telewizorów SD. W przeciwieństwie do Xboxa nie miał realnych ambicji sięgania po 720p. Na osobny akapit zasługuje dźwięk. Wbudowany we Flippera 16-bitowy DSP Macronix pracował z częstotliwością 81 MHz, obsługiwał sprzętową dekompresję ADPCM, zmianę częstotliwości próbkowania, filtrowanie, miksowanie oraz do 64 głosów. Dzięki temu Gekko nie musiał zużywać dużej części czasu na podstawowe operacje audio. Rogue Leader jako pierwsza gra wykorzystała kodowanie Dolby Pro Logic II, zapewniające przestrzenny dźwięk przy zachowaniu zgodności ze zwykłym sygnałem stereo. Nie było to dyskretne, cyfrowe 5.1, lecz jak na konsolę z 2001 roku rezultat pozostawał imponujący.
Genialny rdzeń otoczony kompromisami
Rogue Leader jest najlepszym dowodem na to, że założenia Nintendo rzeczywiście działały. Właściwa produkcja ruszyła w styczniu 2001 roku, a gotową grę trzeba było dostarczyć we wrześniu. Factor 5 zrealizowało w około dziewięć miesięcy projekt planowany na piętnaście. Nie obyło się bez potężnego crunchu, pracy przez sześć lub siedem dni w tygodniu i problemów z narzędziami. Nikt rozsądny nie powinien przedstawiać tej historii jako beztroskiej zabawy z idealnym devkitem. Mimo wszystko studio dostarczyło na premierę jedną z najbardziej efektownych gier całej generacji. Twórcy wykorzystali wielowarstwowe tekstury do budowania powierzchni planet. Podstawowe, powtarzalne wzory łączono za pomocą prostych czarno-białych mix-map określających, gdzie ma pojawić się piasek, skała lub inny rodzaj podłoża. Warstwy można było obracać względem siebie, a powtarzalność ukrywano bez potrzeby przechowywania jednej gigantycznej tekstury. Całość uzupełniały mapy wypukłości i detali. To podręcznikowy przykład wykorzystania TEV oraz sprzętowej kompresji do obejścia ograniczonej pamięci.
Równie duży skok dokonał się w logice świata. Na Nintendo 64 przeciwnicy w Rogue Squadron i Battle for Naboo w dużej mierze poruszali się po wcześniej przygotowanych trasach. W Rogue Leader nadal korzystano z takich ścieżek, ale zachowanie dużych grup wspierały algorytmy flockingu reagujące na pozycję gracza i wydarzenia podczas misji. Lepsza wydajność CPU nie poszła więc wyłącznie w dodatkowe wielokąty. Pozwoliła ożywić bitwy i dać projektantom większą kontrolę nad tym, co naprawdę dzieje się na ekranie.
Kolejne gry pokazywały inne strony architektury. Metroid Prime trzymał 60 klatek na sekundę, jednocześnie wyświetlając gęste efekty cząsteczkowe, parę, deszcz, zmiany wizjerów i rozbudowane otoczenie. Retro Studios opanowało streaming danych tak, aby kolejne pomieszczenia doczytywały się za zamkniętymi drzwiami. Charakterystyczna pauza przed ich otwarciem czasem zdradzała całą sztuczkę, ale w większości przypadków gracz otrzymywał spójny świat bez tradycyjnych ekranów wczytywania. The Legend of Zelda: The Wind Waker udowadniało natomiast, że stylizowana grafika nie oznacza małych wymagań. Płynne przejścia kolorów, światło, cienie, mimika postaci, deformacje modeli, przezroczystości i warstwowe materiały idealnie pasowały do możliwości TEV. To nie była oprawa przygotowana po to, aby ukryć słabości GameCube. Nintendo wybrało kierunek, w którym wyspecjalizowany układ mógł błyszczeć, a przy okazji stworzyło grę starzejącą się znacznie wolniej niż wiele realistycznych produkcji z tamtego okresu.
F-Zero GX pędziło w 60 klatkach na sekundę, rzucało na tor do 30 pojazdów i nieustannie zmieniało perspektywę kamery pojazdu na poskręcanych trasach. Powstało we współpracy z Segą i otrzymało automatową wersję F-Zero AX działającą na systemie Triforce, opartym na technologii GameCube. Z kolei Resident Evil 4 budowało gęste, szczegółowe lokacje, dużą liczbę przeciwników, efekty ognia, mgły i pyłu oraz scenki generowane przez silnik gry. Późniejszy port na PS2 był imponującym osiągnięciem, ale wymagał uproszczonych tekstur, modeli, oświetlenia i efektów, a scenki zastąpiono nagraniami wersji gamecube’owej. Kostka wyraźnie pokazała wtedy przewagę w typowym renderowaniu grafiki 3D.
Czy oznacza to, że GameCube był mocniejszy od PlayStation 2? Taka odpowiedź byłaby zbyt wygodna. Konsola Nintendo miała bardziej konwencjonalny potok graficzny, sprzętowe filtrowanie tekstur, S3TC, szybki cache tekstur i architekturę, której zachowanie łatwiej było przewidzieć. PS2 dysponowało potężnymi jednostkami wektorowymi, ogromną przepustowością 4 MB lokalnej pamięci Graphics Synthesizera i wyjątkowym fill-rate’em. Wymagało jednak znacznie więcej ręcznego planowania transferów oraz rozdzielania pracy między procesor, VU0, VU1 i GPU. Dlatego typowy port często wyglądał czyściej na GameCube, szczególnie w zakresie jakości tekstur i ich filtrowania. Ale najlepsze zespoły potrafiły na PS2 osiągać rezultaty, których nie dało się sprowadzić do prostego stwierdzenia, że jedna maszyna jest zawsze silniejsza od drugiej. Gran Turismo 4, Metal Gear Solid 3, God of War II czy Shadow of the Colossus nie powstały wbrew sprzętowi. Powstały dzięki ludziom, którzy nauczyli się wykorzystywać jego bardzo specyficzną konstrukcję. PS2 miało trudniej dostępny potencjał. GameCube szybciej oddawał do dyspozycji znaczną część własnego.
Jeszcze wyraźniej trzeba oddzielić kostkę od Xboxa. Maszyna Microsoftu miała 64 MB pamięci zunifikowanej, procesor 733 MHz, układ Nvidia NV2A z programowalnymi shaderami, dysk twardy, napęd DVD i wbudowany Ethernet. Jej większa elastyczność stawała się coraz ważniejsza wraz z przechodzeniem branży na nowoczesne silniki oraz materiały projektowane pod shaderowy model grafiki. Julian Eggebrecht twierdził, że GameCube dorównuje Xboxowi i potrafi odtworzyć te same efekty innymi technikami. Rogue Leader oraz późniejszy Rebel Strike stanowią mocne argumenty na poparcie tych słów. Nie zmienia to faktu, że Xbox miał więcej pamięci i większe możliwości. Najuczciwiej powiedzieć, że Xbox był ogólnie potężniejszy, natomiast GameCube znajdował się znacznie bliżej niego, niż sugerowały częstotliwości procesora i rozmiar obudowy. W określonych zadaniach, szczególnie związanych z wielowarstwowym teksturowaniem i szybkim buforem obrazu, Flipper wypadał znakomicie. Tylko że starcie konsol rozgrywało się już nie wyłącznie na ekranie. Tutaj zaczynały się problemy, których nawet najlepiej zbalansowany zestaw układów nie mógł naprawić.
Pierwszym była pamięć. 24 MB szybkiego RAM-u ograniczało opóźnienia, ale pod koniec generacji coraz częściej brakowało pojemności. ARAM pomagał w buforowaniu dźwięku, animacji i mniej pilnych danych, lecz wymagał transferów DMA i uważnego zarządzania. Gry budowane z myślą o 64 MB Xboxa nie zawsze dawało się zmniejszyć bez usuwania części tekstur, kompresowania dźwięku albo przebudowy systemu streamingu. Zespół tworzący ekskluzywny tytuł mógł projektować silnik wokół tych ograniczeń. Studio wykonujące szybki port często nie miało na to czasu ani budżetu. Drugim ograniczeniem był TEV. W 2001 roku zapewniał ogromne możliwości i bardzo przewidywalną wydajność, ale branża skręcała w stronę programowalnych shaderów. Efekt przygotowany dla Xboxa lub PC dało się często odtworzyć przez odpowiednie połączenie tekstur, kolejne etapy albo dodatkowy przebieg renderowania. Nie znaczy to jednak, że zawsze odbywało się to bez kosztów. Stały zestaw funkcji przypomina świetnie wyposażony warsztat: pozwala szybko wykonać większość typowych prac, lecz gdy pojawia się zadanie, dla którego nie przygotowano właściwego narzędzia, zaczyna się kombinowanie.
Najbardziej widocznym kompromisem była płyta. GameCube Disc mieścił dokładnie 1 459 978 240 bajtów, czyli około 1,46 GB. Nie był zwykłym mini-DVD, choć korzystał z technologii optycznej rozwijanej przez Matsushitę i miał z DVD wiele wspólnych cech. Własny format utrudniał kopiowanie, pozwalał zastosować niewielki napęd i kończył bolesną epokę drogich kartridży. Napęd pracował w trybie CAV, osiągał około 2-3 MB/s, miał cache oraz mechanizm pobierający z wyprzedzeniem dane położone za ostatnio odczytanym fragmentem. Technicznie nie był złym urządzeniem.
Pojemność pozostawała jednak ponad trzykrotnie mniejsza od jednowarstwowego DVD. Przy grach tworzonych bezpośrednio na GameCube można było zaplanować kompresję, streaming i rozmiar zasobów od początku. Porty z PS2 oraz Xboxa wymagały już cięcia filmów, agresywniejszej kompresji dźwięku, zmniejszania tekstur albo wydania gry na dwóch dyskach. Resident Evil 4, Tales of Symphonia, Baten Kaitos czy Metal Gear Solid: The Twin Snakes nie bez powodu zajmowały po dwie płyty. Problem, którego Nintendo próbowało pozbyć się wraz z kartridżami N64, wrócił w znacznie łagodniejszej, ale nadal dokuczliwej postaci. Mały dysk odebrał GameCube także funkcję odtwarzacza DVD. Dziś może się to wydawać drobiazgiem, ale na początku 2000 roku zakup PS2 bywał najtańszym sposobem wprowadzenia DVD do salonu. Sony sprzedawało grę, konsolę i modny sprzęt multimedialny w jednym pudełku. Nintendo odpowiadało, że GameCube służy przede wszystkim do grania, a filmy i internet to jedynie konkurencja dla gier. Brzmiało konsekwentnie, ale rynkowo było fatalne PRowo.
Podobnie wyglądało wsparcie sieci. GameCube dostał osobny modem oraz Broadband Adapter, a jego porty pozwalały na znacznie więcej, niż ostatecznie wykorzystano. Brakowało jednak wbudowanego Ethernetu, dysku twardego i spójnej usługi porównywalnej z Xbox Live. Phantasy Star Online, Homeland oraz kilka eksperymentów nie tworzyły ekosystemu. Nintendo zbudowało sprzęt, który teoretycznie mógł wejść do internetu, po czym prawie nic z tym nie zrobiło. Do tego dochodził wizerunek. Fioletowa obudowa, małe płyty oraz gry z Mario i Linkiem wyglądały niewinnie w chwili, gdy duża część rynku chciała GTA, Halo, Metal Gear Solid 2, Final Fantasy X i sportowe hity. GameCube miał Resident Evil, Eternal Darkness, Metroid Prime, Killer7, Viewtiful Joe i własnego Metal Geara, więc sprowadzanie jego biblioteki do produkcji dla dzieci jest zwyczajnie nieuczciwe. Tylko że w wojnie o nastoletniego klienta wrażenie bywało ważniejsze od pełnej listy premier.
Sprzęt nadawał się do portowania znacznie lepiej niż Nintendo 64, ale najlepsza architektura nie wybiera gier za wydawców. GameCube nie otrzymał żadnego Grand Theft Auto, głównych odsłon Final Fantasy ani wielu strzelanin budujących tożsamość Xboxa. Mniejsza baza użytkowników zmniejszała opłacalność kolejnych konwersji, słabsze wyniki portów prowadziły do ograniczenia wsparcia, a uboższy katalog jeszcze bardziej zniechęcał nowych klientów. Klasyczne błędne koło, tylko tym razem trudno było zrzucić całą winę na procesor i GPU. Właśnie dlatego wynik 21,74 mln egzemplarzy tak słabo opisuje GameCube. Konsola nie przegrała, ponieważ nie potrafiła generować dostatecznie dobrej grafiki. Jej wnętrze było szybkie, eleganckie i zaskakująco rozsądne. Przegrała, ponieważ odpowiadała przede wszystkim na problemy programistów, podczas gdy rynek kupował również filmy DVD, GTA, Final Fantasy, Halo, rozgrywkę sieciową i poczucie uczestnictwa w nowoczesnej kulturze. Kostka rozwiązała problem wydajności, której nie dało się wykorzystać. Nie rozwiązała problemu atrakcyjności całej platformy.
Najlepszym dowodem jakości projektu został paradoksalnie następca. Wii nie zerwało z możliwościami GameCube, lecz rozwinęło jego fundamenty. Procesor Broadway wywodził się z tej samej linii co Gekko, układ Hollywood rozwijał pomysły Flippera, a konsola zachowała zgodność z grami, kontrolerami i kartami pamięci poprzedniczki. Nintendo dołożyło więcej RAM-u, podniosło zegary i zbudowało wokół sprawdzonej architektury zupełnie nowy sposób sterowania. Ta sama technologiczna rodzina, która w fioletowej kostce nie zdołała podbić rynku, stała się podstawą maszyny sprzedanej w ponad 100 mln egzemplarzy.
GameCube nie był najmocniejszą konsolą szóstej generacji. Był czymś ciekawszym: maszyną, której inżynierowie rozumieli, że prawdziwa wydajność zaczyna się dopiero tam, gdzie kończy się tabela ze specyfikacją. Gekko, Flipper i 1T-SRAM zrobiły dokładnie to, czego od nich wymagano. To decyzje podjęte wokół tych układów sprawiły, że piękna kostka została zapamiętana jako sympatyczny przegrany zamiast jednego z najlepiej zaprojektowanych systemów początku XXI wieku.
Przeczytaj również
Komentarze (20)
SORTUJ OD: Najnowszych / Najstarszych / Popularnych