ArtykułRetrospekcje

Na poligonie

Loading

Sega Saturn, Sony PlayStation, Nintendo 64. Która z tych konsol jest najlepsza? Z drugiej strony, 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. Oceniając jakość grafiki, siląc się na obiektywizm, w dzisiejszych czasach można stwierdzić, że na wszystkich trzech konsolach jest ona okropna, a nasze subiektywne oceny uzależnione są od tego, do czego przyzwyczailiśmy oczy w czasach piątej generacji. Zaryzykuje stwierdzenie, że dla retro gracza urodzonego po roku 2000, bardziej strawne dla oczu będą gry ze SNES’a i MegaDrive niż to, co oferują pierwsze konsole z grafiką „3D”. A ponieważ grafika „3D” stała się motorem napędowym piątej generacji konsol, przyjrzyjmy się zagadnieniu jej generowania przez każdą z trzech konsol – ponieważ każda z nich, podchodzi do tego tematu na trochę inny sposób. Zapraszam na poligon doświadczalny.

Polygony, polygony, a najlepiej „ich” miliony…
Przekształcane, oświetlane, teksturowane, cieniowane… ale czym tak naprawdę są „polygony”? Najprostszą nasuwającą się na myśl odpowiedzią zazwyczaj jest „to takie trójkąty”. Oczywiście rzeczywistość jest bardziej skomplikowana. Słowo „polygon” pochodzi od greckich słów „polus” czyli „wiele” oraz „gonia” czyli „kąt” – składając w całość „polusgonia” to po prostu „wielokąt”. To jedno z podstawowych pojęć geometrycznych zostało zaadaptowane do grafiki 3D jako jej najmniejszy element, przy czym, w praktyce jako „polygony” najczęściej wykorzystywane są „trójkąty” (PS1, N64) oraz bardzo rzadko „czworokąty” (3DO, Saturn). Istotną różnicą miedzy wielokątem „geometrycznym” a tym używanym podczas tworzenia grafiki 3D jest fakt, iż wierzchołki tych drugich muszą mieć opisane pozycje w przestrzeni trójwymiarowej – czyli posiadać odpowiednie wartości na osiach „x”,”y” oraz „z”.

Projektując obiekty 3D do gier, grafik musi brać pod uwagę moc obliczeniową urządzenia, na którym będzie uruchamiana gra – im więcej użyjemy wielokątów tym model będzie bardziej dokładny i „realistyczny”, ale zostaje to okupione wzrostem ilości obliczeń potrzebnych do jego dalszej obróbki. Gotowe obiekty 3D w postaci położeń wierzchołków zostają zapisane w pamięci, skąd są pobierane przez odpowiednie procesory do pierwszego etapu tworzenia sceny 3D.

Transformacja, eliminacja, elektryfikacja…

Po pobraniu przez procesor(y) położenia wierzchołków wielokątów danego obiektu, następuje umieszczenie go w przestrzeni trójwymiarowej aktualnej sceny programu (gry). W zależności od położenia względem obserwatora (kamery) obiekty są odpowiednio powiększane bądź pomniejszane oraz obracane. Na tym etapie bardzo ważna jest dokładność, z jaką przeprowadzane są obliczenia. Wszelkie operacje związane z przeliczaniem położeń wierzchołków modeli nazywamy „transformacją”.

W konsoli Sega Saturn do tego zadania zostały oddelegowane 2 główne procesory (SH2) – jak wiemy na wstępnym etapie projektowania Saturn miał być konsolą „2D”, sytuacja zmieniła się po prezentacji konsoli PlayStation, która była od początku projektowana do generowania grafiki 3D. Pojedynczy procesor SH2 nie byłby w stanie nawiązać równej walki z pierwszą konsolą Sony, dlatego w celu zwiększenia wydajności dodano drugi procesor główny, komplikując architekturę konsoli a co za tym idzie również sam proces tworzenia oprogramowania dla tego urządzenia.

Projektanci PlayStation zastosowali bardziej „specjalizowane” rozwiązanie – w układzie z procesorem głównym został umieszczony między innym dodatkowy procesor wspomagający nazwany „Geometry Transformation Engine” (GTE). To wyspecjalizowany w transformacji obiektów 3D układ, swoją wydajnością w tej dziedzinie znacznie przekraczający możliwości procesora głównego PlayStation, czy też pojedynczego procesora SH2 konsoli Saturn. Niestety sam układ nie jest idealny i sam z siebie nie potrafi wykonywać operacji z użyciem funkcji trygonometrycznych, dlatego w tym przypadku obliczenia tego typu zostają przerzucone na procesor główny.

Obydwie te konsole wszelkie obliczenia przeprowadzają na liczbach stałoprzecinkowych – co szczególnie w przypadku rozległych scen 3D jest dokładnością niewystarczającą. W wyniku różnego rodzaju uproszczeń w obliczeniach, mogą wystąpić niepożądane sytuacje, w których dwa sąsiadujące ze sobą wielokąty obiektu nie stykają się bezpośrednio ze sobą – powstaje między nimi pewnego rodzaju „przerwa na 1 pixel” widoczna dla nas jako „łamanie się” bądź dezintegracja obiektu.

Najbardziej zaawansowane rozwiązanie w temacie „transformacji” zastosowano w konsoli Nintendo 64. W przypadku tej konsoli, podczas wszelkich obliczeń związanych z przetwarzaniem obiektów 3D, procesor główny może odpoczywać – wszystkim zajmuje się procesor graficzny Reality CoProcessor (RCP). Według jego specyfikacji technicznej potrafi on wykonywać operacje zmiennoprzecinkowe, co skutkuje bardzo dużą precyzją obliczeń. Aczkolwiek sprawa obecności/zastosowania tych operacji może wydawać się dyskusyjna – jeden z programistów najbardziej zaawansowanych wyścigów na N64 (World Driver Championship) tłumaczył, iż zwiększona precyzja obliczeń jest wynikiem kilkuetapowych przeliczeń mniej precyzyjnych danych. W każdym razie N64 jako jedyna z wielkiej trójki V generacji konsol, analizuje przemieszczanie się wierzchołków wielokątów obiektów z większą dokładnością eliminując tym samym efekt ich rozjeżdżania się.

W celu zaoszczędzenia mocy obliczeniowej, kolejnym etapem jest eliminacja zbędnych (niewidocznych) wielokątów na podstawie wyników obliczeń powstałych podczas procesów transformacji. Na pierwszy ogień idą „plecy” wielokątów – jak się można domyślić umieszczony w przestrzeni 3D wielokąt będzie posiadał dwie płaszczyzny – przód oraz tył. Z góry wiadomo, że jedna z tych płaszczyzn na pewno nie będzie widoczna i z miejsca można ją wykluczyć z dalszej obróbki. Jako drugie eliminacji podlegają te wielokąty, które w wyniku transformacji nie zostaną ustawione „frontem” w kierunku kamery.

Kolejną (bardziej zaawansowaną) metodą eliminacji zbędnych obliczeń (sprzętowo dostępną jedynie na konsoli Nintendo 64) jest tak zwany „bufor Z” – to (w uproszczeniu) funkcja tworząca w pamięci dwuwymiarowy obraz sceny 3D, na którym za pomocą odcieni szarości określa się odległość poszczególnych wielokątów od widza. Na podstawie tego obrazu konsola potrafi określić, które wielokąty są przysłonięte przez inne, eliminując je z dalszej obróbki. Funkcję tę można oczywiście zrealizować na poziomie programu, dysponując odpowiednim zapasem pamięci – tak zrealizowany bardzo prosty bufor Z został zastosowany w grach Crash Bandicoot 2 oraz Crash Bandicoot 3 na konsoli PlayStation.

Poza eliminacją niewidocznych polygonów programiści stosują także inne sztuczki zwalniające zasoby mocy obliczeniowej. Zadając sobie pytanie o sens wyświetlania obiektu składającego się na przykład z kilkuset wielokątów w takiej odległości, że jest on widoczny jako „kilka pixeli”, stworzono pojęcie „drawing distance”, czyli odległość (od kamery) od której zaczynają być rysowane obiekty. Metoda ta zwalnia sporą część zasobów obliczeniowych, ale powoduje efekt „pop-up”, czyli nagłego wyskakiwania/pojawiania się obiektów na ekranie. Im w dalszej odległości obiekty się pojawiają tym efekt ten jest mniej zauważalny. Spośród gier na V generację konsol, które widziałem, najbardziej widocznym efektem „pop-up” może się „pochwalić” gra „Daytona USA” na Segę Saturn, z kolei największym „drawning distance” szczyci się „Star Wars: Battle for Naboo” na Nintendo 64.

Architekci Nintendo 64 w ograniczaniu zapotrzebowania na moc obliczeniową poszli jeszcze o krok dalej oferując „menadżera poziomu detali” (Level of Detail Managment). Ta dostępna na poziomie sprzętowym funkcja tym razem musi być wywołana z poziomu programu (gry) – czyli w przeciwieństwie do bufora Z nie jest opcją obowiązkową i automatyczną. A w uproszczeniu całość polega na odpowiedniej redukcji detali obiektów 3D wraz ze wzrostem odległości od kamery.

Na zakończenie części obliczeniowej pozostaje podłączenie prądu, a dokładniej włączenie „światła”. Jak wiadomo bez światła nic nie widać, dlatego też w obliczeniach potrzebnych do stworzenia sceny 3D należy określić źródło(źródła) światła, oraz wyliczyć intensywność z jaką dociera do poszczególnych ścian obiektów 3D korzystając z matematycznych modeli oświetlenia. Żeby było ciekawie modele te nie mają nic wspólnego z fizyką światła, i jedyną ich funkcją jest „dobrze wyglądać”. Im bardziej zaawansowany model oświetlenia, tym scena wygląda bardziej realistycznie, co oczywiście powoduje wzrost zapotrzebowania na moc obliczeniową. Podobnie jak w przypadku transformacji, obliczenia związane z oświetleniem są realizowane odpowiednio na konsoli Sega Saturn przez procesor(y) SH2, na PlayStation przez GTE, a na Nintendo 64 przez RCP.

Matematyczny obraz sceny 3D następnie jest w przypadku konsol Saturn oraz PlayStation przesyłany do procesorów graficznych w celu przeprowadzenie procesu renderingu (ponieważ obliczeniami sceny 3D w przypadku Nintendo 64 zajmuje się procesor graficzny, dane nie muszą być nigdzie przesyłane).

Tam gdzie powstają obrazy.

Przechodzimy do najciekawszego etapu powstawania grafiki 3D (chociaż w tej części artykułu będziemy się tak naprawdę zajmować grafiką 2D). Na czy polega, więc proces nazwany „renderingiem”? Nie zagłębiając się w szczegóły, jest to proces polegający na przetworzeniu matematycznego obrazu sceny 3D w pojedynczą klatkę obrazu (2D) wyświetlaną na ekranie. Podczas tej operacji możemy (a nawet powinniśmy) korzystać z jak największej ilości funkcji upiększających wielokąty. I tak naprawdę jakość obserwowanej przez gracza sceny w dużej mierze zależy od możliwości konsoli w zakresie upiększania poligonów, niż od samej ich ilości.

Najprostszym sposobem przetworzenia sceny 3D na obraz widoczny na ekranie jest połączenie liniami wierzchołków wielokątów. Powstała w ten sposób „siatka (wireframe)” mogła być atrakcyjna przy niskiej ilości polygonów dla graczy w latach ’80 ubiegłego wieku. Dlatego też na wstępnym etapie renderingu wielokąty możemy wypełnić – szybko za pomocą jednolitego koloru, lub poświęcając więcej mocy obliczeniowej procesora graficznego za pomocą „tekstury”. A czym są „tekstury”? Obrazowo mówiąc, to w zależności od potrzeb rozciągające się lub kurczące się samoprzylepne tapety, które możemy nakładać na obiekty 3D. Im lepiej wykonana tekstura, tym bardziej realistyczny wygląd obiektu. W przypadku tekstur, ograniczenia jakościowe nie są powiązane z mocą obliczeniową, a ilością dostępnej pamięci.

Parametrami, jakie mogą określać jakość tekstury są rozdzielczość oraz paleta (ilość) kolorów.

Konsola Sega Saturn jako jedyna z całej trójki, nie obsługuje w rzeczywistości tekstur – na wielokąty nakładane są odpowiednio modyfikowane znane z grafiki 2D obiekty „sprite”. W tym przypadku minimalnym rozmiarem sprite/tekstury jest 8×1 a maksymalnym 504×255 (to największy rozmiar tekstury, jaki możemy spotkać na konsolach V generacji), a dostępne palety kolorów (dla pojedynczej tekstury) mogą się ograniczać do ilości 16, 64, 128, 256 oraz 32’768 (z ogólniej liczby kolorów wynoszącej 16.777.256). Limitem ograniczającym rozdzielczość oraz wymuszającym użycie odpowiednich palet kolorów jest pamięć, jaką mogą zajmować wszystkie tekstury aktualnie renderowanej sceny – 512KB.

Sony PlayStation obsługuje tekstury w rozdzielczościach od 8×8 do 256×256 pixeli, przy czym najczęściej używane są tekstury 64×64 oraz (rzadziej) 128×128. Ciekawiej wygląda sprawa z paletami kolorów. Na wstępie z całkowitej ilości kolorów (16’777’256 – 24bit) tworzymy paletę(y) 15bit (32’768), ilość dostępnych palet jest uzależniona od dostępnej wolnej pamięci video (najczęściej stosuje się, więc 1 paletę). Po ustaleniu palety, możemy limitować ilość kolorów danej tekstury do 4bit lub 8bit (w trybie „pośrednim”) oraz do 15bit lub 24bit (w trybie „bezpośrednim”). Ze względu na maksymalną dostępną objętość pojedynczej tekstury (2KB) zazwyczaj zastosowanie znajdują tekstury 16 kolorowe (aczkolwiek istnieje możliwość obejścia tego ograniczenia odpowiednio manipulując położeniem tekstury w pamięci video – w tym przypadku limitem staje się niezbyt duża pojemność pamięci).

Najmniejszym rozmiarem tekstury może się natomiast „pochwalić” Nintendo 64 – 64×32, przy czym rozmiar ten został ograniczony jedynie przez maksymalny dozwolony rozmiar pojedynczej tekstury wynoszący 4KB. Mimo iż jest to objętość 2x większa niż w przypadku PlayStation, Nintendo zabroniło deweloperom używać tekstur z niższą paletą kolorów niż 16bit (65’536 kolorów).

Tekstury zostają nakładane na obiekty 3D w procesie zwanym „mapowaniem tekstur”. Po wybraniu odpowiedniej ściany wybranego obiektu (mogącej składać się z wielu wielokątów), możemy wypełnić ją (w zależności od wielkości ściany) poprzez kopiowanie poziome i/lub pionowe tekstury w jej pierwotnym rozmiarze lub rozciągać teksturę do rozmiaru teksturowanej powierzchni. Podczas nakładania tekstury możemy ją również dowolnie obracać.

Podczas powiększania bądź pomniejszania tekstury, konsole Saturn oraz PlayStation stosują metodę „najbliższego sąsiada”. Polega ona na kopiowaniu najbliższego pixela tekstury – w praktyce przy powiększaniu o wartości niebędące wielokrotnością rozmiaru tekstury kopiowane są tylko niektóre pixele, a w przypadku pomniejszania mamy do czynienia z pomijaniem niektórych punktów. Metoda ta wymaga niewielkiej mocy obliczeniowej, jednak cechuje się takimi wadami jak widoczność dużych grup takich samych pixeli oraz ostrymi granicami między nimi.

Według danych technicznych, konsola Nintendo 64 podczas zmiany rozmiaru tekstury automatycznie stosuje tzw. interpolację dwuliniową (bilinear filtering). Polega ona na tworzeniu płynnych przejść kolorów między pixelami powiększonej lub pomniejszonej tekstury na podstawie analizy kolorów 4 sąsiednich pixeli stykających się z powiększanym punktem.

W rzeczywistości konsola ta w celu przyspieszenia operacji używa do analizy jedynie trzech punktów (aktualnie powiększany, lewy górny oraz prawy dolny), co nadaje rozmyciu specyficzny „diamentowy” charakter.

Poza zmianą rozmiaru tekstury z użyciem interpolacji dwuliniowej Nintendo 64 posiada także inne funkcje pozwalające optymalnie nakładać tekstury na obiekty 3D. Jedną z nich jest tzw. „MIPmapping”. Technika ta polega na przechowywaniu w pamięci, trzech wersji tekstury – w rozmiarze standardowym, pomniejszonym 2x oraz pomniejszonym 4x. Tak przygotowane tekstury są nakładane na obiekty w zależności od odległości obiektu (lub jego fragmentu) od kamery. Pozwala to na uniknięcie artefaktów powstających podczas nakładania zbyt szczegółowej tekstury na obiekcie (lub jego fragmencie) znajdującym się w większej odległości od obserwatora). Technika ta, z powodu ograniczenia pamięci na główną teksturę do 2KB (w pamięci 4KB musimy zmieścić pozostałe instancje tekstury) nie jest obowiązkowa, i jej użycie jest uzależnione od programu (gry). Wykorzystując interpolację dwuliniową oraz MIPmapping Nintendo 64 potrafi zastosować filtrowanie trójliniowe tworzące płynne przejścia między dwoma poziomami szczegółowości danej tekstury.

Ostatnią funkcją (automatyczną) wyróżniającą na tym etapie N64 na tle konkurencji jest „korekta perspektywy”. Uwzględnia ona podczas nakładania tekstury kąt widzenia obserwatora, dzięki czemu unikamy załamywania bądź „pływania” tekstur na krawędziach obiektów.

Skoro już wypełniliśmy nasze wielokąty kolorami bądź teksturami, czas wykorzystać w procesie cieniowania wyniki obliczeń ilości światła docierającego do obiektów. W przypadku cieniowania płaskiego brana pod uwagę jest jasność światła padającego na daną powierzchnię obiektu, a następnie sumowana z jasnością koloru wypełnienia danej powierzchni lub jej teksturą. Cieniowanie to charakteryzuje się minimalnym wykorzystaniem mocy układu graficznego. W przypadku cieniowania Gourauda układy graficzne muszą się trochę bardziej napocić. Po pobraniu wartości jasności światła dla każdego wierzchołka polygonu zostaje na drodze interpolacji stworzone płynne przejście jasności pomiędzy trzema wierzchołkami, następnie zsumowane z jasnością koloru wypełnienia lub tekstury. Dodatkowo konsole PlayStation oraz Nintendo 64 potrafią sprzętowo obsłużyć sumowanie kolorów wypełnienia/tekstury w przypadku zastosowania kolorowych źródeł światła.

W procesie renderingu jako ostatnie przetwarzane są obiekty z określonym poziomem przezroczystości. Przeźroczystość może być realizowana na dwa sposoby – za pomocą odpowiednio przygotowanej tekstury (używającej mieszania całkowicie przezroczystych pixeli z rozpraszaniem (ditheringiem) koloru przezroczystego obiektu), oraz za pomocą obliczeń odpowiednio sumujących kolory obiektów przezroczystych z kolorami otoczenia.

Przyjęło się uważać ze Sega Saturn nie obsługuje sprzętowej przezroczystości (czyli drugiej metody). Spowodowane jest to bardzo częstym stosowaniem tekstur z ditheringiem do symulacji efektu przezroczystości, co jest wynikiem dość skomplikowanej architektury konsoli. Saturn posiada 2 procesory odpowiedzialne za wyświetlanie obrazu – VDP1 (renderujący i teksturujący poligony), oraz VDP2 (odpowiedzialny za generowanie teł 2D). Obydwa te układy potrafią sprzętowo przeliczać kolory przezroczystych obiektów, przy czym o ile VDP2 przychodzi to z łatwością, tak VDP1 potrafi w tym przypadku zwolnić nawet czterokrotnie. Na domiar złego obydwa układy niezbyt dobrze współpracują ze sobą w tej dziedzinie – o ile obiekty wygenerowane przez VDP1 ładnie prześwitują przez tła wygenerowane przez VDP2, tak przezroczystość obiektów wygenerowanych przez VDP1 dotyczy jednie ich samych (oczywiście można obejść to ograniczenie stosując różnego rodzaju sztuczki programistyczne, czego przykładem jest gra „Burning Rangers”).

W przypadku konsoli PlayStation symulacji przezroczystości za pomocą tekstur z ditheringiem używa się bardzo rzadko, w ekstremalnych przypadkach dużego zapotrzebowania na moc obliczeniową układu graficznego w innych operacjach. Sprzętowo konsola ta obsługuje 32 poziomy przezroczystości.

Najbardziej zaawansowaną (chociaż nie idealną) konsolą pod tym względem jest Nintendo 64 oferujące sprzętowo aż 256 poziomów przezroczystości. W przypadku gier na N64 praktycznie nie używa się innych metod generowania tego efektu. Przykładem najintensywniejszego wykorzystania różnego rodzaju poziomów przezroczystości jest gra „Wave Race 64”.

Gdy już mamy wyrenderowane wszystkie obiekty Nintendo 64 potrafi jeszcze dołożyć kilka efektów specjalnych.

Jednym z nich jest funkcja „depth cueing” – polegająca na ustalaniu jasności wszystkich lub wybranych obiektów w zależności od odległości od widza (w przypadku N64 jest to realizowane za pomocą miksowania wyrenderowanego obrazu z „obrazem” bufora Z). Generalnie efekt ten w połączeniu z przezroczystością jest używany do symulacji mgły lub mętnej wody.

Kolejną ciekawostką, jaką oferuje N64 jest efekt „mapowania środowiskowego” służący do tworzenia różnego rodzaju odblaskowych powierzchni. Efekt ten możemy zaobserwować w Super Mario 64 zakładając „metal cup”, błyszczący miecz i zbroje w The Legend of Zelda, wywrotka w Blast Corps, błyszcząca broń w Turok… Efektem tym bardzo często RARE traktowało swoje logo w grach. Jednym z ciekawszych sposobów wykorzystania mapowania środowiskowego na N64 możemy spotkać w grze GoldenEye – na poziomie „Library” możemy natknąć się na obszar z pokoikami posiadającymi przezroczyste okna, na których jednocześnie w pewnym stopniu możemy zaobserwować refleksy świetlne. Efekt ten jest realizowany przez umieszczenie (wirtualnej) kamery na miejscu obiektu który ma „odbijać” środowisko, a następnie wyrenderowaniu tekstury w rozmiarze 32×32, która następnie zostanie nałożona na obiekt. Przy wystarczającym zapasie mocy możemy wyrenderować i pokryć obiekt większą ilością tekstur.

Ostatnim efektem, który chciałbym opisać jest wygładzanie krawędzi obiektów. Jest to kolejna z opcjonalnych funkcji układu graficznego N64. Z powodu niskiej rozdzielczości wyświetlanego obrazu, powstaje bardzo dużo krawędzi, które sprawiają wrażenie „poszarpanych” – szczególnie objawia się to w przypadku linii, które są prawie pionowe lub prawie poziome. Podczas ruchu obiektów pojawiające się na krawędziach „schodki” wykazują duże tendencję do poruszania, co w efekcie może stać się bardzo męczące dla oczu. W celu niwelacji tego niepożądanego zjawiska stosując odpowiednie obliczenia rozjaśnia się lub przyciemnia punkty obrazu sąsiadujące z wygładzaną krawędzią.

Na koniec chciałbym zwrócić uwagę na fakt, że brak sprzętowej obsługi danego efektu na dowolnej z konsol, nie oznacza że nie można go uzyskać programowo. Wiąże się to jednak z większym zapotrzebowaniem na moc obliczeniową i/lub pamięć.

Rzutem na ekran.

Etapy obliczeniowy oraz rendering mamy już za sobą. Gotowy do wyświetlenia obraz znajduje się już w pamięci obrazu konsoli. Co nie znaczy że musimy go od razu „wysyłać na ekran”. Wszystkie trzy konsole do przechowywania obrazu używają obszaru pamięci zwanego buforem ramki. W zależności od ilości pozostałej pamięci, oraz dostępnej mocy obliczeniowej możemy sobie stworzyć kilka obrazów, które przechowywane w pamięci możemy sobie mieszać, tworzyć miedzy nimi przejścia… Możliwości są bardzo duże – możemy na bieżąco generować obraz 3D wyścigów samochodowych, na który będziemy nakładać wygenerowany wcześniej obraz kokpitu samochodu, możemy mieszać szybko zmieniające wyrenderowane sceny z bardziej stałymi „obrazami” liczników punktów bądź energii. Stosując efekty znane z grafiki 2D, możemy obracać, powiększać, pomniejszać wyrenderowane sceny tworząc efekty „wirowania” obecne np. przy przejściach w tryb bitewny w grach z serii Final Fantasty. Kolejnym ciekawym wykorzystaniem efektów bufora ramki są telebimy w grach Mario Kart 64 i 1080 Snowboarding, gdzie mamy do czynienia z wycięciem pewnego fragmentu obrazu, zmianą jego rozmiaru, oraz wklejeniem w inne miejsce obrazu.

W skrócie – plusy i minusy całej trójki.

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 Electronic Arts 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 704×480 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). Kilkakrotnie już wspominałem, że ze względu na ograniczoną ilość pamięci 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ą.

W dziale poświęconym transformacji wielokątów, możemy przeczytać, że 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 jak już pisałem wcześniej ś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 jak już wiemy, jest 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ę).

Postscriptum

Czyli część nieoficjalna, zawierająca zakazane treści, mogąca generować konsolowe wojenki.

Jeśli zastanawialiście się czy istnieje możliwość samodzielnego sprawdzenia ilości obrabianych wielokątów przez daną konsole podczas zabawy w różne gry, odpowiedź brzmi niestety nie. Istnieje jednak metoda pośrednia (na pewien sposób niedoskonała, dlatego też wyników pomiarów nie możemy brać za pewnik). Wykorzystując komputer PC oraz program 3D-Analyze możemy zbadać między innymi ilość wielokątów generowanych przez dowolną aplikacją korzystającą z Dicerct3D lub OpenGL. A gdyby tą aplikacją był emulator konsoli? (tak, nie przywidziało się wam – emulator). Najlepiej gdyby program ten był jak najnowszy i najdokładniejszy. Ponieważ żadna gra nie wykorzystuje w pełni możliwości Saturna (tak naprawdę nie znalazłem dobrego emulatora tej konsoli działającego na moim laptopie), pominąłem tę konsolę w testach. Do testowania gier na PlayStation użyłem najnowszej wersji emulatora ePSXe, a do testowania gier na Nintendo 64 emulatora PJ64. W każdą z testowanych gier „pograłem” maksimum 5min.

Wartości podane w tysiącach polygonów/sekundę i pochodzą z wersji NTSC gier.

PlayStation:

Demo T-Rex: 45

WipeOut: 33-56

Crash Bandicoot: 33-69

Ridge Racer Type 4: 40-70

Demo Manta: 75

Spyro 3 Year of the Dragon: 20-90

Final Fantasy IX: 20-91

Battle Arena Toshinden: 80-93

Tekken: 70-111

Driver: 70-114

Tekken 3: maksimum 120,średnio 105

Gran Turismo 2: na linii startowej do 130, wyścig 70-94, replay 105-130

Ridge Racer Hi-spec (demo): maksimum 133, średnio 90

Nintendo 64:

Mario Kart 64: 10-24

Turok 2: 15-60

Super Mario 64: 25-67

Mace the Dark Age: 70-80

Pilotwings 64: 40-86

SW: Shadows of the Empire: Hoth 30-102

Doneky Kong 64: maksimum 102

Conker’s Bad Fur Day: maksimum 123 w trakcie gry, natomiast podczas animacji początkowej (gdy wiewiór wchodzi do baru – menu głównego gry) możemy chwilowo zaobserwować liczbę 185, a podczas intro w sali tronowej licznik na moment podskakuje do wartości 194

Perfect Dark: maksimum 137

Rocket Robot on Wheels: maksimum 141.5

World Driver Championship: 123-145

Jet Force Gemini – maksimum 165

Autor

Komentarze

  1. Wow, rewelacyjny artykuł, jeden z najlepszych jakie tu czytałem! Gratuluję wiedzy i umiejętności przekazania jej w przystępny sposób 😉

    No i w końcu wiem co się dzieje na zrzutach VRAMu z PSXa: Spyro i Time Crisis

  2. Obficie i w miare szczegolowo przeanalizowane. W sumie obawiam sie o zrozumienie tekstu w przypadku niezbyt zaawansowanychtechnicznie uzytkownikow, ale taki material jest potrzebny w necie, bo nigdzie do tej pory nie widzialem takiej piguly 🙂 Gratulacje dla tbxxa za checi i wytrwalosc w zglebianiu tajnikow 🙂

  3. Ponownie przeczytałem i artykułjest świetny, mnóstwo ciekawych informacji i pomimo swojej długości tekst czyta się jednym tchem.

  4. „Obydwie te konsole wszelkie obliczenia przeprowadzają na liczbach całkowitych ”

    A nie przypadkiem na stałoprzecinkowych (jak fixed_t 16.16 w Doomie)?

    Duży plus za zwrócenie uwagi na korekcję tekstur od perspektywy, to bardzo ciekawy problem, szczególnie, że gdzieś chyba czytałeś o tym, że Playstation nie używało (czy to prawda?) współrzędnych jednorodnych. Dla mocniej zainteresowanych, wyjaśnienie ten problemu (ang) https://youtu.be/zPLfyj-Szow?t=38m0s

    1. Wybacz, że komentarz pod komentarzem, ale:

      „Aktualne dane na Wikipedii, mówią o 100tyś. wielokątów na sekundę w trybie „Fast” oraz 500-600tyś. wielokątów w trybie „Turbo”. Powstaje pytanie, czym są, oraz czym różnią się tryby „Fast” oraz „TURBO”?”

      Czy nie chodziło Ci przypadkiem o wymienny mikrokod? Układ graficzny N64 był programowalny i moc obliczeniową można było przesuwać (np. tracąc niektóre funkcje by zyskiwać więcej trójkątów). Inaczej mówiąc Turbo nie był lepszy od Fast czy odwrotnie, a po prostu przeznaczony do innych obciążeń. Tutaj notka o mikrokodzie używanym przez Mario Kart 64 https://github.com/RenaKunisaki/mariokart64/wiki/F3DEX

      1. Tak, „fast” i „turbo” to są microcode ładowane do RCP. W akapicie „Ocean możliwości, ocean niedostępności.” o tym napisałem.

  5. Przez określenie „„Obydwie te konsole wszelkie obliczenia przeprowadzają na liczbach całkowitych ” chciałem w miarę prosto oddać fakt że Saturn i PlayStation przeliczają przemieszczanie się wierzchołków z „pixel precision” a Nintendo 64 z „sub-pixel precision”. I tak procesory Saturna i PlayStation używają przeliczeń stałoprzecinkowych, a Nintendo 64 może używać zmiennoprzecinkowych.

    1. Porządna robota. Gratulacje!

      Popraw tylko „tyś.” na „tys.” oraz fragment dotyczący obliczeń „na liczbach całkowitych” -> „na liczbach stałoprzecinkowych”, bowiem to za duże uproszczenie, wręcz błąd.

  6. Super artykuł, pokazujący mojego ukochanego Saturna w dobrym świetle :). A i N64 nie ma się czego wstydzić :).

    Rzeczowy tekst, dużo się dowiedziałem.

  7. Fajnie napisane, przeczytałem w wolnej chwili w pracy chociaż nie lubię typowo technicznych artykułów w temacie gier.

  8. Ten artykuł to coś czego szukałem bez skutku przez ostatnie 2 lata i zdecydowanie najbardziej wartościowy dla mnie tekst związany z retro graniem z jakim się w tym czasie zetknąłem. Wielkie brawa dla ciebie! W końcu nie tylko będę umiał wskazać i opisać różnice w wyglądzie gier na Saturn/PSX/N65, ale również będę mógł je nazwać i wyjaśnić, co z pewnością przyda się w wielu dyskusjach ze znajomymi miłośnikami retro 3D i pozwoli mi odkryć odłożone już na półkę gry na nowo, właśnie po to, aby tę wiedzę przetestować. Dzięki!

  9. Naprawdę tłusty materiał. Choć części technikaliów kompletnie nie zrozumiałem to i tak czytało się świetnie. Lektura akurat w sam raz na plażę.

  10. Materiał świetny. Doskonale napisany, czytelny i łatwy do przyswojenia. Powiem szczerze – niewiele nowego się dowiedziałem 🙂 . Ale to dlatego, że sam się tym interesowałem (ale nie wiedziałem np. że kartridż N64 można było wykorzystać jako pamięć).

    Szkoda, że nie ma gry cross-platformowej gdzie można by porównać organo-leptycznie – ilość polygonów, jakość grafiki i dźwięku (na raz). Brawa dla autora za stworzenie tej pigułki wiedzy !!! Za to kocham ten serwis 🙂 .

  11. Dzięki za budujące komentarze. Sam długo szukałem podobnego tekstu. Nie znalazłem, więc postanowiłem go napisać;) Przed publikacją miałem wątpliwości czy takie techniczne bajdurzenie znajdzie większe grono odbiorców – jak widać niepotrzebnie.

  12. Kartridz to podstawa pamieci w przypadku kazdej konsoli korzystajacej z tego nosnika. Bez tego niewiele daloby sie zdzialac tak na prawde. Dla przykladu Atari ma 128 bajtow pamieci (to o wiele mniej niz dlugosc tego komentarza), a NES 2kb (+2 na video ram) – to mniej niz pol strony tekstu! Dzieki temu ze dane sa na kartridzu to mozliwosci sa o wiele wieksze i dzieki temu taka np. Contra wyglada tak jak wyglada mimo ze konsola NES ma o 32 razy mniej pamieci niz takie np. C64. Pamiec na kartridzu dziala jak ROM (w rzeczywistosci jest to wymienny ROM). To tak jakbys mial wyciagalny BIOS z PC i wkladajac inna kostke mial calkiem inny program.

  13. Może sprecyzujmy, pamięć ROM jest tylko do odczytu i służy do przechowywania programu (gry). Pamięć RAM służy do odczytu i zapisu. W skrócie kawałek kodu z pamięci ROM jest odczytywany do pamięci RAM i w tej też pamięci jest przetwarzany przez procesor i inne chipy, przetworzony kod jest wypluwany w postaci obrazu na naszym TV. Pamięć na koniec lat 70 i początku 80 była bardzo droga, dlatego Atari ma tylko 128 bajtów RAM a NES 2KB RAM, chodziło tylko i wyłącznie o koszty produkcji. Konstruktorzy projektując Atari, tworzyli sprzęt na którym pójdzie pong, czyli kawałek kwadratu odbijany od lewej do prawej przez dwóch graczy czyli 128 bajtów RAM powinno styknąć. Na stworzenie bardziej zaawansowanych tytułów to niestety za mało np. Pitfall (gra ma tylko 4kb i w tamtym czasie było to mistrzostwo w kodowaniu), dlatego na karcie była zainstalowana dodatkowa pamięć RAM. Na wielu kartach było wbudowane 256 bajtów dodatkowej pamięci RAM.

    Gdy sobie porównamy grafikę z NES do np. C64, gdzie NES miał 2KB RAM a C64 64KB RAM, to od razu widać że na kartach był dodatkowy RAM i taka Contra nie poleci na 2KB, zwłaszcza że wygląda sporo lepiej niż większość gier z C64.

    Na kartach instalowano również dodatkowe chipy wspomagające renderowanie 2D i 3D np. chip Super FX, dzięki któremu można zobaczyć grafikę 3D na konsoli SNES (np. gry Star Fox i Doom). Fajnie by było jakby ktoś podjął się napisania artykułu na ten temat.

    1. Troche zamieszales ale w wiekszosci masz racje (szczegolnie z tym pakowaniem dodatkowych ficzerow do kartridzy). Bledem jest natomiast sugerowanie ze kawalek kodu z pamieci ROM jest odczytywany do pamieci RAM i tam przetwarzany. Duzo zalezy od konkretnej konstrukcji z ktora mamy do czynienia. Kod programu sam w sobie jest w ROMie na karcie i absolutnie nie musi byc przenoszony do RAMu. Malo tego, da sie np. stworzyc na NESa kod ktory kompletnie nie bedzie wymagal RAMu w konsoli – wystarczy nie uzywac zmiennych. Grafike tez bezposrednio da sie przerzucac do pamieci graficznej bez udzialu RAMu konsoli. Oczywiscie nie kazdy sprzet da sie w ten sposob efektywnie wykorzystac i predzej czy pozniej dane w RAMie i tak laduja (szczegolnie w przypadku N64).

  14. Uzupełniłem artykuł w części dotyczącej filtrowania tekstur (przez konsolę N64), dzięki czemu można lepiej zrozumieć dlaczego gry na emulatorze tej konsoli nie wyglądają tak samo jak na „prawdziwym sprzęcie”.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.