Obsah
1. Historie vývoje počítačových her (109. část – herní konzole Sony PlayStation: dokončení)
2. Další důležité parametry grafického subsystému herní konzole Sony PlayStation
3. Příkazy pro vykreslování a pro konfiguraci grafické pipeline
5. Textury a texturovací jednotka
7. Geometry Transformation Engine
8. Zvukový subsystém herní konzole Sony PlayStation
1. Historie vývoje počítačových her (109. část – herní konzole Sony PlayStation: dokončení)
V dnešní části seriálu o historii vývoje her i herního hardware dokončíme popis základních technických parametrů dnes již téměř legendární herní konzole Sony PlayStation. V úvodních kapitolách přímo navážeme na předchozí díl, v jehož závěru byla popsána struktura framebufferu a taktéž všechny typy grafických primitiv (geometrických tvarů a spritů), jejichž vykreslování bylo podporováno přímo v renderovací jednotce (součást GPU). Popíšeme si především různé režimy vykreslování, díky nimž bylo umožněno například simulovat mlhu, poloprůhledné objekty atd. Posléze si alespoň ve stručnosti popíšeme takzvaný GTE (Geometry Transformation Engine), zvukový subsystém a taktéž jednotku CD-ROM, protože právě dobrá podpora této technologie znamenala pro Sony PlayStation velkou konkurenční výhodu v porovnání s některými jinými herními konzolemi páté generace, které využívaly především paměťové moduly (typickým příkladem je Nintendo 64, jehož podrobnějším popisem se budeme zabývat příště).
Minule jsme si mj. řekli, že herní konzole Sony PlayStation je založena na několika čipech vykonávajících veškerou práci při vykreslování dvourozměrného či třírozměrného herního světa i při práci se zvukem a hudbou. Základním čipem je samozřejmě vlastní hlavní mikroprocesor s architekturou RISC (odvozený od čipu R3000A), kterému při práci sekundoval grafický procesor, neboli GPU (Graphics Processing Unit), jenž prováděl vykreslování do framebufferu o kapacitě jednoho megabajtu. Hlavní mikroprocesor sice neobsahoval klasický FPU (jednotku pro práci s hodnotami s plovoucí řádovou čárkou), ovšem namísto toho obsahoval pro herní konzoli mnohem praktičtější modul nazvaný GTE (Geometry Transformation Engine), jenž se používal – jak již ostatně jeho název napovídá – k výpočtům s vektory a maticemi, což jsou operace používané (nejenom) v 3D grafice. Dnes je tato jednotka součástí každého moderního grafického akcelerátoru.
2. Další důležité parametry grafického subsystému herní konzole Sony PlayStation
Činnost GPU (Graphics Processing Unit) v herní konzoli Sony PlayStation lze zjednodušeně popsat následujícím způsobem: GPU postupně načítá vykreslovací a nastavovací příkazy uložené do lineárně vázaného seznamu a každý příkaz postupně provádí (v pořadí odpovídajícímu pořadí načítání příkazů). Pokud se načte vykreslovací příkaz, provede se rasterizace příslušného grafického primitiva (bod, úsečka, obdélník, otexturovaný obdélník, sprite, …) v rasterizační jednotce GPU. Rasterizace spočívá ve vyplnění všech pixelů tvořících obraz grafického primitiva.
Při vykreslování se přitom na základě aktuálně nastaveného režimu může provádět vyplňování obrazu grafického primitiva konstantní barvou (flat shading), interpolace barev vrcholů (Gouraudovo stínování), texturování (vyplňování rastrovým vzorkem), maskování pixelů na základě nejvyššího bitu, tzv. m-bitu uloženého ve framebufferu a konečně pak poněkud zjednodušený, ale v praxi mnohdy zcela dostačující výpočet průhlednosti spočívající v kombinaci původní barvy pixelu (barva pozadí či barva již vykresleného objektu) s nově vykreslovaným pixelem (nový objekt je překreslovaný přes objekt starý).
V případě použití texturování, tj. při vykreslování spritů či otexturovaných obdélníků, se texely (pixely uložené v rastrové textuře) načítaly přímo z framebufferu. Nesmíme ovšem zapomenout ani na čip nazvaný MDEC, neboli plným názvem Motion Decoder. Tento čip umožňoval urychlit dekódování (resp. poněkud nepřesně řečeno dekompresi) rastrových obrázků uložených dle normy JPEG, čehož bylo možné využít například při zobrazování videa uloženého ve formátu MJPEG (Motion JPEG). Podrobnosti o tomto zajímavém čipu, který umožnil ještě ve větší míře využít všech kladných vlastností mechaniky CD-ROM, kterou byla konzole Sony PlayStation vybavena, si uvedeme v šesté kapitole.
3. Příkazy pro vykreslování a pro konfiguraci grafické pipeline
V předchozí části tohoto seriálu jsme se zmínili o několika typech grafických primitiv, jejichž vykreslování je podporováno přímo v hardwarové renderovací jednotce herní konzole Sony PlayStation. Jedná se jak o různé jednoduché geometrické objekty (bod, úsečka, obdélník, polygon), tak i o sprity, jejichž vykreslování bylo rychlejší, než v případě použití obecných otexturovaných obdélníků:
| # | Typ | Geometrie zadána | Popis grafického primitiva |
|---|---|---|---|
| 1 | bod | 1 vrchol | vykreslení jednoho pixelu zadanou barvou |
| 2 | úsečka | 2 vrcholy | vykreslení úsečky, možnost jednorozměrného Gouraudova stínování |
| 3 | polyčára | n vrcholů | vykreslení sekvence úseček, možnost jednorozměrného Gouraudova stínování |
| 4 | obdélník | 1 vrchol+rozměry | zobrazen rychleji než obecný čtyřúhelník |
| 5 | sprite | 1 vrchol+rozměry | obdélník s texturou, rychlejší než obecný otexturovaný čtyřúhelník |
| 6 | polygon | 3 nebo 4 vrcholy | čtyřúhelník je interně rozdělen na dva trojúhelníky |
| 7 | otexturovaný polygon | 3 nebo 4 vrcholy | opět dochází k rozdělení na dva trojúhelníky |
Podle konkrétního typu grafického primitiva rozpoznávala jednotka GPU následující vykreslovací příkazy:
| # | Kód | Délka paketu | Typ primitiva |
|---|---|---|---|
| 1 | 0×20 | 4 bajty | jednobarevný polygon zadaný třemi vrcholy |
| 2 | 0×24 | 7 bajtů | otexturovaný polygon zadaný třemi vrcholy |
| 3 | 0×28 | 5 bajtů | jednobarevný polygon zadaný čtyřmi vrcholy |
| 4 | 0×2c | 9 bajtů | otexturovaný polygon zadaný čtyřmi vrcholy |
| 5 | 0×30 | 6 bajtů | polygon se třemi vrcholy, každý vrchol může mít odlišnou barvu |
| 6 | 0×34 | 9 bajtů | otexturovaný polygon se třemi vrcholy, každý má odlišnou barvu |
| 7 | 0×38 | 8 bajtů | polygon se čtyřmi vrcholy, každý může mít odlišnou barvu |
| 8 | 0×3c | 12 bajtů | otexturovaný polygon se čtyřmi vrcholy, každý má odlišnou barvu |
| 9 | 0×40 | 3 bajty | jednobarevná úsečka |
| 10 | 0×48 | x bajtů | obecná polyčára (proměnný počet vrcholů) |
| 11 | 0×50 | 4 bajty | úsečka, každý její vrchol (počáteční, koncový) může mít odlišnou barvu |
| 12 | 0×58 | x bajtů | obecná polyčára (proměnný počet vrcholů) s odlišnou barvou vrcholů |
| 13 | 0×60 | 3 bajty | obdélník se specifikovanou barvou |
| 14 | 0×64 | 4 bajty | sprite |
| 15 | 0×68 | 2 bajty | bod se specifikovanou barvou |
| 16 | 0×70 | 2 bajty | obdélník o rozměrech 8×8 |
| 17 | 0×74 | 3 bajty | sprite o rozměrech 8×8 |
| 18 | 0×78 | 2 bajty | obdélník o rozměrech 16×16 |
| 19 | 0×7c | 3 bajty | sprite o rozměrech 16×16 |
4. Režimy vykreslování
Při pohledu na tabulku s příkazy pro vykreslování jednotlivých typů grafických primitiv je – zejména z údajů o délkách paketů – patrná snaha o to, aby všechny příkazy byly co nejkratší. Z tohoto důvodu zde například najdeme jak příkaz pro kresbu obecného spritu, tak i speciální příkazy pro sprity o velikost 8×8 pixelů a 16×16 pixelů. U některých typů grafických primitiv se zase odlišují příkazy použité ve chvíli, kdy mají všechny vrcholy stejnou barvu a v případě, kdy programátor potřebovat využít interpolaci barvy, neboli Gouraudovo stínování – Gouraud shading (zde je nutné barvu uložit pro každý vrchol zvlášť). Zajímavá je taktéž podpora pro obecné polyčáry, u nichž není dopředu zadán počet vrcholů. Paket může obsahovat libovolný počet vrcholů, přičemž se za posledním vrcholem zapisuje ukončující kód s hodnotou 0×55555555 (který by teoreticky znamenal vrchol na souřadnicích [0×5555, 0×5555]). Pro speciální efekty bylo možné použít i úsečku, v níž měl každý vrchol odlišnou barvu a při vykreslování se tedy musela použít interpolace barvy (jednorozměrná varianta Gouraudova stínování).
Zbývá nám ještě doplnit informaci o barvách grafických primitiv a/nebo jednotlivých vrcholů. Nezávisle na formátu framebufferu byla barva vždy reprezentována 24bitovou hodnotou. Kromě toho ještě každý vykreslovací příkaz obsahoval jednobitovou hodnotu, kterou se zapínala či vypínala poloprůhlednost. Pokud byla průhlednost povolena, mohla rasterizační jednotka použít jeden ze čtyř režimů výpočtu průhlednosti:
| Režim | Prováděný výpočet |
|---|---|
| 1 | 1.0 × dest + 0.5 × source |
| 2 | 1.0 × dest + 1.0 × source |
| 3 | 1.0 × dest – 1.0 × source |
| 4 | 1.0 × dest + 0.25 × source |
Označením dest je myšlena barva pixelu uložená ve framebufferu, označením source pak barva pixelu vypočtená v rasterizační jednotce.
5. Textury a texturovací jednotka
Textury použité při vykreslování spritů popř. otexturovaných polygonů musí být ještě před začátkem vykreslování uloženy do framebufferu. Podporovány jsou přitom tři formáty uložení. Při použití prvního formátu je každý texel reprezentován šestnácti bity (dvěma bajty), přičemž pro každou barvovou složku RGB bylo použito pět bitů a šestnáctý bit (s nejvyšší váhou) určoval průhlednost či poloprůhlednost texelu. Druhý formát umožňoval do dvou bajtů uložit barvy dvou za sebou jdoucích texelů; v tomto případě byla barva každého texelu určena osmibitovým indexem do barvové palety, v níž byla každá barva reprezentována patnácti bity. Třetí formát byl částečně podobný formátu druhému, ovšem do dvou bajtů se zde ukládaly indexy barvy čtyř texelů. Každý texel tedy mohl být nastaven na jednu z šestnácti barev; výsledkem byly šestnáctibarevné textury s poměrně malými paměťovými nároky (polovičními oproti formátu druhému a dokonce čtvrtinovými oproti formátu prvnímu).
Textury byly ve framebufferu uloženy do takzvaných stránek textur (texture pages) o rozměrech 256×256 texelů. To znamenalo, že souřadnice v prostoru textury (takzvané u-v souřadnice) byly osmibitové, což snižovalo paměťové nároky na uložení vykreslovacích příkazů. Navíc nemělo smysl podporovat textury o větších rozměrech, a to kvůli poměrně malé kapacitě framebufferu (mnoho her používalo například textury o rozměrech 64×64 texelů). Při vykreslování otexturovaných polygonů či spritů bylo nutné načítat texely z framebufferu a ukládat do něj rozrastrovaný grafický objekt. Tyto operace byly samozřejmě náročné kvůli nutnosti několikanásobného přístupu do paměti framebufferu a proto byl grafický subsystém vybaven vyrovnávací pamětí pro textury. V závislosti na použitém režimu mohla tato vyrovnávací paměť obsahovat jednu texturu o rozměrech 32×32 texelů, 32×64 texelů či 64×64 texelů.
6. Čip MDEC
Další důležitou součástí herní konzole Sony PlayStation je čip nazvaný MDEC, neboli plným názvem Motion Decoder. Tento čip byl navržen takovým způsobem, aby umožňoval urychlit dekódování (resp. poněkud nepřesně řečeno dekompresi) rastrových obrázků uložených dle normy JPEG, čehož bylo možné využít například při zobrazování videa uloženého ve formátu MJPEG (Motion JPEG). Dekódování jednotlivých snímků probíhalo po takzvaných makroblocích o velikosti 16×16 pixelů. Vstupní makroblok obsahoval barvy pixelů ve formátu YUV (YCbCr) (složky Cb a Cr měly poloviční frekvenci), které byly zpracovány diskrétní kosinovou transformací (DCT) a následně RLE komprimací (vyšší frekvence v obraze měly uměle sníženou váhu díky kvantizaci).
Obrázek 1: Převod mezi barvovým prostorem RGB a YCbCr (zde světlost pixelu odpovídá úrovním složek Y, Cb a Cr).
Výstupní makroblok vypočtený čipem MDEC obsahoval taktéž hodnoty barev v matici 16×16 pixelů, ovšem již v dekódované podobě a ve formátu RGB (24bpp popř. alternativně 16bpp), což přesně odpovídalo formátu framebufferu.
Obrázek 2: Díky cíleně aplikované kvantizaci je v běžných obrázcích mnoho koeficientů získaných po DCT nulových, což zvyšuje kompresní poměr po aplikaci RLE (Run-Length Encoding).
Díky tomu, že MDEC prováděl pouze operace nad makrobloky a nikoli další komplikovanější činnosti, byla jeho rychlost poměrně vysoká – dosahovala přibližně 9000 makrobloků za sekundu, což při rozlišení 320×240 pixelů umožňovalo zobrazovat video s třiceti snímky za sekundu (300 makrobloků na snímek). Přenos dat do MDEC probíhal přes první DMA kanál, výstup byl do framebufferu ukládán přes druhý DMA kanál.
7. Geometry Transformation Engine
Další součástí herní konzole Sony PlayStation, o níž jsme se již stručně zmínili, je modul nazvaný Geometry Transformation Engine, neboli zkráceně GTE. Tento modul dokázal provádět několik operací nad vektory a maticemi. Při práci s vektory se rozlišovaly obecné vektory se třemi složkami a normálové vektory, tj. vektory s délkou rovnou jedné. Mezi podporované základní operace patřil posun bodu o zadaný vektor (translate), rotace okolo jedné souřadné osy (rotate) a perspektivní transformace, která slouží k projekci vrcholu z trojrozměrného prostoru do dvourozměrné plochy představující plochu obrazovky. Pro provedení rotace, posunu a perspektivní transformace sloužily instrukce typu RTPS/RTPT, násobení vektoru konstantou (skalárem) se provádělo instrukcí typu GPL, pro násobení matice a vektoru instrukce typu MVMVA a GTE navíc obsahoval i další speciální instrukce, například pro interpolaci barvy, částečný výpočet barvy na základě Phongova osvětlovacího modelu atd.
Modul GTE obsahoval 32 pracovních registrů a 32 řídicích registrů, přičemž každý z těchto registrů měl šířku 32 bitů. Pracovní a řídicí registry sloužily pro uložení prvků vektorů a matic. V řídicích registrech byl použit formát s pevnou řádovou čárkou, kde většina hodnot byla reprezentována šestnácti bity: jeden bit sloužil pro uložení znaménka, tři bity pro uložení celé části čísla a zbylých dvanáct bitů pro uložení desetinné části čísla. Tento formát byl tedy vhodný především pro reprezentace malých čísel s absolutní hodnotou v rozsahu 0,0 až 7,99975585938 – jde o poměrně ideální formát pro reprezentaci matice rotace, normálových vektorů atd.
8. Zvukový subsystém herní konzole Sony PlayStation
Posledním modulem herní konzole Sony PlayStation, s nímž se dnes seznámíme, je modul nazvaný SPU, neboli celým jménem Sound Processing Unit. Jedná se o modul určený pro generování (stereo) hudby a zvuků a taktéž pro přehrávání hudby uložené na discích CD-ROM (resp. CD-ROM XA, což je technologie, o níž jsme se již zmínili v předchozí části tohoto seriálu). Modul SPU zpracovává zvuková data a dokáže generovat až 24hlasou hudbu či zvuky. Pro uložení zvukových dat slouží buffer o kapacitě 512 kb, v němž jsou zvuková data rozdělena po blocích o velikosti šestnácti bajtů. V těchto blocích jsou uloženy jak vlastní komprimované samply, tak i dvoubajtová hlavička obsahující informaci o formátu samplů atd. První 4kb v bufferu jsou určeny pro uložení zvukových dat načtených z CD-ROM (CD-ROM XA), která jsou navíc částečně digitálně předzpracovaná (nastavení hlasitosti atd.). Formát těchto zvukových dat odpovídá možnostem CD-Audio, tj. jedná se o šestnáctibitové samply se vzorkovací frekvencí 44,1 kHz.
Zajímavější je ta část modulu SPU sloužící pro generování hudby, tj. nikoli pro pouhé přehrávání samplovaných zvuků uložených na CD-ROM. Jak již bylo řečeno v předchozím odstavci, dokáže SPU vytvářet až 24hlasou hudbu tvořenou 24 generátory. Každý generátor buď přehrává předem připravené samply, šum, popř. může být využit ve funkci frekvenčního modulátoru pro další generátor – tímto způsobem lze tvořit hudbu s využitím frekvenční modulace, tj. podobným způsobem, s jakým jsme se seznámili při popisu herních konzolí čtvrté generace. Z tohoto důvodu obsahuje každý generátor programovatelnou obálku ADSR (Attack, Decay, Sustain, Release), která ovlivňuje hlasitost generovaného signálu. Obálka tvořená čipem SPU má poněkud širší možnosti, než klasické ADSR obálky, protože lze volit i postupný pokles úrovně sustain, která je ve starších generátorech buď konstantní nebo klesající bez možnosti ovlivnit úroveň tohoto poklesu.
Modul SPU se konfiguruje pomocí sady řídicích registrů, s jejichž využitím lze nastavit jak základní parametry (hlasitost pro pravý a nezávisle i pro levý kanál), tak i složitější zvukové efekty, mezi něž patří například parametry již zmíněné ADSR obálky, reverb (a to i pro hudbu čtenou z CD-ROM), parametry dolnopásmové propusti atd. Veškerá práce SPU je přitom zcela nezávislá na činnosti hlavního CPU, ovšem SPU lze nakonfigurovat takovým způsobem, aby se generovalo hardwarové přerušení při přehrání samplů z nějakého zvukového kanálu, takže CPU může například provést rekonfiguraci SPU, vytvořit nové samply apod.
9. Odkazy na Internetu
- MIPS Architecture Overview
http://tams-www.informatik.uni-hamburg.de/applets/hades/webdemos/mips.html - MIPS Technologies R3000
http://www.cpu-world.com/CPUs/R3000/ - Sony PlayStation (Wikipedia)
http://en.wikipedia.org/wiki/PlayStation_(console) - The Official PlayStation muzeum
http://playstationmuseum.com/playstation-systems/ - CPU-collection: IDT R3010 FPU
http://www.cpu-collection.de/?tn=0&l0=co&l1=IDT&l2=R3010+FPU - The MIPS R2000 Instruction Set
http://suraj.lums.edu.pk/~cs423a05/Reference/MIPSCodeTable.pdf - Maska mikroprocesoru RISC 1
http://www.cs.berkeley.edu/~pattrsn/Arch/RISC1.jpg - Maska mikroprocesoru RISC 2
http://www.cs.berkeley.edu/~pattrsn/Arch/RISC2.jpg - The MIPS Register Usage Conventions
http://pages.cs.wisc.edu/~cs354–2/beyond354/conventions.html - C.E. Sequin and D.A.Patterson: Design and Implementation of RISC I
http://www.eecs.berkeley.edu/Pubs/TechRpts/1982/CSD-82–106.pdf - Berkeley RISC
http://en.wikipedia.org/wiki/Berkeley_RISC - Great moments in microprocessor history
http://www.ibm.com/developerworks/library/pa-microhist.html - Great Microprocessors of the Past and Present
http://www.cpushack.com/CPU/cpu1.html - Sega documentation
http://koti.kapsi.fi/~antime/sega/docs.html - 1995 Programming on the Sega Saturn
http://cowboyprogramming.com/2010/06/03/1995-programming-on-the-sega-saturn/ - Sega Myths-Saturn was the most difficult console to program for of 5th Gen
http://forums.sega.com/showthread.php?313485-Sega-Myths-Saturn-was-the-most-difficult-console-to-program-for-of-5th-Gen - SuperH RISC engine Family
http://www.renesas.com/products/mpumcu/superh/index.jsp - Sega Saturn
http://en.wikipedia.org/wiki/Sega_saturn - Jaguar Sector – II
http://www.jaguarsector.com/index.php - Atari Age: Atari Jaguar History
http://www.atariage.com/Jaguar/history.html - Jaguar
http://www.giantbomb.com/jaguar/3045–28/ - Consoles that won't die: The Atari Jaguar
http://venturebeat.com/2013/04/25/consoles-that-wont-die-atari-jaguar/ - Atari Jaguar and Atari Jaguar CD
http://videogamecritic.com/jaguarinfo.htm - Atari Jaguar Documentation (Forum)
http://www.jaguarsector.com/index.php?showforum=65 - Atari Jaguar Programming (Forum)
http://www.jaguarsector.com/index.php?showforum=63 - The Jaguar Underground Documentation
http://justclaws.atari.org/devcats/dox/dox.htm - Blitter (Wikipedia CZ)
http://cs.wikipedia.org/wiki/Blitter - Blitter (Wikipedia EN)
http://en.wikipedia.org/wiki/Blitter - Bit blit
http://en.wikipedia.org/wiki/Bit_blit - Disassembler for the portable Jaguar DSP emulator (zdrojový kód s instrukcemi)
http://mamedev.org/source/src/emu/cpu/jaguar/jagdasm.c.html - Fourth-Generation Consoles
http://gaming.wikia.com/wiki/Fourth-Generation_Consoles - Fifth-Generation Consoles
http://gaming.wikia.com/wiki/Fifth-Generation_Consoles - History of video game consoles (fifth generation)
http://en.wikipedia.org/wiki/History_of_video_game_consoles_(fifth_generation) - Atari Jaguar
http://gaming.wikia.com/wiki/Atari_Jaguar - Atari Jaguar Games
http://gaming.wikia.com/wiki/List_of_Atari_Jaguar_games - MyMedia Games Network Retrospective – Nintendo Super FX chip
http://psp.mmgn.com/News/MyMedia-Games-Network-Retrospe-G6W - Wikipedia: Super FX
http://en.wikipedia.org/wiki/Super_FX - IGN: Top 25 Consoles
http://www.ign.com/top-25-consoles/13.html - Sega Mega Drive
http://sega.jp/archive/segahard/md/ - The16bit Era Of Console Video Games
http://tvtropes.org/pmwiki/pmwiki.php/Main/The16bitEraOfConsoleVideoGames - The Console Wars
http://www.cracked.com/funny-2590-the-console-wars/ - Console Wars
http://tvtropes.org/pmwiki/pmwiki.php/Main/ConsoleWars - Era of the „Bit Wars“
http://www.gtplanet.net/forum/threads/era-of-the-bit-wars.119796/ - Rez Wars: How the Bit Wars never really ended
http://www.ign.com/blogs/beastmastertoad/2013/01/31/rez-wars-how-the-bit-wars-never-really-ended - Which system ended the „Bit Wars“?
http://atariage.com/forums/topic/199163-which-system-ended-the-bit-wars/
