Hernı 3D engine pro Windows Phone 7

Univerzita Karlova v Praze Matematicko-fyzikáln´ı fakulta

´ RSK ˇ ´ PRACE ´ BAKALA A

Tomáˇs Slav´ıˇcek Hern´ı 3D engine pro Windows Phone 7 Katedra teoretické informatiky a matematické logiky

Vedouc´ı bakaláˇrské práce: Mgr. Ondˇrej S´ ykora Studijn´ı program: Informatika Studijn´ı obor: programován´ı

Praha 2011

Chtˇel bych podˇekovat Ondrovi S´ ykorovi za jeho ochotu, odbornou pomoc a cenné rady pˇri konzultac´ıch v pr˚ ubˇehu tvorby celé této práce a ˇceskému zastoupen´ı spoleˇcnosti Microsoft, s.r.o. za poskytnut´ı telefonu k testován´ı této knihovny.

Prohlaˇsuji, ˇze jsem tuto bakaláˇrskou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u, literatury a dalˇs´ıch odborn´ ych zdroj˚ u. Beru na vˇedom´ı, ˇze se na moji práci vztahuj´ı práva a povinnosti vypl´ yvaj´ıc´ı ze zákona ˇc. 121/2000 Sb., autorského zákona v platném znˇen´ı, zejména skuteˇcnost, ˇze Univerzita Karlova v Praze má právo na uzavˇren´ı licenˇcn´ı smlouvy o uˇzit´ı této práce jako ˇskoln´ıho d´ıla podle §60 odst. 1 autorského zákona.

V ........ dne ............

Podpis autora

Název práce: Hern´ı 3D engine pro Windows Phone 7 Autor: Tomáˇs Slav´ıˇcek Katedra: Katedra teoretické informatiky a matematické logiky Vedouc´ı bakaláˇrské práce: Mgr. Ondˇrej S´ ykora Abstrakt: Práce se zab´ yvá implementac´ı knihovny pro jednoduˇsˇs´ı v´ yvoj her na platformˇe Windows Phone 7. Je v n´ı analyzováno prostˇred´ı mobiln´ıch telefon˚ u a probráno, jaké vlastnosti by mˇel hern´ı 3D engine obsahovat. Je navrˇzena hierarchie projektu, popsány a naimplementovány jednotlivé komponenty. Dodána je podpora pro efektivnˇejˇs´ı správu objekt˚ u ve scénˇe. Rozˇs´ıˇreny jsou grafické moˇznosti, pˇredevˇs´ım o zobrazován´ı polopr˚ uhlednosti a st´ın˚ u. Algoritmy jsou vybrány s ohledem na omezen´ y v´ ykon mobiln´ıch zaˇr´ızen´ı. Pˇriloˇzen je vzorov´ y projekt a popsáno jeho pouˇzit´ı. Kl´ıˇcová slova: 3D engine, mobiln´ı telefony, grafika, hry

Title: Game 3D engine for Windows Phone 7 Author: Tomáˇs Slav´ıˇcek Department: Department of Theoretical Computer Science and Mathematical Logic Supervisor: Mgr. Ondˇrej S´ ykora Abstract: In this work, we implement a library for easier development of games for the Windows Phone 7 platform. We analyze the environment of mobile phone development and discuss what features should the 3D game engine include. We propose the hierarchy of the project, its components are described and implemented. The engine supports efficient management of objects in the scene. It provides functionality to improve the visual appeal of the games, especially displaying of transparency and shadows. The algorithms are chosen and implemented with respect to the limited performance of the mobile devices. The capabilities of the engine are demonstrated on a sample game project. Keywords: 3D engine, mobile phones, CGI, games

Obsah ´ Uvod

2

1 Anal´ yza probl´ emu 1.1 Seznámen´ı s platformou . . . . . 1.2 Specifika mobiln´ıho v´ yvoje . . . . 1.3 Anal´ yza her . . . . . . . . . . . . 1.4 Poˇzadované vlastnosti 3D engine 1.5 Dalˇs´ı souˇcásti her . . . . . . . . .

. . . . .

4 4 5 6 7 9

. . . . . .

10 10 11 13 14 16 20

. . . . . . . . .

25 25 27 28 31 32 34 37 39 40

4 Vyuˇ zit´ı v praxi 4.1 Ukázkov´ y projekt, mˇeˇren´ı . . . . . . . . . . . . . . . . . . . . . . 4.2 Zhodnocen´ı práce, rozˇsiˇritelnost . . . . . . . . . . . . . . . . . . . 4.3 Porovnán´ı s dalˇs´ımi knihovnami . . . . . . . . . . . . . . . . . . .

43 43 46 47

Z´ avˇ er

48

Seznam pouˇ zit´ e literatury

49

A Obsah pˇ riloˇ zen´ eho CD

52

B Uˇ zivatelsk´ a dokumentace

53

C Program´ atorsk´ a dokumentace

55

2 N´ avrh hern´ıho 3D engine 2.1 Správa hern´ıch obrazovek . . . . 2.2 Zpracován´ı uˇzivatelského vstupu 2.3 Správa objekt˚ u . . . . . . . . . 2.4 Správci scény . . . . . . . . . . 2.5 Polopr˚ uhlednost . . . . . . . . . 2.6 Vylepˇsen´ı grafického vzhledu . . 3 Implementace 3.1 Hierarchie projektu . . . . . . . 3.2 Globáln´ı vlastnosti engine . . . 3.3 Správa obrazovek, komponenty 3.4 Správci scény . . . . . . . . . . 3.5 Implementace objekt˚ u . . . . . 3.6 Generovaná primitiva . . . . . . 3.7 Serializace objekt˚ u ze souboru . 3.8 Kolize objekt˚ u. . . . . . . . . . 3.9 Kamery . . . . . . . . . . . . .

1

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

. . . . .

. . . . . .

. . . . . . . . .

´ Uvod Mobiln´ı telefony se staly ned´ılnou souˇca´st´ı naˇseho ˇzivota. Lidé je vyuˇz´ıvaj´ı nejen ke komunikaci, ale také k hledán´ı informac´ı na internetu nebo k pˇrehráván´ı hudby. T´ım, jak se postupnˇe navyˇsoval v´ ykon tˇechto zaˇr´ızen´ı, se v´ yznamnou ˇcást´ı mobiln´ıho businessu staly také mobiln´ı hry. Historie Jednou z prvn´ıch mobiln´ıch her byl Snake, uveden´ y v roce 1997 pro telefon Nokia 6110 [24]. V této dobˇe byly hry jeˇstˇe velice jednoduché, k zobrazen´ı slouˇzil mal´ y ˇcernob´ıl´ y displej, k ovládán´ı ˇc´ıselná klávesnice. Tyto hry byly vytváˇreny na zakázku pˇr´ımo pro konkrétn´ı modely telefon˚ u, ze sv´ ych zaˇr´ızen´ı si je uˇzivatelé nemohli odstranit ani nahradit jin´ ymi. Postupem ˇcasu se u mobiln´ıch telefon˚ u prosadila platforma J2ME (Java 2 Micro Edition) [26]. Tento standard umoˇznil v´ yvojáˇr˚ um vytvoˇrit jednu hru a nab´ıdnout ji pro v´ıce telefon˚ u r˚ uzn´ ych znaˇcek. Mobiln´ı hry se staly ˇza´dan´ ym zboˇz´ım, vznikala prvn´ı v´ yvojáˇrská studia. D´ıky nar˚ ustaj´ıc´ımu v´ ykonu telefon˚ u, prvn´ım barevn´ ym displej˚ um a jejich vyˇsˇs´ımu rozliˇsen´ı, zaˇcaly hry také vypadat mnohem lépe. Jejich distribuce v té dobˇe prob´ıhala pˇredevˇs´ım pˇres mobiln´ı operátory. Z dalˇs´ı miln´ık ve v´ yvoji lze povaˇzovat uveden´ı telefonu Apple iPhone v roce 2007 [2]. Nab´ıdl jednoduché ovládán´ı pomoc´ı dotykového displeje a pohybového senzoru. V roce 2008 byl uveden digitáln´ı obchod App Store, ˇc´ımˇz byl nast´ınˇen i nov´ y smˇer v distribuci her. Aplikace se daly stáhnout pouze z jednoho centralizovaného obchodu, ten provozoval pˇr´ımo v´ yrobce telefon˚ u. Uˇzivatelé si ale mohli vyb´ırat nové programy pˇr´ımo z telefonu, tedy mnohem jednoduˇsˇseji, neˇz dˇr´ıve. Stejnˇe tak se i v´ yvojáˇr˚ um ulehˇcila práce, kdyˇz chtˇeli své aplikace zaˇc´ıt nab´ızet. Na tento zp˚ usob distribuce v dneˇsn´ı dobˇe pˇreˇsly vˇsechny hlavn´ı platformy tzv. chytr´ ych telefon˚ u, sv˚ uj obchod s aplikacemi maj´ı operaˇcn´ı systémy Android, Symbian, Bada, nebo také Windows Phone. Windows Phone Windows Phone 7 [18] je nová mobiln´ı platforma spoleˇcnosti Microsoft, uvedená vu ńoru 2010. Obsahuje inovované grafické uˇzivatelské rozhran´ı. Hry zde hraj´ı velkou roli, v systému maj´ı vyhrazenou celou svoji sekci, nˇekteré mohou komunikovat i s hern´ı konzol´ı Xbox 360. Pro jejich tvorbu je v´ yvojáˇr˚ um k dispozici technologie XNA Framework [19]. Pro vytváˇren´ı jednoduch´ ych dvourozmˇern´ ych her je dobˇre pˇripravena, lze si pomoc´ı n´ı jednoduˇse naˇc´ıtat obrázky nebo napˇr´ıklad zvukové 2

soubory do projektu, vyuˇz´ıvat pˇripravenou hern´ı smyˇcku, nebo dalˇs´ı pomocné funkce. Nen´ı to ale kompletn´ı hern´ı engine, nen´ı zde plná podpora pro správu obrazovek a objekt˚ u na scénˇe, vykreslován´ı st´ın˚ u apod. Mnoho funkc´ı je potˇreba doplnit. C´ıle pr´ ace C´ılem této práce je navrhnout a naimplementovat knihovnu pro jednoduˇsˇs´ı a pohodlnˇejˇs´ı v´ yvoj her na této platformˇe. Rozhodnout, jaké funkce budou nejˇcastˇeji potˇreba pˇri tvorbˇe her a doplnit jejich konkrétn´ı implementaci. Postarat se o uˇzivatelsk´ y vstup a navrhnout podporu pro správu hern´ıch obrazovek. Urˇcit, jak budou jednotlivé souˇca´sti hry dˇelené do komponent a popsat, jak spolu budou moci komunikovat. Doplnit implementaci nejˇcastˇejˇs´ıch souˇcást´ı hry, tj. pˇripravit komponenty pro vykreslován´ı ovládac´ıch prvk˚ u, hlavn´ıho menu apod. Dalˇs´ım c´ılem bude rozˇs´ıˇrit grafické moˇznost´ı XNA, pˇredevˇs´ım pro vykreslován´ı 3D scén. Vybrat a naimplementovat algoritmy pro vykreslován´ı st´ın˚ u a pouˇz´ıván´ı polopr˚ uhlednosti. Dodat podporu pro efektivnˇejˇs´ı správu objekt˚ u, aby se pokud moˇzno vˇzdy vykreslovaly jen ty v zorném poli kamery. Doplnit podporu pro ˇreˇsen´ı jednoduch´ ych koliz´ı a pro naˇc´ıtán´ı popisu hern´ı scény ze souboru. Pouˇzit´ı jednotliv´ ych technik a algoritm˚ u bude diskutováno a vˇzdy vybráno s ohledem na omezené vlastnosti tˇechto mobiln´ıch zaˇr´ızen´ı. Struktura pr´ ace Práce je rozdˇelena do ˇctyˇr ˇca´st´ı. V prvn´ı kapitole je analyzován problém, popsáno prostˇred´ı mobiln´ıch telefon˚ u a ˇctenáˇr je seznámen s platformou Windows Phone. Je zde probráno, jaké vlastnosti by mˇel 3D engine obsahovat. Druhá kapitola se zab´ yvá popisem, jak konkrétnˇe by se mohl hern´ı 3D engine navrhnout a jaké souˇcásti by mˇel obsahovat. Popsána je struktura projektu a je rozvedeno, jaké by se mohly pouˇz´ıt grafické techniky pro vylepˇsen´ı vzhledu scény. Kapitola 3 se zab´ yvá konkrétn´ı implementac´ı knihovny, je zde popsána jej´ı architektura a uvedena struktura tˇr´ıd. Je zde rozvedeno, jak spolu jednotlivé ˇca´sti komunikuj´ı. V kapitole 4 je popsán ukázkov´ y projekt. Na závˇer jsou zhodnoceny moˇznosti této knihovny a je porovnána s konkurenc´ı. Jako pˇr´ıloha je pˇriloˇzena uˇzivatelská a programátorská dokumentace. Nacház´ı se zde popis, jak projekt zprovoznit. Také je zde popsáno, jak by se mˇelo postupovat pˇri implementaci nové hry nad touto knihovnou.

3

1. Anal´ yza probl´ emu 1.1

Sezn´ amen´ı s platformou

Windows Phone 7 je v souˇcasné dobˇe (konec roku 2011) hlavn´ı mobiln´ı platforma Microsoftu. Byla uvedena v u ńoru 2010 na konferenci MWC v Barcelonˇe, prvn´ı zaˇr´ızen´ı se zaˇcala prodávat p˚ ul roku poté. V pr˚ ubˇehu ˇcasu byly telefony s t´ımto systémem nˇekolikrát aktualizovány, postupnˇe jim byly pˇridávány funkce, jako napˇr´ıklad podpora pro kop´ırován´ı a vkládán´ı textu. Posledn´ı velká aktualizace, nazvaná Mango, se zaˇcala distribuovat 27. záˇr´ı 2011. Do telefon˚ u byla pˇridána moˇznost rychlého pˇrep´ınán´ı aplikac´ı, bylo zpˇr´ıstupnˇeno nˇekolik nov´ ych rozhran´ı pro programátory. ˇ Spolu s touto aktualizac´ı také pˇribyla plná podpora pro Ceskou republiku, vˇcetnˇe lokalizace systému, moˇznosti nákupu aplikac´ı pro ˇceské uˇzivatele i jejich prodeje pro ˇceské v´ yvojáˇre. V´ yvoj pro Windows Phone Pˇredch˚ udcem Windows Phone 7 byla platforma Pocket PC uvedená v roce 2000, v roce 2003 pˇrejmenovaná na Windows Mobile. Windows Phone 7 se od této platformy liˇs´ı, obsahuje nové grafické rozhran´ı, nazvané Metro, které sáz´ı na jednoduchost a typografii. Odliˇsn´ y je i zp˚ usob v´ yvoje aplikac´ı pro tyto telefony. Zmizela moˇznost nativn´ıho v´ yvoje v jazyce C++, stejnˇe tak i pro jazyky .NET (C# a VB.NET) se styl programován´ı zmˇenil. Nen´ı zde k dispozici kompletn´ı .NET Compact Framework, je nutné si vystaˇcit s dvˇema technologiemi – se Silverlightem a s XNA. Silverlight [17] vycház´ı z desktopové technologie WPF, na Windows Phone je urˇcen´ y pˇredevˇs´ım pro vytváˇren´ı bˇeˇzn´ ych aplikac´ı. Hod´ı se pro psan´ı r˚ uzn´ ych utilit, má pˇr´ıstup k r˚ uzn´ ym telefonn´ım senzor˚ um, napˇr´ıklad k fotoaparátu nebo akcelerometru. Oproti tomu XNA [19] je framework urˇcen´ y pˇredevˇs´ım pro tvorbu her. Je postaven´ y nad technologi´ı DirectX, snaˇz´ı se odst´ınit v´ yvojáˇre od specifick´ ych vlastnost´ı jednotliv´ ych platforem. Dá se pomoc´ı nˇej vyv´ıjet i pro osobn´ı poˇc´ıtaˇce, hern´ı konzole Xbox 360 a hudebn´ı pˇrehrávaˇce Zune.

4

1.2

Specifika mobiln´ıho v´ yvoje

Ovl´ ad´ an´ı telefon˚ u Modern´ı mobiln´ı telefony, kter´ ymi se zab´ yvá tato práce, se v mnohém odliˇsuj´ı od ostatn´ıch typ˚ u zaˇr´ızen´ı. Oproti telefon˚ um klasické konstrukce jim vˇetˇsinou chyb´ı hardwarová ˇc´ıselná klávesnice, prostor zde naopak dostává velk´ y displej. Poˇcet ovládac´ıch prvk˚ u je omezen na minimum, na telefonu se nacház´ı jen ty nejnutnˇejˇs´ı klávesy, jako napˇr´ıklad pro návrat na pˇredchoz´ı obrazovku, nebo zpˇet do hlavn´ı nab´ıdky. Ostatn´ı ovládac´ı prvky se zobrazuj´ı pˇr´ımo na displeji podle aktuáln´ıho kontextu. Displej je dotykov´ y, vˇetˇsinou s podporou stisknut´ı v´ıce dotyk˚ u zároveˇ n. Pro ovládán´ı telefonu se ˇcasto vyuˇz´ıvaj´ı gesta, jako rychlé táhnut´ı prstu urˇcit´ ym smˇerem, nebo roztaˇzen´ı dvou prst˚ u od sebe. Pˇri návrhu her na tyto vlastnosti mus´ı b´ yt brán ohled. Na rozd´ıl od kapesn´ıch hern´ıch konzol´ı tyto telefony nemaj´ı k dispozici ˇzádné hardwarové ovládac´ı ˇsipky, joysticky a podobnˇe. Primárn´ı vstup tedy mus´ı pocházet z dotykového displeje [28], viz obrázek 1.1.

Obrázek 1.1: Windows Phone 7 telefon a jeho souˇca´sti: dotykov´ y displej, klávesy zpˇet, dom˚ u a hledat.

Senzory Druh´ ym zp˚ usobem ovládán´ı her je pouˇzit´ı vestavˇeného akcelerometru. Ten udává aktuáln´ı náklon telefonu v prostoru. Bˇeˇzné aplikace na nˇej mohou reagovat zmˇenou své orientace na v´ yˇsku, nebo na ˇs´ıˇrku. Ve hrách se ˇcasto pouˇz´ıvá k ovládán´ı pohybu, naklápˇen´ım zaˇr´ızen´ı lze napˇr´ıklad ovládat zatáˇcen´ı auta v závodn´ı hˇre. Nˇekteré hry mohou také vyuˇz´ıvat vstupu z dalˇs´ıch senzor˚ u, jako napˇr´ıklad z fotoaparátu, digitáln´ıho kompasu, z gyroskopu nebo z mikrofonu.

5

V´ ykon telefon˚ u Pro telefony se systémem Windows Phone byly stanoveny pevné minimáln´ı hardwarové poˇzadavky. Kaˇzdé zaˇr´ızen´ı obsahuje displej s rozliˇsen´ım 800x480 pixel˚ u, s podporou stisku nejménˇe ˇctyˇr dotyk˚ u najednou. K dispozici je v´ ykonn´ y procesor a dedikovaná grafická karta s podporou DirectX 9 [28]. Celkov´ y v´ ykon nen´ı takov´ y, jako na poˇc´ıtaˇci, nebo na specializovan´ ych hern´ıch konzol´ıch, pˇresto se pro tyto telefony daj´ı vytváˇret i pomˇernˇe dobˇre vypadaj´ıc´ı trojrozmˇerné hry.

1.3

Anal´ yza her

Kaˇzdá komplexnˇejˇs´ı hra se skládá z nˇekolika oddˇelen´ ych ˇcást´ı. Obsahuje u ´vodn´ı obrazovku s hlavn´ım menu, obrazovku s nastaven´ım, nebo s v´ ypisem rekord˚ u. Mezi tˇemito obrazovkami se dá pˇrecházet, napˇr´ıklad vybrán´ım poloˇzky v hlavn´ım menu. V hern´ım oknˇe se nacház´ı hern´ı plán. To je sestava obrázk˚ u, naˇcten´ ych model˚ u nebo dalˇs´ıch objekt˚ u rozm´ıstˇen´ ych na specifick´ ych pozic´ıch. Dohromady pˇredstavuj´ı prostˇred´ı, ve kterém se odehrává hra. M˚ uˇze to b´ yt napˇr´ıklad sestavené bludiˇstˇe pro hern´ı postaviˇcku. C´ılem hry potom m˚ uˇze b´ yt prokliˇckován´ı s hlavn´ım hrdinou mezi objekty tohoto hern´ıho plánu a docestován´ı aˇz do c´ıle. Pˇres tento hern´ı plán b´ yvaj´ı pˇrekreslené ovládac´ı prvky, ukazatele skóre apod. Hra vˇetˇsinou umoˇzn ˇuje naˇcten´ı v´ıce r˚ uzn´ ych level˚ u, neboli pˇredem urˇcen´ ych rozm´ıstˇen´ı objekt˚ u na hern´ım plánu. Danou hru je moˇzné pozastavit. M˚ uˇze se uloˇzit nejvyˇsˇs´ı dosaˇzené skóre v této hˇre, nebo ho odeslat online. Tato struktura se opakuje prakticky u vˇsech her. U kaˇzdé hry je také potˇreba zpracovávat dotyky na displeji, gesta, pˇr´ıpadnˇe informace z pohybového senzoru (akcelerometru). Hern´ı ˇ z´ anry Hry mohou b´ yt rozdˇeleny do nˇekolika skupin. Obvyklé dˇelen´ı b´ yvá podle jejich ˇzańr˚ u, mezi hlavn´ı zástupce patˇr´ı arkády (rychlé hry s jednoduch´ ymi pravidly), simulátory (napˇr´ıklad závodn´ı a sportovn´ı hry), RPG (hry na hrdiny), nebo napˇr´ıklad akˇcn´ı hry (stˇr´ıleˇcky apod.). Hry mohou ˇcasto kombinovat i v´ıce ˇzánr˚ u dohromady. Kaˇzdému ˇzánru odpov´ıdá urˇcit´ y zp˚ usob ovládán´ı, rychlé akˇcn´ı hry vyˇzaduj´ı dobˇre navrˇzené ovládac´ı prvky s rychlou odezvou. Naopak napˇr´ıklad point & click adventury jsou na ovládán´ı nenároˇcné. U nich staˇc´ı, kdyˇz hra um´ı jednoduˇse zareagovat na kliknut´ı na displeji.

6

Zp˚ usoby zobrazen´ı sc´ eny Sp´ıˇs neˇz dan´ y ˇzańr hry, bude pro návrh knihovny d˚ uleˇzitˇejˇs´ı zp˚ usob, jak´ ym se hra bude vykreslovat na scénu. Hra m˚ uˇze b´ yt renderována dvourozmˇernˇe, bud’ pomoc´ı pˇrekr´ yván´ı obrázk˚ u pˇres sebe, nebo pomoc´ı vektorové grafiky. Tato práce se t´ yká pˇredevˇs´ım 3D her, tedy her, ve kter´ ych je vykreslován tˇr´ırozmˇerný pohled na scénu. Hern´ı plán je pˇredstavován virtuáln´ım svˇetem, na kter´ y se hráˇc ˇ d´ıvá pomyslnou kamerou. Casto si s t´ımto pohledem m˚ uˇze posouvat nebo otáˇcet, pˇr´ıpadnˇe si toto zobrazen´ı m˚ uˇze pˇribliˇzovat a oddalovat. Mezi nejˇcastˇejˇs´ı zp˚ usoby zobrazen´ı 3D her patˇr´ı pohled prvn´ı osoby (takzvan´ y FPS pohled, hráˇc si prohl´ıˇz´ı objekty ve scénˇe z pohledu hern´ı postaviˇcky), pˇr´ıpadnˇe pohled tˇret´ı osoby (kamera m´ıˇr´ı shora na hráˇce a pohybuje se s n´ım), viz obrázek 1.2. Ve hrách typu strategie se pouˇz´ıvá kamera, která m´ıˇr´ı shora na urˇcitou ˇcást hern´ıho svˇeta. Nˇekteré hry vyuˇz´ıvaj´ı pohled zboku na hráˇce. Ve scénˇe také m˚ uˇze b´ yt rozm´ıstˇeno nˇekolik pevných kamer, kdy se jen pˇrep´ıná pohled podle aktuáln´ı pozice postaviˇcky.

Obrázek 1.2: Hra Harvest pro Windows Phone 7 (akˇcn´ı RPG s pohledem ˇsikmo shora, Luma Arcade) [16], vytvoˇrena pomoc´ı technologie XNA

1.4

Poˇ zadovan´ e vlastnosti 3D engine

XNA Framework má jen ˇcásteˇcnou podporu pro vytváˇren´ı sloˇzitˇejˇs´ıch her. Je zde k dispozici pˇripravená hern´ı smyˇcka (sada metod naˇcti, zaktualizuj, vykresli. . . , do kter´ ych lze dosazovat kód). Je zde základn´ı podpora pro vytváˇren´ı hern´ıch 7

komponent. Data do projektu lze naˇc´ıtat pomoc´ı mechanismu Content Pipeline, stejnˇe jako na PC a hern´ı konzoli Xbox 360. Jsou zde pˇripravené i základn´ı matematické funkce uˇziteˇcné pro 3D grafiku ´ e zde ale chyb´ı nˇejaká vyˇsˇs´ı abs(pro r˚ uzné v´ ypoˇcty s vektory a maticemi). Uplnˇ trakce, pro celkovˇe pohodlnˇejˇs´ı a jednoduˇsˇs´ı v´ yvoj. Spr´ ava objekt˚ u S objekty na hern´ım plánu by mˇelo b´ yt jednoduché manipulovat. Kaˇzd´ y by si mˇel pamatovat transformaˇcn´ı matici (um´ıstˇen´ı a pootoˇcen´ı v prostoru). Mˇelo by jim b´ yt moˇzné nastavit parametry jako osvˇetlen´ı, polopr˚ uhlednost nebo st´ıny. Pro moˇznost oˇsetˇrován´ı koliz´ı by si objekty mˇely pamatovat i opsané orientované bounding boxy, pˇr´ıpadnˇe bounding sphere. Tyto objekty by mˇely b´ yt udrˇzovány ve spoleˇcné kolekci, aby se daly jednoduˇse naˇc´ıst ze souboru, pˇr´ıpadnˇe aby se jim vˇsem najednou daly nastavit vybrané parametry. Tato kolekce by také mˇela umoˇzn ˇovat rozdˇelen´ı objekt˚ u do skupin, nebo jejich urˇcité seˇrazen´ı. Z uspoˇrádán´ı v této kolekci by potom ˇcerpaly algoritmy pro ovˇeˇrován´ı viditelnosti na displeji, nebo pro v´ ypoˇcty koliz´ı. Ve hrách se obvykle pouˇz´ıvá nˇekolik typ˚ u objekt˚ u. Modely naˇctené do hry b´ yvaj´ı vytvoˇrené v nˇekterém ze specializovan´ ych 3D editor˚ u. Okolo hern´ı scény m˚ uˇze b´ yt um´ıstˇen skybox simuluj´ıc´ı oblohu. Nˇekteré objekty, jako napˇr´ıklad základn´ı obdéln´ıky nebo kvádry mohou b´ yt generované pˇr´ımo hrou. Stejnˇe tak i terén m˚ uˇze b´ yt vytváˇren aˇz za bˇehu podle nˇejakého popisu v souboru. Nˇekteré objekty budou moci b´ yt deformovatelné, nebo se budou moci animovat. Pro u ´ˇcely ladˇen´ı by mˇela hra umˇet zobrazit i drátˇené objekty pomocné geometrie, napˇr´ıklad pro vizualizaci bounding box˚ u pˇri testován´ı koliz´ı. Kamery Dané ˇzańry her, jako napˇr´ıklad strategie, ˇcasto obsahuj´ı velice podobné moˇznosti ovládán´ı pohledu. S hern´ım plánem jde posouvat, otáˇcet, pˇr´ıpadnˇe si ho pˇribliˇzovat. U FPS stˇr´ıleˇcek zase pˇredpokládáme napˇr´ıklad omezen´ı pohybu v urˇcit´ ych osách (hráˇc se nem˚ uˇze naklopit nabok). Pro jednoduˇsˇs´ı manipulaci s pohledem na scénu se mohou pˇripravit objekty kamer. Nˇekteré mohou vyuˇz´ıvat perspektivn´ı pohled, nˇekteré ortografick´ y, mohou se liˇsit i dalˇs´ı jejich parametry. Grafick´ e techniky ˇ Casto je snaha co nejv´ıce vylepˇsit grafick´ y vzhled hry. Uˇziteˇcná bude podpora alespoˇ n pro vykreslován´ı základn´ıch st´ın˚ u. Ty dokáˇz´ı dodat scénˇe na hloubce, umoˇzn´ı uˇzivateli se lépe orientovat na hern´ım plánu, odhadovat vzájemné pozice 8

objekt˚ u. Dobˇre vypadaj´ıc´ı st´ıny vykreslované v reálném ˇcase b´ yvaj´ı pomˇernˇe nároˇcné na v´ ykon, u mobiln´ıch her se proto vˇetˇsinou nepouˇz´ıvaj´ı. Existuj´ı ale jednoduˇsˇs´ı metody, které t vypadaj´ı pomˇernˇe dobˇre. Podobnˇe se do hry m˚ uˇze doplnit podpora polopr˚ uhlednosti. Polopr˚ uhledné objekty je potˇreba ˇradit odzadu dopˇredu v˚ uˇci kameˇre, aby se správnˇe vykreslily. Z d˚ uvod˚ u omezeného v´ ykonu mobiln´ıch zaˇr´ızen´ı se ve hrách polopr˚ uhlednost obvykle vyuˇz´ıvá jen velice zˇr´ıdka, pˇresto m˚ uˇze pomˇernˇe pˇrispˇet k dobrému vzhledu. Dalˇs´ı grafické techniky, obˇcas také pouˇz´ıvané v mobiln´ıch hrách, jsou napˇr´ıklad particle efekty (simulace kouˇre, ohnˇe apod.), pˇr´ıpadnˇe r˚ uzné pˇrekryvné 2D objekty (záˇre, v´ ybuchy apod.). Tyto objekty ˇcasto také mohou b´ yt animované.

1.5

Dalˇ s´ı souˇ c´ asti her

Ned´ılnou souˇcást´ı vˇetˇsiny her b´ yvá pˇrehráván´ı zvuk˚ u a hudby na pozad´ı. Tyto efekty mohou v´ yznamnˇe pozvednout celkov´ y záˇzitek ze hry. Hru je také obvykle potˇreba lokalizovat do nˇekolika jazyk˚ u. Online sluˇ zby V dneˇsn´ı dobˇe se pˇredpokládá, ˇze vˇetˇsina mobiln´ıch telefon˚ u bude vyuˇz´ıvat pˇripojen´ı k internetu. Mobiln´ım hrám to pˇridává mnoho moˇznost´ı. Lze sd´ılet nejvyˇsˇs´ı skóre s kamarády, nebo napˇr´ıklad dosaˇzené achievementy. Pˇripojen´ı k internetu umoˇzn ˇuje uˇzivateli stahovat do telefonu dalˇs´ı obsah do hry, napˇr´ıklad nové levely. Nˇekteré hry mohou j´ıt hrát i pˇr´ımo online mezi telefony, bud’ jako taková hra, nebo u ´plnˇe naˇzivo (realtime). Fyzik´ aln´ı simulace Mnoho mobiln´ıch her v dneˇsn´ı dobˇe vyuˇz´ıvá algoritm˚ u pro simulaci fyzikáln´ıch zákon˚ u. Padán´ı kostek ve hrách potom vypadá reálnˇe, stejnˇe tak jako rozráˇzen´ı kuˇzelek, ovládán´ı auta apod. Tyto simulace se z d˚ uvodu omezeného v´ ykonu zaˇr´ızen´ı vˇetˇsinou pouˇz´ıvaj´ı jen u jednoduˇsˇs´ıch dvourozmˇern´ ych mobiln´ıch her. Existuje pro nˇe uˇz nˇekolik pˇripraven´ ych knihoven, jako napˇr´ıklad Farseer Physics Engine [10].

9

2. N´ avrh hern´ıho 3D engine Tato kapitola se zab´ yvá konkrétn´ım popisem, jak by se mohl 3D engine navrhnout a jaké souˇca´sti by mˇel obsahovat. Popsána je struktura projektu a je rozvedeno, jaké by se mohly vyuˇz´ıt grafické techniky pro vylepˇsen´ı vzhledu scény.

2.1

Spr´ ava hern´ıch obrazovek

Základn´ı poˇzadavek na správu hern´ıch obrazovek byl, aby mˇel programátor, kter´ y bude nad touto knihovnou vytváˇret svoji hru, co nejv´ıce ulehˇcenou práci. Na zaˇcátku hry by si nadefinoval jednotlivé objekty obrazovek. Rozm´ıstil si na nˇe ovládac´ı prvky a urˇcil by, jak budou obrazovky mezi sebou provázané. Dál by uˇz do jejich bˇehu nemusel zasahovat, pˇrecházen´ı mezi obrazovkami, naˇc´ıtán´ı a ˇ o to rozodnaˇc´ıtán´ı grafického obsahu apod. by uˇz fungovalo automaticky. Slo hodnout, co vˇsechny by tedy tyto objekty obrazovek mˇely umˇet a jak´ y obsah by se na nich mohl nacházet. Zvolen byl pˇr´ıstup, ˇze kaˇzdá obrazovka m˚ uˇze obsahovat tˇri kolekce objekt˚ u– grafické vrstvy, dotykové vrstvy a vrstvy pohybového senzoru. Pˇri programován´ı hry se jako prvn´ı na zvolenou obrazovku napˇr´ıklad um´ıst´ı vrstva pozad´ı, ta bude jen grafickou vrstvou. Nad ni se pˇridá objekt, kter´ y bude ´ e nejv´ vykreslovat naˇcten´ y hern´ı plán. Uplnˇ yˇs se potom um´ıst´ı ovládac´ı prvky, jako napˇr´ıklad virtuáln´ı joystick. Bude tak oddˇelena logika jednotliv´ ych komponent. Vytvoˇrené komponenty se d´ıky tomu budou moci vyuˇz´ıvat ve v´ıce hrách. Jednotlivé komponenty budou moci obsahovat i vlastnosti v´ıce vrstev. Virtuáln´ı joystick bude napˇr´ıklad definován jako grafická i dotyková vrstva, bude se tedy vykreslovat na displej i reagovat na dotyky a gesta. Grafick´ e vrstvy Objekt obrazovky se potom bude starat o správné volán´ı metod jednotliv´ ych komponent. Pˇri své inicializaci zavolá inicializaci také na vˇsechny svoje vrstvy. Grafick´ ym vrstvám se nav´ıc postará o naˇcten´ı obsahu, v pˇr´ıpadˇe pˇrechodu na jinou obrazovku také o jeho odnaˇcten´ı. Pokud nastane zmˇena orientace displeje, tuto informaci také pˇredá dál vˇsem grafick´ ym vrstvám. Tento koncept grafick´ ych vrstev byl ve v´ ysledné práci nakonec jeˇstˇe rozˇs´ıˇren. Kaˇzdé takové vrstvˇe se m˚ uˇze zadat sada dvojic obrazovek, mezi kter´ ymi by mˇela pˇreˇz´ıt. Objekt obrazovky se potom postará o to, aby pˇri pˇrechodu na jinou obrazovku nebyl jej´ı obsah odnaˇcten. M˚ uˇze se tak napˇr´ıklad udrˇzovat vrstva pozad´ı, která bude um´ıstˇena pod vˇsemi 10

hern´ımi obrazovkami po celou dobu bˇehu programu. V pamˇeti bude ale uloˇzená jen jednou. Pokud se na n´ı budou vykreslovat napˇr´ıklad animace, ty na sebe budou plynule navazovat i pˇri pˇrechodech mezi obrazovkami. Dotykov´ e vrstvy U dotykov´ ych vrstev má objekt obrazovky za u ´kol starat se o to, aby kaˇzdé takové vrstvˇe byly pos´ılány jen ty dotyky, které se k n´ı mohly dostat. Kaˇzdá vrstva si m˚ uˇze nadefinovat oblast, na kterou bude reagovat. Aktuálnˇe stisknuté dotyky na displeji se nejdˇr´ıv pos´ılaj´ı vrstvˇe, která je nejv´ıc nahoˇre. Ta m˚ uˇze nˇekteré odchytit a zpracovat. Ostatn´ım vrstvám na niˇzˇs´ıch hladinách jsou potom odes´ılány uˇz jen ty dotyky, které nebyly zpracovány ostatn´ımi vrstvami. Uˇziteˇcné bude, pokud uˇzivatel bude moci zapoˇcnout taˇzen´ı prstu na ovládac´ım prvku, ale s t´ımto taˇzen´ım bude moci pokraˇcovat po oblasti celého displeje. Nebude si muset hl´ıdat, zda se jeho prst stále nacház´ı napˇr´ıklad na joysticku. Bude to tak pro nˇej mnohem pˇrirozenˇejˇs´ı. Stejnˇe tak, pokud se rozhodne posouvat hern´ı plán, t´ımto prstem bude moci pˇrej´ıˇzdˇet i pˇres ostatn´ı ovládac´ı prvky. Objekt obrazovky si tedy bude nav´ıc pamatovat, které vrstvy se dan´ y dotyk poprvé dotknul (kde zaˇcalo taˇzen´ı prstu). Informace o tomto dotyku se potom budou pos´ılat dál uˇz jen této zvolené vrstvˇe. Vrstvy nakl´ apˇ en´ı Tˇret´ım typem vrstev jsou komponenty, které maj´ı za u ´kol zpracovávat vstup z pohybového senzoru. I kdyˇz toto asi nebude nejˇcastˇeji vyuˇz´ıvaná funkcionalita, umoˇzn´ı to alespoˇ n oddˇelit logiku zpracovávaj´ıc´ı naklápˇen´ı telefonu mimo bˇeˇznou aktualizaˇcn´ı metodu, stejnˇe tak, jako se to dˇelalo u ostatn´ıch typ˚ u vrstev. Na naklopen´ı telefonu bude moci na jedné obrazovce opˇet reagovat i v´ıce komponent. Bude se tak moci urˇcovat u ´hel naklonˇen´ı kamery, i napˇr´ıklad specifické pozice ovládac´ıch prvk˚ u.

2.2

Zpracov´ an´ı uˇ zivatelsk´ eho vstupu

Na zaˇca´tku kaˇzdého vykreslovaného sn´ımku se nejdˇr´ıve zjist´ı aktuáln´ı vstup, ten se pˇredá jednotliv´ ym vrstvám na zobrazené obrazovce. Kaˇzdá vrstva si ho bude moci zpracovat. Urˇcitˇe se bude hodit, aby tyto vrstvy mˇely nˇejakou moˇznost spolu jednoduˇse komunikovat. Virtuáln´ı joystick bude moci napˇr´ıklad nastavit podle své pozice poloˇzku posuˇ n pohled doleva. Kamera d´ıvaj´ıc´ı se na hern´ı plán potom na tuto promˇennou bude reagovat sv´ ym posunut´ım.

11

Meziobjekt uˇ zivatelsk´ eho vstupu Pro tuto komunikaci mezi komponentami se bude hodit vytvoˇrit nˇejak´ y spoleˇcn´ y objekt, ve kterém budou udrˇzovány informace o uˇzivatelském vstupu. Tento objekt se na zaˇcátku kaˇzdého sm´ınku postará o naˇcten´ı vstupu z displeje a hodnot z akcelerometru. Také poslouˇz´ı jako urˇcitá mezivrstva ostatn´ım objekt˚ um. Bude m´ıt nˇekolik pˇripraven´ ych poloˇzek jako posuˇ n hlavn´ıho hrdinu, otoˇc kamerou apod., spolu s nˇejak´ ym doporuˇcen´ım, jaké hodnoty by se tam mˇely ukládat. Jednotlivé komponenty na dané obrazovce potom budou moci tyto hodnoty nastavovat, nebo na nˇe nˇejak reagovat. Takto spolu budou moci komunikovat. Pokud by programátorovi nevyhovovala ˇzádná pˇripravená poloˇzka, bude m´ıt k dispozici i obecnou kolekci kl´ıˇc-hodnota, do které si bude moci ukládat jakékoliv hodnoty. Podpora gest Protoˇze v´ ychoz´ı podpora gest v XNA nereflektuje navrˇzenou strukturu dotykov´ ych vrstev, do tohoto objektu se bude hodit pˇridat jeˇstˇe nˇekolik poloˇzek. Sem si budou moci komponenty ukládat doplˇ nuj´ıc´ı informace o taˇzen´ıch prst˚ u po displeji. Bude zde podpora pro posouván´ı jednoho dotyku a pro dvouprsté pinch gesto. Pro toto pouˇzit´ı byla v této práci navrˇzena komponenta DragDropPad, v implementaˇcn´ı ˇca´sti budou popsány jej´ı moˇznosti a jak prob´ıhá jej´ı komunikace s komponentami kamer. Akcelerometr Jak jiˇz bylo ˇreˇceno, objekt uˇzivatelského vstupu se bude také starat o naˇcten´ı hodnot z akcelerometru. Akcelerometr, udávaj´ıc´ı aktuáln´ı náklon zaˇr´ızen´ı, je pomˇernˇe nepˇresná souˇca´stka. I kdyˇz je telefon poloˇzen nehybnˇe na rovném stole, ˇctené hodnoty stále kol´ısaj´ı. Tento objekt by se tedy mˇel postarat o pˇredzpracován´ı a vyˇciˇstˇen´ı tohoto vstupu, aby si to nemusely ˇreˇsit jednotlivé komponenty po svém. ˇ stˇ Ciˇ en´ı zaˇ sumˇ en´ eho vstupu Byla zvolena varianta, kdy lze volitelnˇe zadat poˇcet posledn´ıch namˇeˇren´ ych hodnot, nad kter´ ymi se provede aritmetick´ y pr˚ umˇer. Ve v´ ychoz´ım stavu prob´ıhá ˇcten´ı hodnot z akcelerometru kaˇzdé 2 milisekundy. Byl zvolen obdobn´ y zp˚ usob, jako v ˇclánku [9].

12

Na posledn´ıch 10 mˇeˇren´ ych hodnot se provedl aritmetick´ y pr˚ umˇer. K tomu bylo jeˇstˇe pˇridáno pravidlo, aby se ignorovaly malé zmˇeny hodnot (do +-1.5%). Praktick´ y test na zaˇr´ızen´ıch (Samsung Omnia 7, HTC Trophy [12]) ukázal dostateˇcnˇe pˇresné chován´ı, vhodné bez problém˚ u pro pouˇzit´ı ve hrách. Pro ˇcten´ı dat ze senzoru byla pouˇzita tˇr´ıda Accelerometer. V novém v´ yvojovém SDK verze 7.1 pˇribyla jeˇstˇe druhá moˇznost pˇr´ıstupu, pomoc´ı takzvaného Motion API. U telefon˚ u uveden´ ych v záˇr´ı 2011 (a novˇejˇs´ıch) tento zp˚ usob vyuˇz´ıvá i vestavˇeného digitáln´ıho gyroskopu. Z d˚ uvod˚ u zachován´ı kompatibility se starˇs´ımi zaˇr´ızen´ımi byl ale zvolen prvn´ı zmiˇ novan´ y pˇr´ıstup.

2.3

Spr´ ava objekt˚ u

Jak bylo prob´ıráno v kapitole 1.4, hry se budou skládat z nˇekolik typ˚ u objekt˚ u. Ke vˇsem tˇemto objekt˚ um se budou udrˇzovat informace o jejich transformaˇcn´ı matici, osvˇetlen´ı, polopr˚ uhlednosti nebo st´ınech. Vˇsechny objekty budou m´ıt pˇripravenou metodu pro vykreslen´ı na scénu, nebo pro vykreslen´ı jejich st´ın˚ u. Transformace objekt˚ u Kaˇzd´ y objekt si pamatuje své um´ıstˇen´ı na hern´ım plánu v transformaˇcn´ı matici. Lze mu ale nastavovat i jednotlivé poloˇzky - pozici v trojrozmˇerném prostoru, pootoˇcen´ı, zkosen´ı ve vˇsech osách, pˇr´ıpadnˇe mˇeˇr´ıtko. Transformaˇcn´ı matice je potom urˇcena jako v´ ysledek násoben´ı matic odvozen´ ych z tˇechto hodnot:

transf ormsM = scaleM × shearM × rotationM × translationM ;

(2.1)

Pootoˇcen´ı objektu je internˇe reprezentováno pomoc´ı quaternionu [15]. Lze tak jednoduˇse ovlivˇ novat rotaci objektu podle dan´ ych os, aniˇz by nastal problém zvan´ y gimbal lock [22]. Jsou pˇripravené ale i metody pro pˇrevod této hodnoty do vektoru Eulerov´ ych u ´hl˚ u a zpˇet (ten je reprezentovan´ y tˇremi poloˇzkami – rotac´ı v ose X, Y a Z). Protoˇze v´ ysledná pozice transformac´ı se vztahuje k intern´ımu stˇredu objektu, i posunut´ı na urˇcitou pozici tento objekt posune tak, ˇze se na tomto bodˇe bude nalézat jeho stˇred. Pro nˇekteré pˇr´ıpady se bude hodit metoda pro zarovnán´ı objektu na dan´ y bod, podle jeho levého doln´ıho zadn´ıho rohu.

13

Vykreslen´ı pohledu na sc´ enu To, z jakého u ´hlu vykresl´ı pohled na scénu, zajist´ı abstrakce kamer. Kamery budou objekty obsahuj´ıc´ı matici pohledu (view matrix) a projekˇcn´ı matici (projection matrix). Internˇe budou moci reagovat na zadan´ y uˇzivatelsk´ y vstup, podle nˇeho si pˇrepoˇc´ıtávat tyto matice. Budou moci m´ıt implementované omezen´ı pro pohyb v urˇcit´ ych osách, pro maximáln´ı naklonˇen´ı a podobnˇe. Na posun pohledu budou moci reagovat napˇr´ıklad krátk´ ym dojezdem. Kaˇzdému objektu se pro jeho vykreslen´ı bude pˇredávat objekt kamery. V´ yvojáˇr bude m´ıt k dispozici nˇekolik pˇredpˇripraven´ ych objekt˚ u kamer. V této práci byla naimplementována kamera pro strategie (pro pohled shora nebo zeˇsikma na hern´ı plán), FPS kamera a kamera simuluj´ıc´ı 2D pohled. V´ ysledn´ y pˇrepoˇcet pohledu na scénu je potom urˇcen pronásoben´ım transformaˇcn´ı matice objektu (také naz´ yvané world matrix) spolu s maticemi pohledu a projekce [14] f inalM = transf ormsM × viewM × projectionM

2.4

(2.2)

Spr´ avci sc´ eny

Objekty na scénˇe budou udrˇzovány ve správc´ıch scény. Ty budou zajiˇst’ovat základn´ı operace, jako jejich naˇcten´ı ze soubor˚ u, nebo následné vykreslen´ı na displej. Také budou pomáhat odpov´ıdat na dotazy typu ”Který objekt je nebl´ıˇz?”, pˇr´ıpadnˇe pomáhat ovˇeˇrovat kolize mezi objekty. Bude na kaˇzdém správci scény, do jak´ ych kolekc´ı a jak´ ym zp˚ usobem si bude tyto objekty vnitˇrnˇe uspoˇra´dávat. Jedna hra bude moci vyuˇz´ıvat v´ıce takov´ ychto správc˚ u. Jeden se bude napˇr´ıklad starat o statickou nepohyblivou geometrii, objekty si bude chytˇre rozdˇelovat podle jejich um´ıstˇen´ı (aby následnˇe urychlil jejich vykreslen´ı). Druh´ y správce scény potom bude urˇcen´ y pro pohybuj´ıc´ı se hern´ı objekty. Hra bude moci b´ yt navrˇzena tak, ˇze napˇr´ıklad budou moci reagovat na klikán´ı na displeji pouze objekty z jednoho konkrétn´ıho správce. Stejnˇe tak bude napˇr´ıklad moˇzné zvolit, ze kter´ ych správc˚ u scény by mˇely objekty vrhat dynamické st´ıny. Moˇ znosti spr´ avc˚ u sc´ eny Kaˇzd´ y správce scény bude umoˇzn ˇovat vykreslit vˇsechny nepr˚ uhledné, pˇr´ıpadnˇe polopr˚ uhledné objekty. Také bude umoˇzn ˇovat “splácnout” aktuáln´ı objekty na scénˇe a vykreslit je jako st´ın do urˇcité plochy. P˚ ujde pomoc´ı nˇeho také zavolat vykreslen´ı pomocné geometrie (opsan´ ych orientovan´ ych kvádr˚ u kolem objekt˚ u 14

apod.). Bude umoˇzn ˇovat vrátit nejbliˇzˇs´ı objekt k zadanému paprsku, pˇr´ıpadnˇe vˇsechny s n´ım koliduj´ıc´ı objekty. Konkrétn´ı správci scény budou moci pro urychlen´ı tˇechto operac´ı brát ohled na um´ıstˇen´ı jednotliv´ ych objekt˚ u ve scénˇe. Budou umoˇzn ˇovat vykreslit jen aktuálnˇe viditelné objekty na obrazovce. Stejnˇe tak i pˇri ovˇeˇrován´ı koliz´ı mezi objekty budou moci brát ohled na svoji vnitˇrn´ı strukturu. Reprezentace sc´ eny Pro vnitˇrn´ı reprezentaci objekt˚ u v daném správci scény se dá vyuˇz´ıt nˇekolika datov´ ych struktur. Obvykle se ve 3D grafice pouˇz´ıvaj´ı takzvané BSP stromy, dˇelen´ı scény pomoc´ı portál˚ u [8], nebo struktury jako octree a quadtree [11]. Prvn´ı dvˇe zmiˇ nované struktury maj´ı vyuˇzit´ı pˇredevˇs´ım ve specifickém ˇzánru FPS stˇr´ıleˇcek a vˇsude tam, kde se scény skládaj´ı se z hodnˇe navzájem zakr´ yvaj´ıc´ıch se polygon˚ u. Mobiln´ı hry vˇetˇsinou budou obsahovat sp´ıˇse vˇetˇs´ı poˇcet mal´ ych objekt˚ u, na scénu se ˇcasto bude d´ıvat shora pohledem tˇret´ı osoby. Vyuˇzij´ı se tedy sp´ıˇse takové struktury, které budou posuzovat celé objekty, ne jen jejich jednotlivé polygony. Bude se hodit, kdyˇz hry budou moci obsahovat rozsáhlé levely pˇresahuj´ıc´ı velikost jedné obrazovky. Vykreslovat se z nich ale bude pokud moˇzno vˇzdy jen jejich viditelná ˇca´st. Struktury octree a quadtree naˇsi scénu budou dˇelit do krychl´ı (obrázek 2.1) resp. obdéln´ık˚ u. D´ıky nim bude moˇzné jednoduˇse ovˇeˇrit, se kter´ ymi koliduje pohledov´ y jehlan kamery a jaké objekty by se tedy mˇely odeslat k vykreslen´ı. V této práci byl naimplementován správce scény vyuˇz´ıvaj´ıc´ı struktury octree a objekt terénu, internˇe vyuˇz´ıvaj´ıc´ı struktury quadtree (posuzuj´ı se tak jeho jednotlivé polygony). Octree Správce scény, kter´ y se obvykle bude pouˇz´ıvat ve hrách pro ukládan´ı statické geometrie, bude internˇe vyuˇz´ıvat strukturu octree. Na zaˇcátku bude m´ıt pˇripraven jeden uzel, ten bude pˇredstavovat krychli obep´ınaj´ıc´ı celou scénu. S kaˇzd´ ym pˇridán´ım dalˇs´ıho objektu do scény si odkaz na nˇej pˇridá i do tohoto uzlu. Pokud celkov´ y poˇcet objekt˚ u v jednom uzlu pˇresáhne urˇcitou hodnotu, tato krychle se rozdˇel´ı na 8 menˇs´ıch podkrychl´ı a do tˇechto nov´ ych uzl˚ u se popˇrehazuj´ı odkazy na tyto objekty. Pokud bude sv´ ym rozmˇerem objekt pˇresahovat rozhran´ı dvou krychl´ı, bude se moci nacházet i ve v´ıce uzlech. Ve v´ ychoz´ım stavu bude nastaven maximáln´ı poˇcet objekt˚ u v jednom uzlu napˇr´ıklad na 5 kus˚ u, kaˇzdá hra si to ale bude moci nastavit po svém. Bude zde jeˇstˇe omezen´ı na nejmenˇs´ı moˇznou velikost stˇeny, aby nevznikaly zbyteˇcnˇe malé

15

krychliˇcky. Pod tuto hodnotu se uˇz dále uzly nebudou dˇelit (ve v´ ychoz´ım stavu bude minimáln´ı velikost stˇeny krychle nastavena napˇr´ıklad na 2 hern´ı jednotky). Prvotn´ı nastaven´ı velikosti nejvˇetˇs´ı krychle bude moci b´ yt urˇceno i dynamicky, objekty se pˇredem naˇctou do jiného pomocného správce scény, ten vrát´ı potˇrebnou ideáln´ı velikost a um´ıstˇen´ı. Vykreslov´ an´ı pomoc´ı octree Pˇri vykreslován´ı objekt˚ u se bude procházet tato stromová struktura. Pokud se bude dan´ y uzel nacházet cel´ y v pohledovém jehlanu kamery, vykresl´ı se vˇsechny jeho objekty. Pokud se tam bude nacházet jen ˇca´steˇcnˇe, posoud´ı se rekurzivnˇe vˇsech jeho osm poduzl˚ u. Kdyˇz bude dan´ y uzel u ´plnˇe mimo, bude se ignorovat. Protoˇze se dan´ y objekt bude moci nacházet ve v´ıce uzlech najednou, bude potˇreba si dát pozor, aby byl vykreslován jen jednou. Obdobnˇe bude fungovat i algoritmus pro testován´ı koliz´ı objekt˚ u s dan´ ym paprskem.

Obrázek 2.1: Struktura octree, projekˇcn´ı st´ıny a st´ınová koleˇcka

2.5

Polopr˚ uhlednost

S t´ım, jak funguj´ı správci scény, také souvis´ı podpora polopr˚ uhlednosti. Vykreslován´ı polopr˚ uhledn´ ych objekt˚ u ve 3D scénˇe se vˇetˇsinou mus´ı ˇreˇsit zvláˇst’. Pro bˇeˇzné nepr˚ uhledné objekty funguje bez problém˚ u posuzován´ı viditelnosti podle takzvané pamˇeti hloubky (depth bufferu) [6]. To je bitmapa o velikosti displeje, v kaˇzdém pixelu si pamatuje, jak daleko je na této pozici bod nejbliˇzˇs´ıho dosud 16

vykresleného objektu. Pokud se bude cht´ıt vykreslit dalˇs´ı objekt, kter´ y se bude nacházet za n´ım, posoud´ı se jeho pozice podle této pamˇeti a pˇr´ıpadnˇe se nˇejaká jeho ˇca´st nevykresl´ı. Tohle bude v XNA fungovat automaticky, aniˇz by se muselo nˇeco extra nastavovat. U polopr˚ uhledn´ ych objekt˚ u ale nastane problém, ˇze bude poˇzadováno, aby skrz nˇe bylo ˇca´steˇcnˇe vidˇet. Pokud by se nejdˇr´ıve vykreslil zadn´ı objekt a aˇz potom ten pˇred n´ım, vˇse by bylo v poˇra´dku. Pokud by se ale jejich poˇrad´ı prohodilo, zadn´ı objekt by opticky vystoupil dopˇredu. Bude potˇreba tedy tyto objekty nˇejak´ ym zp˚ usobem ˇradit v˚ uˇci pozici kamery. ˇ Razen´ ı objekt˚ u V kaˇzdém správci scény jsou navrˇzeny oddˇelené metody pro vykreslován´ı polopr˚ uhledn´ ych a nepr˚ uhledn´ ych objekt˚ u. Obvyklé pouˇzit´ı ve hrách je takové, ˇze se nejdˇr´ıve vykresl´ı vˇsechny nepr˚ uhledné objekty pomoc´ı vˇsech správc˚ u scén. Potom se teprve zavolá vykreslen´ı polopr˚ uhledn´ ych objekt˚ u. Ty je potˇreba seˇradit vzájemnˇe v˚ uˇci sobˇe napˇr´ıˇc vˇsemi správci scén. [29] Objekty se mohou ˇradit bud’ jen podle jejich nejvzdálenˇejˇs´ıch bod˚ u od kamery, nebo lépe. Hlavnˇe u sloˇzitˇejˇs´ıch scén se nám bude hodit modifikovaná varianta mal´ıˇrova algoritmu (Newell Newell Sancha). [23] Modifikovan´ y mal´ıˇ r˚ uv algoritmus Objekty se v tomto algoritmu budou ˇradit v˚ uˇci sobˇe podle jejich orientovan´ ych kvádr˚ u. Stoj´ı za to zm´ınit, ˇze ne vˇzdy takové setˇr´ıdˇen´ı bude v˚ ubec existovat. I za situace, ˇze kvádry budou na sebe navzájem kolmé a nebudou se spolu nijak prot´ınat, bude moci nastat pˇri urˇcitém pohledu kamery neˇreˇsitelná situace, viz obrázek 2.2. Pokud ale seˇrazen´ı bude existovat, vˇzdy se ho pokus´ı tento algoritmus naj´ıt.

Obrázek 2.2: Neˇreˇsitelná situace uspoˇrádán´ı orientovan´ ych kvádr˚ u (fotografie)

17

Z kaˇzdého objektu se vezme 8 bod˚ u jeho orientovaného bounding boxu. Situace se bude posuzovat v transformovan´ ych souˇradnic´ıch do prostoru obrazovky. Hodnoty X a Y se pˇrevedou tak, aby nab´ yvaly hodnot od –1 do 1. Souˇradnice Z se bude pohybovat od 1 (bod v nekoneˇcnu), do 0 (bod na oˇrezové rovinˇe kamery). Tyto kvádry se poté setˇr´ıd´ı podle jejich nejvzdálenˇejˇs´ı souˇradnice Z. Vezme se nejvzdálenˇejˇs´ı kvádr a postupnˇe se bude testovat nˇekolika podm´ınkami v˚ uˇci vˇsem bliˇzˇs´ım. Pokud se potvrd´ı vˇzdy nˇekterá z podm´ınek v˚ uˇci vˇsem testovan´ ym kvádr˚ um, bude to znamenat, ˇze testovan´ y kvádr je dobˇre um´ıstˇen´ y a m˚ uˇze se vykreslit (ˇze se nacház´ı za vˇsemi ostatn´ımi kvádry, nebo na jeho poˇrad´ı vykreslen´ı nezáleˇz´ı). Pokud v˚ uˇci nˇejakému kvádru jedna z podm´ınek selˇze, tento kvádr se pˇresune na zaˇca´tek (tj. na nejvzdálenˇejˇs´ı pozici) a oznaˇc´ı se, ˇze byl uˇz pˇresouván. Pokud uˇz nyn´ı problém nenastane, bude se moci bez problém˚ u vykreslit. Pokud se zjist´ı, ˇze by se nˇekter´ y kvádr mˇel znovu pˇresouvat na zaˇca´tek, i kdyˇz byl uˇz jednou pˇresouván, rovnou se poˇsle na vykreslen´ı (znamená to, ˇze tuto situaci by algoritmus nedokázal jinak vyˇreˇsit). Sada podm´ınek je navrˇzena od v´ ypoˇcetnˇe nejjednoduˇsˇs´ıch po ty sloˇzitˇejˇs´ı. Kvádr b1 je testovan´ y, posuzujeme se oproti ostatn´ım kvádr˚ um b2. Jak jiˇz bylo ˇreˇceno, pokud nˇekterá z tˇechto podm´ınek uspˇeje, je to v poˇrádku a m˚ uˇze se j´ıt testovat v˚ uˇci dalˇs´ımu kvádru: 1. Nejvzdálenˇejˇs´ı souˇradnice b2.Z je bl´ıˇz, neˇz nejbliˇzˇs´ı b1.Z 2. b1 a b2 se neprot´ınaj´ı v ose X 3. b1 a b2 se neprot´ınaj´ı v ose Y 4. Cel´ y box b1 je za boxem b2 5. Cel´ y box b2 je pˇred boxem b1 ˇ Ctvrt´ a i pátá podm´ınka vypadá na prvn´ı pohled podobnˇe. Proˇc je ale potˇreba ovˇeˇrit oba pˇr´ıpady je vidˇet na obrázku 2.3. Obˇe posledn´ı podm´ınky se ale jeˇstˇe liˇs´ı od standardn´ıho mal´ıˇrova algoritmu v tom, ˇze zat´ımco on vˇzdy posuzuje v˚ uˇci sobˇe dva polygony, zde se porovnávaj´ı celé kvádry. Porovn´ av´ an´ı um´ıstˇ en´ı kv´ adr˚ u Kvádr se m˚ uˇze rozloˇzit na ˇsest stˇen. Podle normálového vektoru kaˇzdé strany se pozná, jestli je tato strana v˚ uˇci pohledu kamery odvrácená nebo pˇrivrácená. Dosazen´ım tˇr´ı bod˚ u této stˇeny se urˇc´ı rovnice roviny. Pokud se do n´ı nyn´ı dosad´ı vˇsechny body druhého kvádru a vˇzdy vyjde v´ ysledek > 0, bude to znamenat 18

ˇ Obrázek 2.3: Ctvrt´ a a pátá podm´ınka v mal´ıˇrovˇe algoritmu (porovnán´ı vzájemné pozice polygon˚ u v˚ uˇci pohledu kamery) u ´spˇech (vˇsechny body druhého kvádru se budou nacházet pˇred, resp. za nˇejakou stˇenou prvn´ıho). Protoˇze by mohly u pˇrilehl´ ych stˇen vznikat jeˇstˇe zaokrouhlovac´ı nepˇresnosti, bude se v této rovnici m´ısto nuly porovnávat napˇr´ıklad v˚ uˇci hodnotˇe -0.000001. Pokud ve scénˇe budou i nˇejaké 2D objekty, ty budou oˇsetˇreny zvláˇst’ (bude se u nich uvaˇzovat jen jedna stˇena). Protoˇze se toto ˇrazen´ı bude volat pˇred vykreslován´ım kaˇzdého sn´ımku, budou se zde hodit i urˇcité optimalizace na u ´rovni kódu. Potˇrebná pomocná pole by mˇela b´ yt nadeklarována pˇredem na zaˇca´tku, jejich velikost by se mˇela mˇenit jen pˇri zmˇenˇe poˇctu polopr˚ uhledn´ ych objekt˚ u na scénˇe. Pro ˇrazen´ı kvádr˚ u podle vzdálenosti by zase mohlo b´ yt vyuˇzito upravené pole, ke kterému by ˇslo pˇristupovat i jako k obousmˇernému spojovému seznamu (aby se kvádry mohly co nejrychleji vymˇen ˇovat). V´ ysledn´ y pohled na scénu bude vypadat napˇr´ıklad jako na obrázku 2.4.

Obrázek 2.4: Scéna s polopr˚ uhledn´ ymi objekty

19

2.6

Vylepˇ sen´ı grafick´ eho vzhledu

Bude snaha, aby 3D scéna vˇzdy vypadala co nejlépe. Na pˇekn´ y vzhled objekt˚ u ve hrách bude m´ıt vliv pˇredevˇs´ım jejich osvˇetlen´ı. Dalˇs´ı techniky, jako napˇr´ıklad vrˇzené st´ıny, potom budou pˇrisp´ıvat k odliˇsen´ı jejich vzájemn´ ych pozic a budou pomáhat k celkovˇe lepˇs´ı orientaci ve scénˇe (obrázek 2.7). Nejlepˇs´ı metody s nejkvalitnˇejˇs´ımi v´ ysledky budou ˇcasto ale ne´ umˇernˇe nároˇcné pro pouˇzit´ı na mobiln´ıch telefonech. Bude tedy záleˇzet, jak´ y se zvol´ı kompromis a které techniky se naimplementuj´ı. Osvˇ etlen´ı Samotné urˇcován´ı správného osvˇetlen´ı objekt˚ u (neboli st´ınován´ı, shading) [32] je uˇz v XNA pˇripravené. Pokud se naˇcte do projektu model, nastav´ı se mu parametry svˇetla a vykresl´ıme se, jeho odvrácená ˇca´st bude automaticky tmavˇs´ı, neˇz ta bliˇzˇs´ı ke zdroji svˇetla. Stejnˇe tak pokud se budou pˇr´ımo ze hry generovat nˇejaké vlastn´ı objekty, bude jim staˇcit jen správnˇe nastavit normálové vektory pro jejich jednotlivé vertexy. O správné vykreslen´ı se potom v obou pˇr´ıpadech postará objekt typu BasicEffect. XNA internˇe pouˇz´ıvá Blinn-Phong˚ uv osvˇetlovac´ı model [13], kter´ y dohromady kombinuje dif´ uzn´ı sloˇzku svˇetla (diffuse light) a sloˇzku odlesk˚ u (specular light). Lze si zvolit per-pixel nebo per-vertex osvˇetlen´ı, nasv´ıtit si objekt aˇz tˇremi svˇetly, nebo urˇcit parametry mlhy. Kaˇzd´ y objekt ve hˇre bude moci b´ yt nasvˇetlován zvláˇst’, jeho parametry osvˇetlen´ı budou urˇceny podle globáln´ıch parametr˚ u engine. Nastaven´ı tˇechto parametr˚ u ale p˚ ujde upravit i jednotliv´ ym konkrétn´ım objekt˚ um. St´ıny Tato práce se bude zab´ yvat pˇredevˇs´ım druhou kategori´ı grafick´ ych vylepˇsen´ı, tedy jak se daj´ı do scény doplnit vrˇzené st´ıny od objekt˚ u. Toto uˇz v XNA nen´ı automaticky ˇreˇseno, pro vykreslován´ı st´ın˚ u existuje v 3D grafice mnoho algoritm˚ u i rozd´ıln´ ych pˇr´ıstup˚ u. Nejpˇresnˇejˇs´ı b´ yvaj´ı metody takzvaného fotorealistického zobrazován´ı, kdy se tmavosti jednotliv´ ych ˇca´st´ı scény posuzuj´ı vrhán´ım paprsk˚ u (tzv. ray-casting). Tyto metody ale nejsou vhodné pro pouˇzit´ı ve hrách, kdy poˇzadujeme, aby se vˇse renderovalo v reálném ˇcase. Mezi dva nejpouˇz´ıvanˇejˇs´ı zp˚ usoby vykreslován´ı st´ın˚ u v poˇc´ıtaˇcov´ ych hrách patˇr´ı metody st´ınov´ ych map (shadow maps) a st´ınov´ ych tˇeles (volume shadows). [3] Oba zp˚ usoby generuj´ı dostateˇcnˇe dobˇre vypadaj´ıc´ı st´ıny, reflektuj´ıc´ı celou scénu. Objekty mohou na sebe vrhat st´ıny vzájemnˇe, mohou se bˇehem hry i pohybovat a animovat.

20

Tyto plnˇe dynamické metody ale nejsou vhodné pro mobiln´ı pouˇzit´ı kv˚ uli jejich velké v´ ypoˇcetn´ı nároˇcnosti. Metody st´ınov´ ych tˇeles jsou velmi náchylné na sloˇzitˇejˇs´ı geometrii model˚ u. Nav´ıc generuj´ı jen ostré st´ıny, ne nˇejak´ ym zp˚ usobem rozmazané. Metody st´ınov´ ych map mohou podávat v urˇcit´ ych pˇr´ıpadech lepˇs´ı v´ ysledky, pro jejich dobrou implementaci je ale zapotˇreb´ı ˇca´st kódu provádˇet pˇr´ımo na grafické kartˇe. Psan´ı vlastn´ıch shader˚ u ale nen´ı pro Windows Phone v SDK 7.1 zat´ım povoleno. Mus´ı se tedy zvolit jeˇstˇe jiná varianta. St´ınov´ a koleˇ cka V´ ypoˇcetnˇe nejjednoduˇsˇs´ı, ale pˇritom pro vˇetˇsinu her dostaˇcuj´ıc´ı, bude metoda takzvan´ ych st´ınov´ ych koleˇcek. Pod dan´ y objekt se um´ıst´ı pr˚ uhledn´ y ˇctverec, kterému se nastav´ı nˇejaká textura. Vˇetˇsinou to bude nˇejaké rozmazané koleˇcko, tento obsah ale bude moci b´ yt odvozen i od tvaru p˚ uvodn´ıho objektu. Kdyˇz se potom s objektem bude pohybovat, bude se s n´ım automaticky h´ ybat i jeho st´ın. Tato metoda bude vhodná pro vˇsechny pohybuj´ıc´ı se objekty ve hˇre. Pˇri prvotn´ım nastavován´ı tohoto st´ınového koleˇcka mu bude zadáno, na jaké v´ yˇsce (pozici Y) by se mˇelo vykreslovat. Bude se taky moci zapnout, aby se zmenˇsovalo, pokud se od této hladiny objekt dostateˇcnˇe v´ yˇskovˇe vzdál´ı. V kontextu engine potom tento st´ınov´ y objekt bude ˇrazen mezi ostatn´ı polopr˚ uhledné objekty, bude se na nˇej vztahovat i zmiˇ nované ˇrazen´ı podle vzdálenosti. Projekˇ cn´ı st´ıny Druhou metodou, dostupnou v této knihovnˇe, budou takzvané projekˇcn´ı st´ıny na plochu, viz obrázek 2.1. Urˇc´ı se matice, která zajist´ı prom´ıtnut´ı objekt˚ u do zadané plochy, podle smˇeru svˇetla. Objekty ze zadaného správce scény se potom t´ımto deformovan´ ym zp˚ usobem vykresl´ı, budou m´ıt pro tuto operaci pˇripravenou upravenou vykreslovac´ı metodu. Objekty se vykresl´ı bez osvˇetlen´ı, jen ˇsedou barvou, se zadanou polopr˚ uhlednost´ı. Aby v´ ysledn´ y st´ın p˚ usobil jednolitˇe, kromˇe pamˇeti hloubky (depth bufferu) se zde vyuˇzije i stencil buffer [20]. Bude se v nˇem, jako ve speciáln´ı pomocné pamˇeti, pamatovat, jestli se na dané m´ısto uˇz zapisovalo. St´ıny od r˚ uzn´ ych tˇeles se tedy nebudou nijak sˇc´ıtat a pˇrekr´ yvat, v pˇr´ıpadˇe, ˇze uˇz nˇekde bude nˇejak´ y st´ın, ˇsedá barva se tam vykresl´ı jen jednou. Toto se nebude renderovat do nˇejaké textury, ale pˇr´ımo na obrazovku. Obvykl´ y postup pˇri programován´ı hry bude takov´ y, ˇze se vykresl´ı vˇsechny nepr˚ uhledné objekty, potom se zavolá vykreslen´ı tˇechto dynamick´ ych st´ın˚ u na plochu. Následnˇe se budou moci vykreslit ostatn´ı polopr˚ uhledné objekty. Protoˇze se pro kaˇzd´ y objekt bude volat jeho standardn´ı vykreslovac´ı metoda a

21

nav´ıc ta, pro vykreslen´ı st´ınu, vykreslen´ı scény bude tedy cca dvakrát nároˇcnˇejˇs´ı, neˇz bez st´ın˚ u. Nemˇelo by ale b´ yt v´ıce ovlivnˇeno vzájemnou pozic´ı objekt˚ u apod. V pˇr´ıpadˇe vyuˇzit´ı správce scény se strukturou octree se také bude moci ˇcerpat i z optimalizac´ı, ˇze se budou renderovat jen st´ıny od potenciálnˇe viditeln´ ych objekt˚ u. Stoj´ı za to pˇripomenout, ˇze tyto st´ıny také nebudou rozmazané (budou ostré) a budou vˇzdy vykreslené do jedné plochy (objekty nebudou vrhat st´ıny na jiné objekty). Tato metoda ale bude vhodná, stejnˇe tak jako ta pˇredchoz´ı, pro dynamické pohybuj´ıc´ı se objekty. Lightmapy Pro pouˇzit´ı v mobiln´ıch hrách bude vhodné naimplementovat jeˇstˇe jeden typ st´ın˚ u. Pro statické nepohyblivé objekty bude moˇzné pˇredpoˇc´ıtat, kam by na nˇe dopadly st´ıny od ostatn´ıch objekt˚ u. St´ıny se tedy nebudou poˇc´ıtat dynamicky pˇri vykreslován´ı kaˇzdého sn´ımku, ale vypoˇc´ıtaj´ı se jen jednou na zaˇca´tku, napˇr´ıklad pˇri prvn´ım spuˇstˇen´ı hry. Vykreslován´ı potom nebude tˇemito v´ ypoˇcty zpomalované. St´ıny také bude moˇzné pˇripravit ve vyˇsˇs´ı kvalitˇe, bude je moˇzné vygenerovat i v grafickém 3D editoru a následnˇe naˇc´ıst do hry. V´ yhodou také bude, ˇze pˇrekryvné lightmapy budou moci b´ yt v jiném rozliˇsen´ı, neˇz samotné textury na objektech. Stejné textury budou moci b´ yt opakovány na v´ıce objektech, jednotlivé lightmapy k nim budou urˇceny nezávisle. Zmˇenou jejich rozliˇsen´ı bude také moˇzné regulovat jejich pamˇet’ovou nároˇcnost. Dosáhne se t´ım, mimo jiné, také urˇcitého pˇr´ıjemného rozmazaného efektu. V implementované knihovnˇe bude zahrnuta podpora pro generován´ı lightmap do obdéln´ık˚ u a pro kvádry. Pˇri jejich v´ ypoˇctu bude pro kaˇzdou stˇenu takovéhoto kvádru urˇcena jedna textura. Do n´ı si vykresl´ı své st´ıny vˇsechny objekty, které je tam mohli vrhnout. Podobnˇe, jako pˇri posuzován´ı poˇrad´ı objekt˚ u v algoritmu polopr˚ uhlednosti, zde bude nutné zjistit, které z tˇechto objekt˚ u se nacházely za poˇzadovan´ ym polygonem (v˚ uˇci smˇeru svˇetla). Takové objekty se zanedbaj´ı, aby na dan´ y polygon nevrhaly faleˇsn´ y st´ın. Protoˇze se tyto st´ıny budou pˇredpoˇc´ıtávat na zaˇcátku, bude moˇzné si dovolit i dalˇs´ı vylepˇsen´ı vzhledu. St´ıny budou vypadat jemnˇe zapuˇstˇené, pokud se na texturu provede jeˇstˇe volitelné rozmazán´ı (viz obrázky 2.5 a 2.6). Mlha Dojem hloubky m˚ uˇze scénˇe dodat také efekt takzvané mlhy. Vzdálenˇejˇs´ı ˇcásti objekt˚ u od kamery se vyrenderuj´ı pˇrekryté urˇcitou barvou. V pˇr´ıpadˇe ˇcerné barvy bude scéna vypadat jakoby v ˇseru (obrázek 2.8). Tato funkcionalita je uˇz v XNA k dispozici, bude ji potˇreba jen zahrnout do kontextu ostatn´ıch ˇca´st´ı knihovny.

22

Obrázek 2.5: Pˇredpoˇc´ıtané lightmapy aplikované na kvádry

Obrázek 2.6: Lightmapa aplikovaná na plochu (st´ın na podlaze)

23

Obrázek 2.7: Scéna vykreslená se st´ıny (1) a bez st´ın˚ u (2). St´ıny dodávaj´ı scénˇe mnohem pˇrirozenˇejˇs´ı vzhled, umoˇzn ˇuj´ı lépe odhadovat vzdálenosti mezi pˇredmˇety.

Obrázek 2.8: Ukázka efektu mlha (ˇcerné barvy), aplikovaného na scénu

24

3. Implementace V této kapitole je popsána konkrétn´ı implementace knihovny, jej´ı architektura a uvedena struktura tˇr´ıd. Je zde rozvedeno, jak spolu jednotlivé ˇca´sti komunikuj´ı. Pro implementaci knihovny byl zvolen jazyk C# 4.0 (.NET Framework 4.0) a XNA Framework verze 4.0. Vyuˇzito bylo Windows Phone SDK verze 7.1 [19].

3.1

Hierarchie projektu

Kaˇzdá hra m˚ uˇze obsahovat nˇekolik hern´ıch obrazovek. Jedna z nich bude vˇzdy vybraná jako aktuálnˇe zobrazená. Objekt hry si také udrˇzuje odkaz na objekt uˇzivatelského vstupu (viz obrázek 3.1). Hern´ı obrazovka se m˚ uˇze skládat z nˇekolika vrstev (z konkrétn´ıch komponent, napˇr´ıklad ovládac´ıch prvk˚ u, virtuáln´ıho joysticku apod.). Kaˇzdá takováto vrstva m˚ uˇze obsahovat nˇekolik správc˚ u scény, kaˇzd´ y si bude udrˇzovat svoji kolekci objekt˚ u na hern´ım plánu. Vrstva si také drˇz´ı odkaz na objekt kamery. Odkaz na tuto kameru je pˇredáván konkrétn´ım hern´ım objekt˚ u pro jejich vykreslen´ı, pˇr´ıpadnˇe do nˇekter´ ych metod daného správce scény.

Obrázek 3.1: Hierarchie projektu 25

Do objektu uˇzivatelského vstupu mohou zapisovat a ˇc´ıst data vˇsechny vrstvy, ˇc´ıst z nˇej hodnoty m˚ uˇze i objekt kamery. Mimo tuto základn´ı hierarchii také existuje objekt EngineParams, kter´ y obsahuje globáln´ı parametry a nastaven´ı, je dosaˇziteln´ y ze vˇsech ˇcást´ı knihovny. Jmenn´ e prostory projektu Projekt byl rozdˇelen do nˇekolika jmenn´ ych prostor˚ u. Hlavn´ı funkcionalita knihovny je sdruˇzena ve jmenném prostoru MyEngine. Zde jsou udrˇzovány globáln´ı parametry scény, osvˇetlen´ı a mlhy. Také je zde k dispozici nˇekolik pomocn´ ych funkc´ı rozˇsiˇruj´ıc´ıch funkcionalitu XNA, které mohou b´ yt uˇziteˇcné pro vˇsechny souˇcásti engine. Ostatn´ı tˇr´ıdy jsou rozdˇeleny do jmenn´ ych podprostor˚ u, podle svého urˇcen´ı: MyEngine.Input Zpracován´ı uˇzivatelského vstupu, naˇc´ıtán´ı hodnot z akcelerometru. MyEngine.ScreenManagement Správa hern´ıch obrazovek. Bázové objekty pro grafické, dotykové vrstvy a vrstvy naklápˇen´ı. Implementace konkrétn´ıch komponent, jako virtuáln´ıho joysticku, plochy pro zpracován´ı gest a pro vykreslován´ı hlavn´ıho menu. MyEngine.SceneManagers Správa objekt˚ u ve scénˇe. Nacház´ı se zde obecn´ y bázov´ y objekt, i konkrétn´ı implementace správc˚ u scény (jednoduch´ y manaˇzer a octree). V tomto jmenném prostoru se také nacház´ı algoritmy pro serializaci objekt˚ u ze souboru, pro jejich ˇrazen´ı pˇri polopr˚ uhlednosti a pro generován´ı lightmap. MyEngine.Objects Hern´ı objekty a jejich konkrétn´ı implementace. Základn´ı primitiva (kvádry, jehlany apod.), deformovatelná a drátˇená primitiva, objekt terénu, objekty vyuˇz´ıvaj´ıc´ı lightmapy. Skybox a objekt pro ukládán´ı model˚ u naˇcten´ ych z grafického editoru. MyEngine.Cameras Objekty kamer, pro ovládán´ı pohledu na scénu. FPS kamera, kamera pro strategie, obecná statická kamera, pˇr´ıp. kamera simuluj´ıc´ı 2D pohled na obrazovce. MyEngine.Helpers Pomocné komponenty pro testován´ı her (zobrazován´ı FPS, lad´ıc´ıho textu)

26

3.2

Glob´ aln´ı vlastnosti engine

Globáln´ı parametry engine jsou sdruˇzeny v hlavn´ım jmenném prostoru MyEngine, ve statické tˇr´ıdˇe EngineParams. Je to nˇekolik poloˇzek urˇcuj´ıc´ıch vlastnosti a parametry vykreslován´ı. Ty jsou dostupné ze vˇsech ˇcást´ı knihovny. Programátoˇri, stavˇej´ıc´ı nad touto knihovnou hru, mohou také tyto parametry nastavovat podle sv´ ych potˇreb. Je zde uloˇzen odkaz na meziobjekt uˇzivatelského vstupu a pˇr´ıpadnˇe i na pomocné komponenty pro vykreslován´ı sn´ımkovac´ı frekvence, pˇr´ıpadnˇe lad´ıc´ıho textu. Je zde udrˇzován odkaz na aktuáln´ı zobrazenou hern´ı obrazovku. Dále se zde daj´ı nastavit grafické parametry, jako smˇer a polopr˚ uhlednost vrˇzen´ ych st´ın˚ u, vlastnosti svˇetla a mlhy nebo barvy vykreslované pomocné geometrie. Z´ akladn´ı hern´ı jednotka M˚ uˇze se zde také urˇcit, jak velká bude základn´ı jednotka engine. Jej´ı hodnota udává ˇs´ıˇrku jedné krychle velikosti 1x1x1 v hern´ım svˇetˇe. Pokud budou vˇsechny objekty naˇctené z grafického editoru napˇr´ıklad 20x vˇetˇs´ı, bude se moci nastavit tato základn´ı jednotka také na dvacetinásobek. Podle této hodnoty potom bude automaticky urˇceno rozliˇsen´ı textur lightmap, nebo napˇr´ıklad vzdálenost vrˇzen´ ych st´ınov´ ych koleˇcek od zadané plochy. Parametry mal´ıˇrova algoritmu pro ˇrazen´ı polopr˚ uhledn´ ych objekt˚ u budou také ovlivnˇeny touto jednotkou. Kamery na ni budou reagovat napˇr´ıklad pˇrenastaven´ım pˇredn´ı a zadn´ı oˇrezové plochy, nebo zmˇenou rychlosti posunu po hern´ım plánu. Mapován´ı textur na objekty také nebude muset záviset jen na rozmˇerech objekt˚ u, bude se moci pˇrepnout na mapován´ı podle této základn´ı jednotky. Parametry svˇ etla a mlhy Pro nastaven´ı parametr˚ u svˇetla a mlhy se vyuˇz´ıvaj´ı pˇripravené objekty LightParams a FogParams. Svˇetlu je moˇzné nastavit vlastnosti jako smˇer, základn´ı barvu, barvu odlesk˚ u apod. V pˇr´ıpadˇe mlhy jsou zde uloˇzeny parametry jako barva a kde mlha zaˇc´ıná a konˇc´ı. Obˇema objekt˚ um je moˇzné vybrat dané parametry i z nˇekolika pˇredvolen´ ych nastaven´ı, jako napˇr´ıklad z hodnot typu ostré b´ılé svˇetlo, nebo veˇcern´ı soumrak. Rychlejˇ s´ı naˇ c´ıt´ an´ı obr´ azk˚ u Ve statické tˇr´ıdˇe Operations se nacház´ı sada metod uˇziteˇcn´ ych pro r˚ uzné souˇca´sti knihovny. Je moˇzné k zadanému obdéln´ıku vrátit obdéln´ık takové velikosti, aby jeho obˇe strany byly velikosti mocniny dvou (délky stran budou vˇetˇs´ı nebo rovny

27

p˚ uvodn´ım délkám). To se hod´ı napˇr´ıklad pro urˇcován´ı velikost´ı textur lightmap. XNA na Windows Phone v urˇcit´ ych pˇr´ıpadech vyˇzaduje textury tˇechto velikost´ı, pro dosaˇzen´ı optimáln´ıho v´ ykonu. V této tˇr´ıdˇe se také nacház´ı nˇekolik metod vyuˇziteln´ ych pro ovˇeˇrován´ı koliz´ı, v´ıce viz kapitola 3.9. Ve tˇr´ıdˇe Operations je rovnˇeˇz pˇripravena metoda pro rychlejˇs´ı naˇc´ıtán´ı obrázk˚ u ze souboru. XNA na Windows Phone pˇri nahráván´ı obrázk˚ u do projektu pomoc´ı Content Pipeline konvertuje grafické soubory do bezkompresn´ıho formátu. Nev´ yhodou je, ˇze se tyto pˇrevedené soubory kop´ıruj´ı i do v´ ysledného archivu, ten potom m˚ uˇze nab´ yvat velk´ ych rozmˇer˚ u. Kv˚ uli jejich datové velikosti je také pomalejˇs´ı jejich naˇc´ıtán´ı [27]. V této metodˇe bylo naimplementováno pˇr´ımé nahráván´ı obrázku ze souboru pomoc´ı streamu. Obrázek se vyrenderuje do potˇrebné textury, vˇcetnˇe po´ e se takto obejde Content Pipeline, odpadnou zmiˇ lopr˚ uhlednosti. Uplnˇ nované nev´ yhody. Tento zp˚ usob se dá vyuˇz´ıt napˇr´ıklad pro naˇc´ıtán´ı hodnˇe velk´ ych obrázk˚ u. Jako v´ ychoz´ı zp˚ usob naˇc´ıtán´ı vˇsech obrázk˚ u byl ale v této knihovnˇe ponechán standardn´ı pˇr´ıstup pomoc´ı Content Pipeline. Oproti tomuto ˇreˇsen´ı má oˇsetˇreno, ˇze naˇc´ıtá stejné obrázky ze souboru jen jednou. Ve hˇre m˚ uˇze m˚ uˇze nav´ıc existovat v´ıce Content Manager˚ u, kaˇzd´ y m˚ uˇze obsahovat nˇejakou skupinu naˇcten´ ych objekt˚ u. Stejnˇe tak i objekty z jednoho Content Manageru se mohou následnˇe odnaˇc´ıtat ze scény nezávisle na ostatn´ıch.

3.3

Spr´ ava obrazovek, komponenty

Objekty t´ ykaj´ıc´ı se správy obrazovek jsou sdruˇzeny ve jmenném prostoru MyEngine.ScreenManagement. Základn´ım objektem je tˇr´ıda Screen, která pˇredstavuje jednu hern´ı obrazovku. Jak jiˇz bylo zm´ınˇeno v kapitole 2.1, na kaˇzdou hern´ı obrazovku se mohou umist’ovat komponenty. V kontextu námi navrˇzen´ ych tˇr´ıd je daná komponenta objekt, kter´ y implementuje vlastnosti alespoˇ n jednoho typu vrstev. Rozhran´ı ITouchLayer pˇredepisuje vlastnosti, které mus´ı obsahovat kaˇzdá dotyková vrstva. Rozhran´ı ITiltLayer urˇcuje poˇzadované vlastnosti vrstev naklápˇen´ı. Abstraktn´ı tˇr´ıda GraphicalLayer potom pˇredepisuje nutné vlastnosti a chován´ı grafick´ ych vrstev (obrázek 3.1). Tˇr´ıda Screen je podˇedˇená od typu DrawableGameComponent. Objekty tohoto typu patˇr´ı ke speciáln´ı funkcionalitˇe XNA, umoˇzn ˇuj´ı oddˇelit kód z hlavn´ı hern´ı smyˇcky. Kaˇzdy objekt typu DrawableGameComponent obsahuje metody Initialize, Update, Draw apod., stejnˇe, jako tˇr´ıda Game1. Tyto metody jsou mu volány automaticky, vˇzdy po proveden´ı metod stejného názvu v Game1. Pˇri pˇrechodu na jinou obrazovku se jen p˚ uvodn´ı obrazovka odebere z kolekce Game.Components a pˇreregistruje se tam nová obrazovka. 28

Obrázek 3.2: Správa obrazovek, vrstvy Komponenty na obrazovk´ ach Komponenty umist’ované na obrazovky (podˇedˇené od GraphicalLayer, ITouchLayer nebo ITiltLayer ) uˇz nejsou typu DrawableGameComponent. Volán´ı jejich metod je ˇr´ızenou tˇr´ıdou Screen (podle popsaného chován´ı v kapitole 2.1), vˇcetnˇe naˇc´ıtán´ı a odnaˇc´ıtán´ı obsahu (jak bylo ˇreˇceno, nˇekteré grafické vrstvy mohou napˇr´ıklad pˇreˇz´ıvat i mezi v´ıce obrazovkami). Kaˇzdá grafická vrstva obsahuje vlastn´ı Content Manager, pomoc´ı kterého si naˇc´ıtá data. Pokud má b´ yt tato vrstva odnaˇctena, odnaˇcte i obsah svého Content Manageru a t´ım odalokuje zabraná data. Pˇrechod na jinou obrazovku m˚ uˇze b´ yt proveden bud’ stisknut´ım hardwarového tlaˇc´ıtka zpˇet (podle nastavené poloˇzky Screen.PreviousScreen), nebo m˚ uˇze b´ yt vyvolán nˇekterou dotykovou vrstvou. Kaˇzdá dotyková vrstva má moˇznost ve tˇr´ıdˇe Screen vyvolat událost pˇrechodu na jinou obrazovku. To m˚ uˇze b´ yt v´ yhodné napˇr´ıklad u komponenty hlavn´ıho menu. Hlavn´ı menu Hlavn´ı menu je pˇripravená komponenta pro pˇrep´ınán´ı mezi obrazovkami. Obsahuje vlastnosti grafické i dotykové vrstvy. Dokáˇze vykreslit zadan´ y poˇcet poloˇzek pod sebou, spolu s logem hry (obrázek 3.2). Poloˇzky tohoto menu mohou obsahovat obrázek i text. Pˇri prvn´ım zobrazen´ı, nebo pˇri zmˇenˇe orientace displeje, se

29

animuj´ı. Jsou renderované jako obdéln´ıky otáˇcej´ıc´ı se v trojrozmˇerném prostoru, pomoc´ı ortografické kamery. Poloˇzky jsou zobrazené ve sloupeˇcku pod sebou, lze jim nastavit základn´ı parametry jako velikost okraj˚ u, celkovou ˇs´ıˇrku nebo polopr˚ uhlednost. Aby mohly poloˇzky obsahovat text i podkladov´ y obrázek, jsou tyto dvˇe poloˇzky nejdˇr´ıve vykresleny pˇres sebe do textury. Tato textura je potom aplikována na dan´ y obdéln´ık.

Obrázek 3.3: Komponenta hlavn´ıho menu (ve hˇre Galaxy Jet [31])

Virtu´ aln´ı joystick Virtuáln´ı joystick je komponenta, která na displej vykresluje analogovou páˇcku. M˚ uˇze se pomoc´ı nˇej ovládat pohyb nebo otáˇcen´ı objektu, stejnˇe tak posun a otáˇcen´ı kamery, nebo pˇribliˇzován´ı jej´ıho pohledu. Lze urˇcit, na jakou pozici na displeji se joystick vykresl´ı (do kterého rohu obrazovky), jakou bude m´ıt barvu, velikost, pˇr´ıpadnˇe polopr˚ uhlednost (viz obrázek 2.5 dole). Jednotlivé ˇcásti joysticku (okraje, páˇcka) jsou sestaveny z mal´ ych troj´ uheln´ıˇck˚ u a vykreslovány podle jejich vertex˚ u a index˚ u. Pozice páˇcky se urˇcuje v metodˇe HandleTouch implementované z rozhran´ı ITouchLayer. Vych´ ylen´ı páˇcky joysticku do strany nastavuje zvolenou poloˇzku v meziobjektu pro zpracován´ı vstupu. Jakou konkrétn´ı poloˇzku má nastavovat, se urˇcuje pˇri deklaraci joysticku. Pˇredá se odkaz na tˇr´ırozmˇern´ y vektor (pro tyto u ´ˇcely byla vytvoˇrena jeho referenˇcn´ı verze). Tento vektor si potom mohou ˇc´ıst dalˇs´ı komponenty, napˇr´ıklad jiˇz zmiˇ nované kamery. 30

Komponenta DragDropPad Komponentu DragDropPad lze pouˇz´ıvat zároveˇ n s virtuáln´ım joystickem, na hern´ım plánu bude vˇetˇsinou um´ıstˇena pod n´ım. Pomáhá ve zpracován´ı gest na displeji, ze surov´ ych dat rozpoznává, kdy se táhnulo prstem po displeji, nebo kdy se provedlo dvouprsté pinch gesto. Doplˇ nuje základn´ı podporu gest v XNA, umoˇzn ˇuje ale detekovat gesta jen na urˇcité vrstvˇe. Nad touto vrstvou se mohou nacházet dalˇs´ı pˇrekryvné ovládac´ı prvky. Pokud se bude napˇr´ıklad táhnout prstem po hern´ım plánu a zároveˇ n se bude druh´ ym prstem h´ ybat s ovládac´ım joystickem, bude na hern´ım plánu správnˇe detekováno jen jednoprsté gesto. Do objektu UserInput se takto nastav´ı poˇcáteˇcn´ı pozice a posunut´ı prvn´ıho dotyku, pˇr´ıpadnˇe i druhého. Tyto hodnoty si potom zpracuje dalˇs´ı komponenta, nebo pˇr´ımo zadaná kamera. V této práci byla naimplementována podpora pro posouván´ı a zoom pohledu v objektu StrategyCamera (kamera pro zobrazen´ı pohledu jako ve strategick´ ych hrách, v´ıce viz kap. 3.6).

3.4

Spr´ avci sc´ eny

Bázick´ ym objektem pro vˇsechny správce scén je abstraktn´ı tˇr´ıda GenericSceneManager. Od n´ı jsou poté podˇedˇen´ı konkrétn´ı správci scén – SimpleManager a OctreeManager. Tˇr´ıda GenericSceneManager urˇcuje, jaké vˇsechny vlastnosti by mˇely tyto správci obsahovat a jaké metody implementovat (obrázek 3.3). Kaˇzd´ y správce obsahuje dvˇe pole solidObjects a transparentObjects, ve kter´ ych má uloˇzeny nepr˚ uhledné a polopr˚ uhledné objekty. Ty si m˚ uˇze ale dále reprezentovat i po svém, napˇr´ıklad rozdˇelovat do struktury Octree. Kaˇzd´ y správce obsahuje metodu pro pˇridán´ı nového objektu do kolekce a sadu metod pro vykreslen´ı objekt˚ u (nepr˚ uhledn´ ych, polopr˚ uhledn´ ych apod.). Také se zde nacház´ı metody pro ovˇeˇrován´ı koliz´ı objekt˚ u s koul´ı nebo s paprskem, pˇr´ıpadnˇe pro vrácen´ı viditeln´ ych, nebo vˇsech objekt˚ u. Polopr˚ uhledné objekty by mˇely b´ yt vykreslovány vˇsechny najednou, aby se mohly ˇradit podle své vzdálenosti od kamery (bylo popsáno v kapitolách 2.4 a 2.5). V objektu GenericSceneManager je tedy pro nˇe pˇripravená statická metoda, do které se pˇredaj´ı odkazy na vˇsechny potˇrebné správce scén. Zvol´ı se typ ˇrazen´ı, jestli se má posuzovat jen podle jejich nejvzdálenˇejˇs´ıch souˇradnic od kamery, nebo jestli se má vyuˇz´ıt kompletn´ı mal´ıˇr˚ uv algoritmus. Konkr´ etn´ı spr´ avci sc´ en Naimplementovány byly konkrétn´ı správci scén SimpleManager a OctreeManager. SimpleManager je jednoduchá obálka kolem základn´ı funkcionality GenericSce31

neManager, objekty má uloˇzené jen v pol´ıch solidObjects a transparentObjects, dále si je nijak neorganizuje. Hod´ı se pro ukládán´ı pohybuj´ıc´ıch se objekt˚ u ve scénˇe, pˇr´ıp. jako pomocn´ y správce pro dalˇs´ı kolekce. Objekty se mohou do nˇej napˇr´ıklad naˇc´ıst ze souboru, zjist´ı se jejich parametry (celková velikost) a podle tˇechto parametr˚ u se poté postav´ı struktura Octree. OctreeManager si vnitˇrnˇe organizuje objekty podle jejich pozic a velikost´ı do uzl˚ u stromu, jak bylo popsáno v kap. 2.4. Hod´ı se pro statickou nepohyblivou geometrii. Pro u ´ˇcely testován´ı hry je moˇzné zapnout, aby se vykreslovala vizualizace jeho struktury. Krychle, ve kter´ ych se nenacház´ı ˇza´dné objekty, budou zanedbány, vykreslovány budou jen koncové uzly stromu.

Obrázek 3.4: Správce scény

3.5

Implementace objekt˚ u

Jak bylo ˇreˇceno v kap. 2.3, ve scénˇe se budou nacházet objekty nˇekolika typ˚ u (modely, geometrická primitiva vygenerovaná knihovnou apod.). Kaˇzd´ y objekt bude obsahovat transformaˇcn´ı matici a dalˇs´ı vlastnosti, jako parametry osvˇetlen´ı, polopr˚ uhlednosti apod. Kaˇzd´ y objekt se bude moci také vykreslit, pˇr´ıpadnˇe bude moci b´ yt vykreslen jeho st´ın. Základn´ım bázov´ ym typem, sdruˇzuj´ıc´ı vˇsechny tyto vlastnosti, byla zvolena abstraktn´ı tˇr´ıda GenericObject. Obsahuje veˇskerou logiku spoleˇcnou pro vˇsechny 32

objekty na hern´ım plánu, tj. metody pro pˇrepoˇc´ıtáván´ı souˇradnic, pro nastaven´ı st´ınového koleˇcka apod. Obsahuje také pˇr´ıznak [SerializableFromXML] znaˇc´ıc´ı, ˇze je moˇzné tyto objekty naˇc´ıtat ze souboru. Od GenericObject jsou podˇedˇené objekty ModelObject a PrimitiveObject (obrázek 3.4). Oba obsahuj´ı nav´ıc jednu poloˇzku, odkaz na naˇcten´ y model, respektive na vygenerované primitivum. Jejich vykreslovac´ı metody jsou také naimplementované tak, aby braly ohled na to, jestli vykresluj´ı model/primitivum. Tˇr´ıda ModelObject obsahuje jeˇstˇe poloˇzku BoneTransforms, kde jsou uloˇzeny pozice kost´ı daného modelu. Tyto hodnoty je potom moˇzné vyuˇz´ıt napˇr´ıklad pro jeho animace.

Obrázek 3.5: Hierarchie objekt˚ u

Skybox Od tˇr´ıdy ModelObject je jeˇstˇe podˇedˇena tˇr´ıda SkyboxObject. Do tohoto objektu se ukládá model, kter´ y pˇredstavuje skybox okolo hern´ı scény. Ten se skládá z ˇsesti velk´ ych ˇctverc˚ u, pohybuje se zároveˇ n s kamerou. Má pozmˇenˇenou vykreslovac´ı metodu, vykresluje se bez osvˇetlen´ı, u ´plnˇe za vˇsemi objekty. V´ ysledná obloha potom p˚ usob´ı tak, ˇze se nacház´ı nekoneˇcnˇe daleko za scénou.

33

3.6

Generovan´ a primitiva

Objekt typu PrimitiveObject obsahuje poloˇzku PrimitiveObj. V té je uloˇzeno konkrétn´ı primitivum. Primitiva jsou geometrické objekty vygenerované pˇr´ımo knihovnou pomoc´ı vertex˚ u a index˚ u, jako napˇr´ıklad krychle, kvádry apod. Spadaj´ı pod nˇe i pokroˇcilejˇs´ı objekty, jako napˇr´ıklad terén, nebo drátˇené objekty. Bázovou tˇr´ıdou pro vˇsechna primitiva je tˇr´ıda GenericPrimitive (obrázek 3.5). Obsahuje základn´ı vlastnosti kaˇzdého primitiva, jako jeho barvu, velikost a z n´ı odvozen´ y bounding box. Je zde moˇzné zadat i texturu spolu s jej´ım pˇribl´ıˇzen´ım. Lze pˇrepnout parametr st´ınován´ı z per-vertex na per-pixel.

Obrázek 3.6: Hierarchie primitiv Od této tˇr´ıdy potom dˇed´ı vlastnosti konkrétn´ı objekty, napˇr´ıklad Sphere (koule) nebo Cylinder (válec). Z této tˇr´ıdy jsou odvozené i celé dalˇs´ı skupiny objekt˚ u. GenericLightmapPrimitive zastˇreˇsuje vˇsechna primitiva, na která lze aplikovat pˇredgenerované lightmapy. WireframePrimitive pˇredstavuje bázickou tˇr´ıdu pro drátˇená primitiva. Stejnˇe tak objekty odvozené od IDeformablePrimitive mohou m´ıt speciáln´ı vlastnosti, jako napˇr´ıklad, ˇze je se s jejich vrcholy moˇzné bˇehem hry nezávisle pohybovat.

34

Naimplementovan´ a primitiva v t´ eto knihovnˇ e: RectanglePrimitive Objekt obdéln´ıku. Lze zvolit mapován´ı textury podle jeho kratˇs´ı nebo delˇs´ı strany, podle globáln´ıch nastaven´ ych parametr˚ u engine, nebo u ´plnˇe specificky. Obdéln´ık je vykreslen nastojato (jeho normála smˇeˇruje ve smˇeru osy Z), stˇred 0,0,0 se nacház´ı na pr˚ useˇc´ıku jeho u ´hlopˇr´ıˇcek. Box Objekt kvádru. Textury jsou mapovány tak, aby u boˇcn´ıch stˇen na sebe navazovaly, horn´ı a spodn´ı stˇena je mapovaná zvláˇst’. Intern´ı stˇred se nacház´ı na pr˚ useˇc´ıku jeho tˇelesov´ ych u ´hlopˇr´ıˇcek. Cylinder Objekt válce, pˇr´ıpadnˇe komolého kuˇzelu (lze zvolit velikost polomˇeru kaˇzdé podstavy). Lze zadat poˇcet stˇen pláˇstˇe. V´ ychoz´ı st´ınován´ı je nastaveno na per-pixel. Pyramid, Roof Objekty jehlanu a ”stˇrechy”. Sphere Objekt koule. Lze zvolit pˇresnost, z kolika stˇen se bude skládat. V´ ychoz´ı st´ınován´ı je také nastaveno na per-pixel. DirectPrimitive Obecné primitivum, kterému lze zadat pˇr´ımo pole vertex˚ u, normál a index˚ u. Umoˇzn ˇuje takto nahrát do hry jak´ ykoliv obecn´ y objekt. WireframeBox, WireframeSphere Drátˇená primitiva pro vykreslován´ı testovac´ı geometrie. Maj´ı upravenou vykreslovac´ı metodu, nemohou vrhat st´ıny. Drátˇená koule se vykresluje jako tˇri kruˇznice, kaˇzdá okolo jedné osy. Lze opˇet zvolit poˇcet ˇcar, ze kter´ ych se budou skládat. DeformableBox, DeformableSphere Deformovatelná primitiva. M´ısto standardn´ıho vertex bufferu pouˇz´ıvaj´ı dynamick´ y vertex buffer. Pozice jejich vrchol˚ u lze bˇehem hry mˇenit. Pro ukázku byla naimplementována metoda Deform, která umoˇzn ˇuje zploˇstit krychli nebo kouli tak, aby byl zachován jej´ı objem. LightmapRectangle, LightmapBox, DirectLightmapPrimitive Objekty umoˇzn ˇuj´ıc´ı vyuˇzit´ı pˇredgenerovan´ ych lightmap. Jejich bázovou tˇr´ıdou je tˇr´ıda GenericLightmapPrimitive. Maj´ı zmˇenˇen´ y vertex buffer a upravenou metodu pro vykreslován´ı. Ke kaˇzdému vertexu se neukládá jen jeho pozice, normála a souˇradnice textury, ale i souˇradnice druhé textury (té

35

st´ınové lightmapy, kterou je potom objekt potaˇzen). Vytvoˇren byl vlastn´ı typ deklarace vertex˚ u – DualTextureVertexType, kter´ y obsahuje vˇsechny tyto poloˇzky. Textura dané lightmapy se vypoˇc´ıtává v metodˇe InitializeLightmap, pˇredává se do n´ı odkaz na konkrétn´ıho správce scény. Z tohoto správce scény jsou potom do textury vykresleny st´ıny vˇsech jeho objekt˚ u. Protoˇze pˇri vykreslován´ı pomoc´ı efektu DualTextureEffect se nevyhodnocuje standardn´ı st´ınován´ı objektu (jako u základn´ıho efektu BasicEffect), je potˇreba jeˇstˇe pˇred vykreslen´ım st´ın˚ u urˇcit v´ ychoz´ı svˇetlost daného polygonu. Ta se urˇc´ı podle smˇeru jeho normály a podle nastaveného ambientn´ıho a difuzn´ıho svˇetla. Terrain Terén je dalˇs´ı specifické primitivum. Na zaˇca´tku se mu pˇredá jeho celkov´ y rozmˇer a bitmapa s uloˇzenou v´ yˇskovou mapou. Podle n´ı se mu vygeneruje reliéf kopc˚ uau ´dol´ı. Poˇcet troj´ uheln´ıˇck˚ u, ze kter´ ych se bude skládat, bude urˇcen podle rozliˇsen´ı této textury. Terén má pˇripraveno nˇekolik metod, umoˇzn ˇuje k zadanému bodu vrátit jeho v´ yˇsku (lineárn´ı interpolac´ı mezi vrcholy jednotliv´ ych troj´ uheln´ık˚ u), podle ˇctyˇr zadan´ ych bod˚ u je moˇzné také urˇcit pozici a naklopen´ı objektu poloˇzeného na toto m´ısto. Takto se mohou na terén pozicovat objekty, m˚ uˇze po nˇem napˇr´ıklad jezdit aut´ıˇcko a bude to vypadat pˇrirozenˇe. Cel´ y terén je potaˇzen jednou texturou, ta se ale m˚ uˇze opakovat (lze zvolit jej´ı mˇeˇr´ıtko, obdobnˇe jako u objektu Rectangle), viz obrázek 4.2. Pˇri vytváˇren´ı je terén rozdˇelen na obdéln´ıky o zadané maximáln´ı velikosti. Tyto obdéln´ıky jsou uloˇzeny do struktury quadtree. Pˇri vykreslován´ı terénu se bere ohled na pozici kamery a vykresluj´ı se jen ty obdéln´ıky, které mohly b´ yt viditelné (podobnˇe jako u struktury octree, viz kap. 2.4). Oproti quadtree je zde jeˇstˇe jedna zmˇena – v pˇr´ıpadˇe, ˇze je nˇekterá ˇcást terénu dlouhá, ale u ´zká, je rozdˇelována jen na poloviny, ne na ˇctvrtiny. Opˇet je moˇzné pro testovac´ı u ´ˇcely vykreslovat vizualizaci této struktury. Konstrukce primitiv a pˇ rid´ av´ an´ı objekt˚ u na hern´ı pl´ an Kaˇzdé primitivum se skládá z vertex˚ u a index˚ u, které mu jsou urˇceny na zaˇca´tku v metodˇe ConstructPrimitive. Pˇri této konstrukci primitiva se uvaˇzuj´ı objektové souˇradnice, tedy intern´ı souˇradnice vztahuj´ıc´ı se jen k tomuto primitivu. Samotné napozicován´ı na hern´ı plán je ˇreˇseno aˇz na u ´rovni objektu GenericObject, resp. PrimitiveObject. Stejnˇe tak i dalˇs´ı operace, jako napˇr´ıklad pootoˇcen´ı, zkosen´ı apod. jsou ˇreˇseny aˇz v tomto objektu.

36

Správce scény si udrˇzuje odkazy právˇe na objekty typu GenericObject. Ty mohou internˇe obsahovat primitiva (v objektu PrimitiveObject), nebo naˇctené modely (v objektu ModelObject), vˇzdy ale maj´ı k dispozici stejnou sadu vlastnost´ı a metod. Vˇsem se m˚ uˇze zavolat vykreslen´ı na hern´ı plán (i kdyˇz si tuto metodu mohou internˇe ˇreˇsit po svém). Kaˇzd´ y takov´ yto objekt m˚ uˇze b´ yt do správce scény nahrán dvˇema zp˚ usoby. Bud’ se postupnˇe nadeklaruje jako nov´ y objekt, napˇr´ıklad typu PrimitiveObject, a nastav´ı se mu parametry um´ıstˇen´ı na hern´ım plánu. Do nˇej se uloˇz´ı konkrétn´ı primitivum, napˇr´ıklad kvádr, v konstruktoru se mu rovnou urˇc´ı jeho parametry (rozmˇery, mapován´ı textury apod.). Cel´ y tento objekt se potom vloˇz´ı do daného správce scény.

3.7

Serializace objekt˚ u ze souboru

Druh´ ym zp˚ usobem, jak lze naˇc´ıtat objekty do projektu, je jejich serializace z XML souboru. V souboru je uloˇzen jejich popis, ten se procház´ı a parsuje, podle nˇej se rekonstruuj´ı objekty. C´ılem bylo navrhnout toto naˇc´ıtán´ı ze souboru co nejobecnˇeji, aby bylo co nejménˇe závislé na zmˇenách struktury engine. Pokud by se do knihovny pˇridaly nové funkce, nebo se nˇekteré zmˇenily, aby se nemusel pˇrepisovat parser, pˇr´ıpadnˇe nemusela mˇenit specifikace formátu souboru. Parsov´ an´ı pˇ res reflexi Zvolen a naimplementován byl obecn´ y pˇr´ıstup vyuˇz´ıvaj´ıc´ı reflexi. Soubor se procház´ı postupnˇe od zaˇca´tku. Jednotlivé tagy v XML odpov´ıdaj´ı skuteˇcn´ ym názv˚ um tˇr´ıd v engine, vnoˇrené tagy potom jejich vlastnostem (Property) nebo datovým poloˇzkám (Field). Tyto tagy mohou obsahovat dalˇs´ı vnoˇrené tagy, m˚ uˇze se takto rekonstruovat celá stromová struktura objekt˚ u. Prvn´ım pr˚ uchodem parser projde soubor a zjist´ı, které konkrétn´ı tˇr´ıdy by mˇel oˇcekávat. Ke kaˇzdému tagu v XML souboru najde pomoc´ı reflexe odpov´ıdaj´ıc´ı tˇr´ıdu. Nejdˇr´ıv zkontroluje tagy hloubky zanoˇren´ı 1, uvaˇzuje je jen tehdy, pokud jim odpov´ıdaj´ıc´ı tˇr´ıdy obsahuj´ı atribut [SerializableFromXML]. K jejich vnoˇren´ ym tag˚ um také dohledá odpov´ıdaj´ıc´ı poloˇzky. Nalezené dvojice ’název tagu – odpov´ıdaj´ıc´ı tˇr´ıda’ si uloˇz´ı do vyrovnávac´ı pamˇeti. Pokud se v souboru bude nacházet v´ıce stejn´ ych tag˚ u, nebude je nutné pokaˇzdé znovu vyhledávat. Následnˇe parser znovu procház´ı soubor a vytváˇr´ı odpov´ıdaj´ıc´ı objekty typu PrimitiveObject, ModelObject apod. Zanoˇruje se do struktury a vytváˇr´ı vnoˇrené objekty, tˇem opˇet nastavuje vlastnosti a datové poloˇzky.

37

XML tag také m˚ uˇze obsahovat atribut Type. Ten urˇcuje konkrétn´ı typ objektu, kter´ y se má na toto m´ısto vloˇzit. Název tagu m˚ uˇze b´ yt napˇr´ıklad PrimitiveObj. Pomoc´ı reflexe se najde, ˇze tato poloˇzka je typu GenericPrimitive. V atributu XML tagu uˇz bude ale urˇceno konkrétn´ı primitivum, které od tˇr´ıdy GenericPrimitive dˇed´ı. Napˇr´ıklad LightmapRectangle (viz pˇriloˇzen´ y kód). Vytvoˇren potom bude tento konkrétn´ı objekt.
<E u l e r R o t a t i o n> <X>1 . 5 7 0 8 t r u e f a l s e f a l s e
<S i z e> <X>9 7 Content \ GameTextures \ t e x 1 4 4 5

Rekonstrukce objekt˚ u Takto se podle XML souboru zinicializuj´ı vˇsechny objekty a naˇctou se jejich potˇrebné parametry. Podle tˇechto parametr˚ u je ale bude potˇreba jeˇstˇe ’oˇzivit’. Kaˇzdému konkrétn´ımu primitivu se zavolá metoda ConstructPrimitive, která zajist´ı vygenerován´ı správn´ ych pozic vertex˚ u a index˚ u. Následnˇe se jeho rodiˇcovskému objektu PrimitiveObject nastav´ı bounding box a bounding sphere, pˇr´ıpadnˇe zinicializuj´ı dalˇs´ı parametry. Obdobnˇe se pro vˇsechny objekty typu ModelObject zavolá naˇcten´ı jejich modelu, podle nastavené poloˇzky AssetName. Pokud byla nav´ıc objektu nastavena poloˇzka AlignedToPosition na true, provede se jeho zarovnán´ı na danou pozici, podle jeho doln´ıho zadn´ıho levého rohu. Poté, co se pˇridaj´ı vˇsechny objekty do daného správce scény, provede se inicializace lightmap. Bude tak zaruˇceno, ˇze na sebe budou moci vrhat st´ıny vˇsechny objekty vzájemnˇe. 38

Tento zp˚ usob rekonstrukce objekt˚ u ze souboru nutnˇe vyˇzaduje, aby vˇsechny serializovatelné objekty mˇely k dispozici bezparametrick´ y konstruktor. Stejnˇe tak, aby se i vˇsechny jejich poloˇzky daly vytvoˇrit bezparametricky. Nutnost rozhodován´ı se, kter´ y konstruktor objektu by se mˇel pouˇz´ıt, by zbyteˇcnˇe zvyˇsovala sloˇzitost parseru i zápisu v souboru. Vˇsechny objekty tedy mus´ı b´ yt navrˇzené tak, aby je bylo moˇzné vytvoˇrit s v´ ychoz´ım nastaven´ım, potom se jim teprve nastavily parametry (a následnˇe po naˇcten´ı vˇsech parametr˚ u se jim pˇr´ıpadnˇe provedla konstrukce).

3.8

Kolize objekt˚ u

Kaˇzd´ y objekt ve scénˇe (podˇedˇen´ y od GenericObject) obsahuje nˇekolik poloˇzek, které se mohou vyuˇz´ıvat pˇri ovˇeˇrován´ı koliz´ı. Nacház´ı se zde uloˇzen´ y transformovaný bounding box (AABB) [5], neboli nejmenˇs´ı kvádr, kter´ y obep´ıná objekt um´ıstˇen´ y na hern´ım plánu. Hodnoty jeho vrchol˚ u jsou ve svˇetov´ ych souˇradnic´ıch, jeho stˇeny jsou rovnobˇeˇzné s osami. Obdobnˇe se zde nacház´ı bounding sphere, nejmenˇs´ı koule obep´ınaj´ıc´ı objekt. Také je transformovaná do svˇetov´ ych souˇradnic podle transformac´ı objektu. Tˇret´ı vlastnost´ı, kterou obsahuje kaˇzd´ y objekt, je takzvan´ y orientovaný bounding box (OBB), viz obrázek 3.6. To je nejmenˇs´ı kvádr obep´ınaj´ıc´ı objekt, jeho stˇeny ale mohou b´ yt pootoˇcené zároveˇ n s objektem. Tento kvádr bude vˇzdy menˇs´ı, neˇz transformovan´ y bounding box. V této knihovnˇe je reprezentovan´ y jako pole osmi bod˚ u. Vyuˇz´ıvá se napˇr´ıklad pro posuzován´ı vzájemn´ ych pozic objekt˚ u v mal´ıˇrovˇe algoritmu.

Obrázek 3.7: Transformovan´ y a orientovan´ y bounding box, bounding sphere

39

Naˇ c´ıt´ an´ı bounding box˚ u Generovan´ ym primitiv˚ um jsou bounding boxy a bounding sphere urˇceny pri jejich konstrukci, podle jejich zadan´ ych rozmˇer˚ u. Model˚ um je potˇreba tyto obálky urˇcit pˇri jejich naˇc´ıtán´ı. V této knihovnˇe je to umoˇznˇeno dvˇema zp˚ usoby. Bylo vytvoˇreno rozˇs´ıˇren´ı Content Pipeline, napsán vlastn´ı ContentProcessor. Pokud se modelu zvol´ı Content Processor na ModelBoundingBoxProcessor, bude jeho bounding box automaticky vypoˇc´ıtán pˇri nahráván´ı do projektu. Pokud by se tento parametr u objektu zapomnˇel pˇrepnout, zavolá se pˇr´ıpadnˇe jeˇstˇe metoda GetBoundingBox ve tˇr´ıdˇe Operations, kdy se bounding box vypoˇc´ıtá z vertex˚ u modelu pˇr´ımo za bˇehu. Dalˇ s´ı operace Ve statické tˇr´ıdˇe Operations se nacház´ı i dalˇs´ı metody vyuˇzitelné pˇri ovˇeˇrován´ı koliz´ı, nebo pˇri vyb´ırán´ı objekt˚ u. K zadanému dvourozmˇernému bodu na obrazovce lze vrátit paprsek ve 3D prostoru. Podle zadaného paprsku a plochy lze vrátit pr˚ useˇc´ık s touto plochou. Tyto metody potom mohou b´ yt vyuˇz´ıvány ze správc˚ u scény. Je moˇzné vrátit k zadanému paprsku nejbliˇzˇs´ı objekt (podle jeho bounding sphere), stejnˇe tak i vˇsechny objekty, které se s dan´ ym paprskem prot´ınaj´ı. Takto byla naimplementována moˇznost, aby se hern´ı objekty mohly vyb´ırat kliknut´ım na displeji. Z daného správce scény je také moˇzné vrátit vˇsechny objekty, které koliduj´ı s vybranou bounding sphere. Tyto metody vyuˇz´ıvaj´ı efektivnˇe vnitˇrn´ı struktury dan´ ych správc˚ u scény, tedy napˇr´ıklad octree. Tato sada vlastnost´ı a metod dává dobrou podporu pro dalˇs´ı algoritmy. Do knihovny by se dále mohla doplnit moˇznost pˇresnˇejˇs´ıho v´ ybˇeru objekt˚ u podle jejich orientovaných bounding box˚ u, nejen podle jejich bounding sphere. Stejnˇe tak by se urˇcitˇe hodilo doplnit nˇekolik metod pomáhaj´ıc´ıch s oˇsetˇrován´ım situac´ı typu ’auto jede proti zdi, mˇelo by se zastavit tˇesnˇe pˇred n´ı’.

3.9

Kamery

Jak bylo popsáno v kapitole 2.3, objekt˚ um se bude pˇredávat pro vykreslen´ı odkaz na vybran´ y objekt kamery. Kamerou bude kaˇzd´ y objekt podˇedˇen´ y od interface ICamera (obrázek 3.7). Vˇzdy bude obsahovat matice pohledu a projekce, stejnˇe tak jako dalˇs´ı parametry jako pozici kamery, jej´ı smˇerov´ y vektor a kterou stranou m´ıˇr´ı nahoru. Také zde bude moˇzné nastavit pˇredn´ı a zadn´ı oˇrezovou plochu pohledu.

40

Naimplementováno bylo nˇekolik konkrétn´ıch kamer. Nejjednoduˇsˇs´ım objektem je SimpleCamera, slouˇz´ı jen jako obálka okolo tˇechto hodnot. Hod´ı se, pokud se objektu potˇrebuj´ı do vykreslovac´ı metody pˇredat specifické hodnoty a od kamery nen´ı oˇcekávaná ˇzádná dalˇs´ı vnitˇrn´ı logika. StaticCamera uˇz obsahuje nav´ıc implementace metod Initialize a Update, a metody pro zmˇenu orientace displeje. Je podˇedˇená od GameComponent, to znamená, ˇze jej´ı metody Update a Initialize jsou j´ı volány automaticky. V nich si tato kamera podle nastavené pozice a smˇerov´ ych vektor˚ u pˇrepoˇc´ıtává matice pohledu a projekce.

Obrázek 3.8: Kamery

Vol´ an´ı kamer Obecnˇe je to navrˇzeno tak, ˇze kaˇzdou kameru dˇed´ıc´ı od GameComponent si m˚ uˇze jednoduˇse vyuˇz´ıt nˇekterá z grafick´ ych vrstev na dané obrazovce. Volán´ı jej´ı metody Update bude provádˇeno aˇz na konci kaˇzdého sn´ımku, kdy uˇz bude pˇreˇcten´ y veˇsker´ y uˇzivatelsk´ y vstup a vˇsechny vrstvy uˇz budou m´ıt nastavené potˇrebné parametry v meziobjektu uˇzivatelského vstupu UserInput. Kamera tedy bude moci reagovat na to, ˇze má napˇr´ıklad v poloˇzce UserInput.RotateView nastavené pob´ıdnut´ı k otoˇcen´ı pohledu.

41

Dalˇ s´ı objekty kamer Dalˇs´ı naimplementovanou kamerou je objekt Screen2DCamera. Dˇed´ı od statické kamery StaticCamera, má nav´ıc upravenou metodu pro pˇrepoˇc´ıtáván´ı projekce. Jej´ım u ´kolem je nastavit matice pohledu tak, aby mohly b´ yt objekty ve 3D scénˇe jednoduˇse renderovány na obrazovku dvourozmˇernˇe. Pouˇz´ıvá se ortografick´ y pohled, na displej se renderuj´ı objekty s nastaven´ ymi souˇradnicemi X a Y od nuly do ˇs´ıˇrky/v´ yˇsky obrazovky (na osu Z se nebude brát ohled). Objekt StrategyCamera StrategyCamera je nejpokroˇcilejˇs´ı naimplementovaná kamera. Simuluje pohled na hern´ı plán jako ve strategi´ıch. M˚ uˇze se j´ı zvolit, jestli se má d´ıvat shora, z boku, na ˇsikmo, nebo napˇr´ıklad izometricky. Lze pˇrep´ınat ortografick´ y i perspektivn´ı pohled. M˚ uˇze se otáˇcet kolem své osy a naklápˇet nahoru a dol˚ u. Lze omezit u ´hly, pod kter´ ymi se m˚ uˇze naklápˇet. M˚ uˇze také sv´ ym drobn´ ym naklápˇen´ım reagovat na vstup z akcelerometru. Tato kamera dokáˇze reagovat na vstup i gesta nastavená v objektu UserInput. S pohledem se m˚ uˇze posouvat (lze zvolit voliteln´ y dojezd kamery). Pˇribl´ıˇzen´ı kamery lze ovládat dvouprst´ ym gestem, i napˇr´ıklad virtuáln´ım joystickem. Lze omezit minimáln´ı a maximáln´ı pˇribl´ıˇzen´ı pohledu. Mohou se také ’vyp´ınat’ jednotlivé funkce kamery, v nˇekter´ ych hrách tato kamera napˇr´ıklad nemus´ı umoˇzn ˇovat otáˇcen´ı, jen posun a pˇribliˇzován´ı. Pro reprezentaci jej´ı rotace byly vyuˇzity quaterniony [15]. Kameˇre se na zaˇcátku zadává plocha, na kterou by se mˇela d´ıvat. Polomˇer otáˇcen´ı pohledu je urˇcen jako pr˚ useˇc´ık pohledového paprsku kamery s touto plochou. Pˇri posouván´ı pohledu se také nejdˇr´ıve zjist´ı, jakého bodu plochy se prst dotknul, potom se hern´ı plán posunuje tak, aby se vˇzdy tento bod nacházel pod dan´ ym prstem. Obdobnˇe funguje i dvouprsté pinch gesto pro pˇribliˇzován´ı pohledu, zjist´ı se projekce obou bod˚ u na danou plochu a projekce jejich posunut´ı, podle toho se urˇc´ı pˇribl´ıˇzen´ı kamery. FirstPersonCamera FirstPersonCamera je objekt pˇredstavuj´ıc´ı kameru obvyklou ve stˇr´ıleˇckách hran´ ych z prvn´ıho pohledu. Je s n´ı povoleno rozhl´ıˇzet se do stran, nebo pohybovat smˇerem dopˇredu. Tato kamera neumoˇzn ˇuje pˇribliˇzován´ı, nebo dodateˇcné naklápˇen´ı pomoc´ı pohybového senzoru.

42

4. Vyuˇ zit´ı v praxi V této kapitole je popsán ukázkov´ y projekt. Na závˇer jsou zhodnoceny moˇznosti této knihovny a je porovnána s konkurenc´ı.

4.1

Uk´ azkov´ y projekt, mˇ eˇ ren´ı

Spolu s knihovnou byl k této práci pˇriloˇzen i projekt ukázkové hry pro Windows Phone. Sestává se z obrazovky hlavn´ıho menu a z pˇeti vzorov´ ych scén. V kaˇzdé scénˇe jsou demonstrovány jednotlivé moˇznosti engine. Na jednotliv´ ych obrazovkách jsou pro ukázku zapnuté, nebo vypnuté vybrané parametry vykreslován´ı (napˇr´ıklad vizualizace pomocné geometrie). Po vˇsech scénách se lze pohybovat s kamerou, v nˇekter´ ych je moˇzné klikat na objekty nebo ovládat jejich pohyb. Octree V této scénˇe je demonstrován správce scény vyuˇz´ıvaj´ıc´ı strukturu octree. Je zapnuta vizualizace jej´ı struktury a vypisováno ˇc´ıslo, kolik objekt˚ u se aktuálnˇe vykresluje. Scéna obsahuje vygenerovaná primitiva i naˇctené modely (objekty raketek). Na plochu potaˇzenou texturou trávy je aplikována lightmapa. Pod objekty koule, jehlanu a komolého kuˇzelu jsou vykreslována st´ınová koleˇcka, viz obrázek 4.1. Komol´ y kuˇzel, kter´ y se pohybuje nahoru a dol˚ u, nen´ı zahrnut do této statické struktury. Je souˇca´st´ı druhého správce scény, konkrétnˇe typu SimpleManager. Na plochu je vykreslován jeho projekˇcn´ı st´ın. Prav´ y joystick slouˇz´ı k otáˇcen´ı pohledu, lev´ y joystick k jeho oddalován´ı. Hern´ı plán jde posouvat táhnut´ım prstu, lze ho i pˇribliˇzovat dvouprst´ ym gestem. Pohled na scénu se nakláp´ı podle naklopen´ı zaˇr´ızen´ı. Na scénu je aplikována ˇcerná mlha, vzdálenˇejˇs´ı objekty se tedy jev´ı tmavˇs´ı. Objekty zde nevyuˇz´ıvaj´ı polopr˚ uhlednosti. Mˇ eˇ ren´ı Pro ilustraci, na mobiln´ım telefonu Samsung Omnia 7 [12] renderován´ı této scény bˇeˇz´ı stabiln´ıch 23 FPS (sn´ımk˚ u za sekundu). Tento telefon patˇr´ı k prvn´ı generaci zaˇr´ızen´ı s operaˇcn´ım systémem Windows Phone, novˇejˇs´ı zaˇr´ızen´ı uˇz maj´ı v´ ykonnˇejˇs´ı grafick´ y ˇcip. Pokud se s pohledem posune tak, aby nebyly vidˇet modely raketek, rychlost vykreslován´ı stoupne na 42 FPS. Zvolen´ y model totiˇz obsahuje velké

43

mnoˇzstv´ı polygon˚ u a texturu s velk´ ym rozliˇsen´ım, pro pouˇzit´ı na mobiln´ıch telefonech nen´ı u ´plnˇe vhodn´ y. Kdyˇz se zároveˇ n s modely raketek vypne vykreslován´ı skyboxu, pˇr´ıpadnˇe projekˇcn´ıch st´ın˚ u, vykreslován´ı stoupne aˇz na 50 FPS. Teoretick´ ym maximem telefonu je aˇz 60 FPS, podle jeho dané technologie displeje.

Obrázek 4.1: Prvn´ı ukázková scéna, struktura octree

Polopr˚ uhlednost Ve druhé scénˇe je demonstrováno pouˇzit´ı polopr˚ uhlednosti, viz obrázek 2.4. Vˇsechna primitiva maj´ı nastavenou polopr˚ uhlednost na 60%, k jejich ˇrazen´ı je vyuˇzita naimplementovaná verze mal´ıˇrova algoritmu (viz kapitola 2.5). Na pˇr´ıkladu podlahy je ukázáno pouˇzit´ı objektu DirectLightmapPrimitive. To je primitivum obecného tvaru, které je potaˇzené lightmapou. Je definováno v´ yˇctem vertex˚ u a index˚ u. Mˇ eˇ ren´ı Na telefonu Samsung Omnia 7 se scéna vykresluje 36 aˇz 43 FPS (jen primitiva, bez model˚ u raketek). Rychlost závis´ı na aktuáln´ım pohledu kamery. Pro porovnán´ı, totoˇzná scéna, ale u ´plnˇe bez polopr˚ uhlednosti, je vykreslována 44 FPS. Tento mal´ y rozd´ıl je dán t´ım, ˇze primárn´ı zátˇeˇz zde pˇredstavuje vykreslován´ı skyboxu, pˇr´ıp. ostatn´ıch objekt˚ u. Algoritmus ˇrazen´ı objekt˚ u vykreslované scénˇe nepˇridává takovou v´ ypoˇcetn´ı nároˇcnost, nav´ıc je poˇc´ıtán na procesoru, ne na grafické kartˇe. Zpomalen´ı 44

je kombinac´ı nutnosti pˇrekreslován´ı v´ıce objekt˚ u pˇres sebe a ˇcasu stráveného t´ımto ˇrazen´ım. Ve vˇetˇsinˇe her ale nebudou polopr˚ uhledné objekty v˚ uˇci sobˇe um´ıstˇené tak komplexnˇe, zpomalen´ı tedy bude jeˇstˇe menˇs´ı. Lightmapy Ve tˇret´ı scénˇe je ukázáno pouˇzit´ı generovan´ ych lightmap, viz obrázek 2.5. Naˇcten´ y model vodn´ıho rezervoáru vrhá st´ıny na ostatn´ı kvádry. Tyto st´ıny se pˇredpoˇc´ıtávaj´ı vˇzdy pˇri spuˇstˇen´ı, jejich vygenerován´ı trvá na telefonu cca jednu aˇz dvˇe sekundy. Na vˇsechny tyto textury je zde nav´ıc aplikováno rozmazán´ı, zpr˚ umˇerován´ı hodnot okénkem 3x3 body. Tato scéna je naˇc´ıtána podle popisu v XML souboru level2.xml, viz kapitola 3.7. Mˇ eˇ ren´ı Na daném telefonu bˇeˇz´ı vykreslován´ı 26 FPS. Bez naˇcteného modelu vodn´ıho rezervoáru se scéna vykresluje 29 FPS. Pokud se primitiva nahrad´ı za jejich ekvivalenty bez lightmap, rychlost vykreslován´ı scény stoupne na 39 FPS. Primitiva a ter´ en Ve ˇctvrté scénˇe je demonstrován objekt terénu, spolu s vizualizac´ı jeho struktury quadtree, viz kapitola 3.6. Po scénˇe se jde opˇet pohybovat s kamerou, ˇca´sti terénu mimo jej´ı pohled se nevykresluj´ı. Na daném telefonu se zobrazen´ ym st´ınován´ım a zapnutou mlhou bˇeˇz´ı renderován´ı 34 FPS. Pˇri zobrazen´ı jen poloviny terénu stoupne rychlost na 46 FPS.

Obrázek 4.2: Objekt terénu a vizualizace jeho struktury (quadtree)

45

Pohyb objektu V této jednoduché scénˇe je ukázána moˇznost ovládán´ı pohybu objekt˚ u pomoc´ı virtuáln´ıho joysticku. Kliknut´ım lze vybrat krychli, zobraz´ı se kolem n´ı jej´ı bounding sphere. Nastaven´ım jeho pozice pravého joysticku lze udávat objektu smˇer a rychlost. S pohledem na scénou se m˚ uˇze libovolnˇe posouvat a pˇribliˇzovat.

4.2

Zhodnocen´ı pr´ ace, rozˇ siˇ ritelnost

Do v´ ysledné práce se nakonec podaˇrilo naimplementovat vˇsechny poˇzadované souˇcásti. Do dalˇs´ıch verz´ı knihovny by mohla b´ yt o nˇeco rozˇs´ıˇrena podpora koliz´ı, v souˇcasné podobˇe z˚ ustala jen pomˇernˇe základn´ı. Hodilo by se pˇripravit a dokonˇcit dalˇs´ı komponenty vyuˇzitelné ve hrách, napˇr´ıklad pro vykreslen´ı seznamu level˚ u. Ohlednˇe grafick´ ych technik, vhodná by také byla zabudovaná podpora pro zobrazen´ı billboard˚ u (2D obrázk˚ u, které se otáˇc´ı za pohledem kamery). V této práci také nebyly nijak ˇreˇseny animace model˚ u, jen byla vytvoˇrena základn´ı podpora pro jejich zobrazován´ı. Také navrˇzená struktura správc˚ u scény zat´ım nezahrnula podporu pro urˇcován´ı hierarchie mezi objekty, aby napˇr´ıklad otoˇcen´ı jednoho mohlo ovlivˇ novat pozici druhého. Vˇsechny tyto souˇca´sti by ale nemˇel b´ yt problém doplnit do dalˇs´ı verze. Dalˇ s´ı souˇ c´ asti her V kapitole 1.5 byly zmiˇ novány jeˇstˇe dalˇs´ı obvyklé souˇca´sti her, napˇr´ıklad zobrazován´ı online ˇzebˇr´ıˇck˚ u, nebo vyuˇz´ıván´ı simulac´ı fyziky. Tyto moduly nebyly do implementované knihovny pˇr´ımo zahrnuty. Bud’ je jejich podpora dostateˇcná uˇz pˇr´ımo v XNA Frameworku, nebo se tyto souˇcásti daj´ı jednoduˇse vyuˇz´ıt jako dodateˇcné komponenty. Ve hrách Galaxy Jet a Ethereal Pad [31] byla pro ukázku nˇekterá tato dodateˇcná funkcionalita vyuˇzita. Obˇe hry byly postaveny nad touto knihovnou, vyuˇzily z n´ı správu hern´ıch obrazovek. Pro sd´ılen´ı online skóre byla vyuˇzita sluˇzba mogade.com [21]. Pro pˇrehráván´ı zvuk˚ u postaˇcilo v´ ychoz´ı chován´ı XNA Frameworku – pˇrehráván´ı pomoc´ı tˇr´ıdy SoundEffect. Lokalizace hry byla provedena pomoc´ı standardn´ıch souˇca´st´ı XNA. Pro simulaci pohybu ˇca´stic byla vyuˇzita knihovna Particles Pipeline [1].

46

4.3

Porovn´ an´ı s dalˇ s´ımi knihovnami

V dobˇe zadáván´ı této práce nebyla dostupná ˇza´dná podobná knihovna, urˇcená pro Windows Phone. V XNA existovaly hern´ı 3D engine pro Xbox 360 nebo PC. Od té doby vzniklo nˇekolik projekt˚ u, vˇetˇsinou právˇe rozˇs´ıˇren´ım tˇechto jiˇz existuj´ıc´ıch knihoven. Tato ˇreˇsen´ı, vyv´ıjená po mnoho let profesionáln´ımi t´ ymy, budou urˇcitˇe nab´ızet v´ıce moˇznost´ı, neˇz zde implementovaná knihovna. Pˇresto se ale najdou funkce a vlastnosti, které bude m´ıt tato knihovna origináln´ı. Pro porovnán´ı je uveden seznam nejznámˇejˇs´ıch aktuálnˇe dostupn´ ych knihoven pro Windows Phone, spolu s popisem jejich hlavn´ıch rozd´ıl˚ u. SunBurn 2.0 (Synapse Gaming) 3D engine oficiálnˇe podporovan´ y Microsoftem, s mnoha moˇznostmi. Ve verzi pro Windows Phone 7 podporuje pokroˇcilé mapován´ı svˇetla na objekty, dynamické osvˇetlen´ı, kolize, pˇr´ıpadnˇe zdroje zvuku ve 3D scénˇe. Umoˇzn ˇuje základn´ı post-process efekty a bloom. K dispozici je nˇekolik editor˚ u pro pozicován´ı objekt˚ u, ovládán´ı nastaven´ı parametr˚ u scény apod. Nen´ı známo, ˇze by tento engine umoˇzn ˇoval generovat nové objekty pˇr´ımo za bˇehu (primitiva), kromˇe terénu. Nen´ı zde nijak extra ˇreˇseno ˇrazen´ı objekt˚ u pˇri polopr˚ uhlednosti. Engine je zamˇeˇren pˇredevˇs´ım na grafické techniky, neˇreˇs´ı správu obrazovek, grafick´ ych a dotykov´ ych vrstev apod. Je zpoplatnˇen $250 USD [30]. Delta Engine Multiplatformn´ı engine pro Windows Phone, Android a iOS. Nab´ız´ı ˇreˇsen´ı pro správu scény, vykreslován´ı grafiky, pˇrehráván´ı multimédi´ı. Je k nˇemu pˇriloˇzen´ ych nˇekolik ukázkov´ ych her. Je open-source, ale aktuálnˇe stále ve v´ yvoji. V pˇr´ıpadˇe zájmu o implementaci hry nad t´ımto engine je zat´ım nutné kontaktovat autory [7]. Balder 3D engine 3D engine postaven´ y nad technologi´ı Silverlight, dostupn´ y i pro Windows Phone. Je zdarma pro nekomerˇcn´ı u ´ˇcely. Jeho omezen´ı vycház´ı z pouˇzité technologie, oproti knihovnám postaven´ ym nad XNA Frameworkem jsou jeho moˇznosti omezené. Souˇcasná verze nepodporuje polopr˚ uhlednost. [4] Nova4Phone Technologické demo pro zobrazován´ı 3D grafiky. Nen´ı veˇrejnˇe dostupné, nenab´ız´ı dalˇs´ı funkce oˇcekávané od hern´ıho engine [25].

47

Z´ avˇ er Hlavn´ım c´ılem této práce bylo naimplementovat sadu knihoven, která programátoˇ pˇredevˇs´ım o doplnˇen´ı funkc´ı, které v r˚ um zjednoduˇs´ı práci pˇri vytváˇren´ı her. Slo ˇcistém XNA Frameworku nejsou dostupné, a o rozˇs´ıˇren´ı jeho grafick´ ych moˇznost´ı. S kaˇzd´ ym pˇridán´ım nové grafické techniky na scénu (vykreslen´ı st´ın˚ u apod.) se samozˇrejmˇe zvedá jej´ı komplexita a sniˇzuje se celková vykreslovac´ı frekvence hry. Jak bylo ale ukázáno na vzorovém projektu, pˇri volbˇe dostateˇcnˇe vhodn´ ych technik je moˇzné dosáhnout pˇekn´ ych v´ ysledk˚ u i na nev´ ykonn´ ych mobiln´ıch telefonech. Do v´ ysledné práce se podaˇrilo naimplementovat vˇsechny poˇzadované souˇcásti. Systém hierarchie hern´ıch obrazovek a grafick´ ych a dotykov´ ych vrstev byl v praxi ovˇeˇren na hˇre Galaxy Jet [31]. Zp˚ usob oddˇelen´ı kódu jednotliv´ ych komponent a obrazovek do r˚ uzn´ ych tˇr´ıd se pˇri jej´ı implementaci osvˇedˇcil. Pˇridán´ı podpory alternativn´ıch zp˚ usob˚ u ovládán´ı do jiˇz hotové hry bylo rychlé a bezproblémové.

48

Seznam pouˇ zit´ e literatury [1] App Hub: Particles Pipeline code sample [online]. 2010-10 [cit. 2011-12-05] [2] Apple: iPhone Premieres This Friday Night at Apple Retail Stores [online]. 2007-06 [cit. 2011-11-24] ´ Michal: Optimalizace metody st´ınové pamˇeti hloubky : [3] AUGUSTYN, ˇ diplomová práce, Praha : CVUT, Fakulta elektrotechnická, 2008, 128 l. s. 26-29, Vedouc´ı diplomové práce Ing. David Ambroˇz [4] Balder: 3D engine for Silverlight [online]. Verze 0.8.8.9 2010-10 [cit. 2011-1206] [5] BERGEN, Gino van den: Collision Detection in Interactive 3D Environments, 1st edition, Morgan Kaufmann : 2002-11, 277 p., p. 193–200. ISBN: 155860801X [6] DAWES, Adam.: Windows Phone 7 Game Development, 1st edition, Apress : 2010-27, 592 p., p. 219–222. ISBN: 1430233060 [7] Delta Engine: Easy & fast multiplatform development with .NET [online]. Verze 0.9.1 Beta Preview [cit. 2011-12-06] [8] EBERLY, David H.: 3D Game Engine Design, Second Edition: A Practical Approach to Real-Time Computer Graphics, 2nd edition, Morgan Kaufmann : 2006-11, 1040 p., p. 366–375. ISBN: 0122290631 [9] EDSON, Dave: Using the Accelerometer on Windows Phone 7, [online] The Windows Phone Developer Blog 2010-09-08 [cit. 2011-11-24]. [10] Farseer Physics Engine: version 3.3.1 [online]. 2011-09 [cit. 2011-11-29] [11] GROOTJANS, Riemer: XNA 3.0 Game Programming Recipes : A ProblemSolution Approach, 1st printing, Apress : 2009, 673 p., p. 88–120. ISBN: 143021855X [12] GSM Arena: Samsung i8700 Omnia 7 [online]. [cit. 2011-12-05] 49

[13] HARGREAVES, Shawn: Blog. Specularity, [online]. 2007-04-12 [cit. 2011-11-24] [14] KOCI, Roberto. World, View and Projection Matrix Unveiled, [online]. 2010-08-03 [cit. 2011-11-24] [15] LAMOTHE, Andre: Tricks of the 3D Game Programming Gurus - Advanced 3D Graphics and Rasterization, 1st printing, Sams : 2003, 1728 p., p. 317–337. ISBN: 0672318350 [16] Luma: Blog of Luma The Harvest!, [online]. 2010-03 [cit. 2011-12-07] [17] Microsoft: Silverlight, [online]. [cit. 2011-11-24] [18] Microsoft: Windows Phone [online]. Verze 7.5 [cit. 2011-11-24] [19] Microsoft: XNA Framework [online]. [cit. 2011-11-24] [20] Microsoft MSDN: How To: Draw a Shadow, [online]. XNA Game Studio 3.1 [cit. 2011-11-24] [21] Mogade: Free Solutions For Casual Game Developers [online]. [cit. 2011-1204] [22] MSDN Forums - XNA Framework: Quaternion Tutorial - BlueG [online]. 2006-12-15 [cit. 2011-11-29] [23] NEWELL, M. E. a NEWELL, R. G. a SANCHA, T. L.: A solution to the hidden surface problem, Proceedings of the ACM annual conference, 1972, Vol. 1, p. 443–450, Dostupné na WWW: [24] Nokia: The Nokia story [online]. [cit. 2011-11-24] [25] Nova4Phone: Nova by Vertice Team [online]. 2010-08 [cit. 2011-12-06] 50

[26] Oracle: Java for Mobile Devices [online]. [cit. 2011-11-24] [27] POZNANSKI, Jake: Speeding up XNA Content Load [online]. [cit. 2011-1203] ˇ [28] SLAVÍCEK, Tomáˇs: Specifika platformy, Marketplace. Vyv´ıj´ıme pro Windows Phone, [online]. 2011 (2. d´ıl) [cit. 2011-11-24] ˇ [29] SLAVÍCEK, Tomáˇs: Vykreslován´ı polopr˚ uhledných objekt˚ u ve 3D scénˇe, [online]. 2010-11-21 [cit. 2011-11-24] [30] SunBurn: Game Engine, Synapse Gaming [online]. Verze 2.0 [cit. 2011-12-06] [31] Windows Phone Marketplace: aplikace Galaxy Jet, Ethereal Pad. Tomáˇs Slav´ıˇcek, [online]. [cit. 2011-12-05] ˇ ARA, ´ [32] Z Jiˇr´ı a kolektiv autor˚ u: Modern´ı poˇc´ıtaˇcová grafika, 2. vydán´ı. Brno : Computer Press, 2004, 609 s., s. 339-342. EAN: 9788025104545

51

A. Obsah pˇ riloˇ zen´ eho CD Soubory pˇ riloˇ zen´ e na CD WP7 Game.xap Ukázkov´ y projekt – instalaˇcn´ı bal´ıˇcek do telefonu (viz uˇzivatelská dokumentace). sloˇ zka WP7 Game Zdrojov´ y kód implementované knihovny a ukázkového projektu. Pˇriloˇzen zkompilovan´ y soubor knihovny MyEngine.dll. sloˇ zka Galaxy Jet Druhá ukázková hra – demostrace vyuˇzit´ı správy obrazovek na reálné hˇre. Bakal´ aˇ rsk´ a pr´ ace.pdf Soubor s bakaláˇrskou prac´ı. Na konci je pˇriloˇzena uˇzivatelská a programátorská dokumentace. Uˇ zivatelsk´ a dokumentace.pdf Extra pˇriloˇzen´ y soubor s návodem, jak zprovoznit vzorov´ y projekt na telefonu, pˇr´ıp. v emulátoru. Program´ atorsk´ a dokumentace.pdf Extra pˇriloˇzen´ y soubor s popisem struktury projektu a jednotliv´ ych souˇca´st´ı hry. Také je uveden návod, jak nad touto knihovnou lze postavit hru. sloˇ zka WP7 Game documentation Vygenerovaná dokumentace ze zdrojového kódu (v angliˇctinˇe).

52

B. Uˇ zivatelsk´ a dokumentace Spuˇ stˇ en´ı uk´ azkov´ eho projektu na telefonu Ukázkov´ y projekt, popsan´ y v kapitole 4.1, lze zprovoznit nˇekolika zp˚ usoby. Pro spuˇstˇen´ı hry pˇr´ımo na reálném telefonu je potˇreba v´ yvojáˇrsky odemˇcené zaˇr´ızen´ı se systémem Windows Phone 7.5. Telefon lze odemknout na stránkách App Hub [19], po zaregistrován´ı v´ yvojáˇrˇ e republiky, pro bˇeˇzného v´ ského u ´ˇctu. Ten si lze zaloˇzit i z Cesk´ yvojáˇre stoj´ı registrace $99 USD na rok, registrace studentského u ´ˇctu je zdarma. Druh´ ym zp˚ usobem, jak se dá zaˇr´ızen´ı odemknout, je sluˇzba Chevron WP7 na stránkách labs.chevronwp7.com. Zde je odemˇcen´ı zpoplatnˇeno $9 USD. Pro moˇznost nahráván´ı aplikaˇcn´ıch bal´ıˇck˚ u do telefonu je dále si nutné nainstalovat v´ yvojové nástroje Windows Phone SDK 7.1, opˇet ze stránek App Hub na adrese create.msdn.com. Spolu s nástroji se nainstaluje i v´ yvojové prostˇred´ı Visual Studio for Windows Phone, emulátor telefonu a dalˇs´ı utilitky. Pro odeslán´ı aplikace do telefonu slouˇz´ı poloˇzka Application Deployment v nab´ıdce start, ve sloˇzce Windows Phone SDK 7.1. V tomto dialogu se vybere soubor WP7 Game.xap pˇriloˇzen´ y k této práci, t´ım se nainstaluje dan´ y ukázkov´ y projekt. V telefonu se bude nacházet v seznamu aplikac´ı pod poloˇzkou WP7 Game. Spuˇ stˇ en´ı projektu pomoc´ı beta programu Druh´ ym zp˚ usobem, jak si lze odzkouˇset aplikaci na reálném zaˇr´ızen´ı, je takzvan´ y beta program. Je jednoduˇsˇs´ı zp˚ usob v tom, ˇze si potenciáln´ı uˇzivatel nemus´ı v´ yvojáˇrsky odemykat zaˇr´ızen´ı. Hru lze nahrát na zkouˇsku do jakéhokoliv telefonu, z nˇeho se potom po 90 dnech smaˇze. Pro vyuˇzit´ı tohoto pˇr´ıstupu je potˇreba kontaktovat v´ yvojáˇre a pˇredat mu LIVE ID u ´ˇctu, ze kterého by mˇela b´ yt aplikace pˇr´ıˇstupná. Potom probˇehne jeˇstˇe kontroln´ı schvalován´ı ze strany Microsoftu, do nˇekolika dn´ı by se ale mˇela aplikace na daném telefonu objevit. Spuˇ stˇ en´ı v emul´ atoru Pro moˇznost zkompilován´ı kódu a spuˇstˇen´ı hry v emulátoru je potˇreba m´ıt nainstalované jiˇz zmiˇ nované v´ yvojové nástroje Windows Phone SDK 7.1. Kód lze kompilovat z jakékoliv verze Visual Studia, tyto v´ yvojové nástroje se do nˇej pˇri instalaci zaintegruj´ı. Aby vzorov´ y projekt v emulátoru fungoval, je potˇreba m´ıt grafickou kartu

53

s podporou alespoˇ n DirectX 10 a operaˇcn´ı systém Windows alespoˇ n verze Vista, nebo 7 (na starˇs´ıch Windows XP emulátor nefunguje). Pro optimáln´ı bˇeh je potˇreba m´ıt alespoˇ n 2 GB operaˇcn´ı pamˇeti. V´ ykon emulátoru neodpov´ıdá pˇr´ımo v´ ykonu telefon˚ u, na poˇc´ıtaˇci vˇetˇsinou pobˇeˇz´ı hra rychleji a s vyˇsˇs´ı sn´ımkovac´ı frekvenc´ı. Aby se dalo simulovat v´ıce dotyk˚ u na displeji najednou, je také potˇreba m´ıt k poˇc´ıtaˇci pˇripojen´ y monitor s podporou v´ıce dotyk˚ u. Pro zkompilován´ı projektu staˇc´ı otevˇr´ıt soubor WP7 Game.sln ve sloˇzce pˇriloˇzené k této práci. Solution se skládá z nˇekolika projekt˚ u, projekt MyEngine pˇredstavuje implementovanou knihovnu, v projektu WP7 Game se nacház´ı soubory ukázkového projektu. V rozbalovac´ı paletce, nahoˇre ve Visual Studiu, se zvol´ı c´ılová platforma Windows Phone Emulator. Projekt se zkompiluje a spust´ı stiskem klávesy F5. V emulátoru se dá simulovat zmˇena orientace displeje, klikán´ım na ikonky otáˇcen´ı v malé nab´ıdce napravo (objev´ı se, pokud se pˇres emulátor pˇrejede myˇs´ı). Zde se dá také rozbalit nab´ıdka s moˇznost´ı simulace vstupu z akcelerometru.

54

C. Program´ atorsk´ a dokumentace Struktura projektu a hierarchie tˇr´ıd byla popsána v kapitole 3. Na CD je dále pˇriloˇzena vygenerovaná programátorská dokumentace. V této kapitole bude rozvedeno, z jak´ ych souˇca´st´ı se skládá hra vyuˇz´ıvaj´ıc´ı tento engine a jak s n´ım komunikuje. Na konci bude shrnuto, na co je potˇreba pamatovat pˇri portaci jiˇz existuj´ıc´ı hry nad tento engine. u: Pˇriloˇzen´ y zdrojov´ y kód ve sloˇzce WP7 Game se skládá z tˇechto projekt˚ MyEngine Zdrojov´ y kód implementované knihovny. Nacház´ı se zde vˇsechny souˇca´sti popisované v kapitole 3. MyEngineContent Grafické soubory pˇribalené zároveˇ n s knihovnou. Nacház´ı se zde v´ ychoz´ı p´ısma pro vykreslován´ı sn´ımkovac´ı frekvence displeje nebo lad´ıc´ıho textu. V podsloˇzce Textures se nacház´ı v´ ychoz´ı textura st´ınov´ ych koleˇcek. WP7 Game Soubory vzorového projektu, kter´ y vyuˇz´ıvá implementovanou knihovnu. V souboru Game1.cs se nacház´ı definice hern´ıch obrazovek a jednotliv´ ych vrstev. Sloˇzka MyGame obsahuje implementace jednotliv´ ych obrazovek se vzorov´ ymi scénami. Ve sloˇzce Levels se nacház´ı XML soubory s popisem scény. WP7 GameContent Grafické soubory pˇribalené ke vzorovému projektu. Ve sloˇzce GameTextures se nacház´ı textury vyuˇz´ıvané ve scénˇe s lightmapami. Sloˇzka Models obsahuje modely raketky a vodn´ıho rezervoáru. Ve sloˇzce Skybox se nacház´ı ˇsest potˇrebn´ ych textur pro zobrazen´ı oblohy. Sloˇzka Textures obsahuje textury vyuˇz´ıvané v ostatn´ıch scénách, nebo v komponentˇe hlavn´ıho menu. ContentPipelineExtension Rozˇs´ıˇren´ı naˇc´ıtán´ı model˚ u o jejich bounding boxy, viz kapitola 3.8. Jak nad engine postavit hru Jak je provedena implementace vzorové hry, lze vyˇc´ıst ze tˇr´ıdy Game1 v projektu WP7 Game. Tato tˇr´ıda z˚ ustává prakticky prázdná, veˇskerá konkrétn´ı implementace je ponechána pro objekty jednotliv´ ych hern´ıch obrazovek. V konstruktoru Game1 je provedeno jen nˇekolik zmˇen, je pˇrepnuta rychlost zobrazován´ı aˇz na maximáln´ıch 60 sn´ımk˚ u za sekundu a nastavena barevná hloubka na 32 bit˚ u. Definice hern´ıch obrazovek a jednotliv´ ych vrstev je provedena v metodˇe Initialize. Vˇzdy je vytvoˇren objekt dané obrazovky, do nˇej jsou vloˇzeny odkazy na 55

jednotlivé vrstvy. Je zde zinicializován objekt hlavn´ıho menu. M˚ uˇzou se zde také zadat závislosti, mezi kter´ ymi obrazovkami by jaké vrstvy mˇely mˇely pˇreˇz´ıt. Na konci metody Initialize se urˇc´ı obrazovka, která by se mˇela zobrazit jako prvn´ı a pˇr´ıpadnˇe se zinicializuj´ı komponenty pro vykreslován´ı pomocného textu. Také je zde d˚ uleˇzité zinicializovat objekt uˇzivatelského vstupu UserInput. Implementace hern´ı obrazovky Pro konkrétn´ı implementaci hern´ı obrazovky a návod, jak naˇc´ıtat hern´ı plán, se lze pod´ıvat napˇr´ıklad do tˇr´ıdy LightmapGamePlan ve sloˇzce MyGame. V jej´ım konstruktoru jsou nejdˇr´ıve nastaveny parametry vykreslován´ı globáln´ımu objektu EngineParams. Daná scéna obsahuje dva správce scény, jeden pro statické objekty (vyuˇz´ıvaj´ıc´ı strukturu octree) a druh´ y pro dynamické objekty (vyuˇz´ıvaj´ıc´ı tˇr´ıdu SimpleManager). V metodˇe LoadContent je nadefinován objekt kamery a do dan´ ych správc˚ u scén jsou naˇcteny objekty. Do octree jsou serializovány z XML souboru, do SimpleManageru jsou vloˇzeny manuálnˇe (objekt pohybuj´ıc´ıho se komolého kuˇzelu). V metodˇe Update m˚ uˇze b´ yt objekt˚ um udáván pohyb, je zde vytvoˇrena vzorová animace pohybu komolého kuˇzelu. Jsou zde naimplementovány i metody HandleTouch a HandleTilt. V metodˇe andleTouch jsou zpracovávány dotyky na displeji, pro ukázku je naimplementována moˇznost vyb´ırán´ı objekt˚ u klikán´ım. V metodˇe HandleTilt je vytvoˇreno propojen´ı mezi aktuáln´ım vstupem z akcelerometru a naklánˇen´ım kamery. Metoda Draw slouˇz´ı k vykreslován´ı scény, je zde vidˇet struktura obvyklého volán´ı metod na správc´ıch scén. Nejdˇr´ıv jsou vykresleny vˇsechny nepr˚ uhledné objekty, pˇr´ıpadnˇe jejich drátˇená geometrie. Jsou vykresleny statické objekty, poté dynamické (vˇcetnˇe projekˇcn´ıch st´ın˚ u). Na konci jsou vyrenderovány polopr˚ uhledné objekty. Portace existuj´ıc´ı hry Pro vyuˇzit´ı tohoto engine v novém, nebo existuj´ıc´ı projektu, je potˇreba provést tyto kroky: • Pˇridat do projektu referenci na MyEngine.dll a na zaˇcátek tˇr´ıdy Game1 pˇridat ˇra´dek using MyEngine; • Pˇripravit si objekt grafické vrstvy, ta bude um´ıstˇena na vytvoˇren´ y objekt obrazovky. Tato tˇr´ıda bude dˇedit od GraphicalLayer, pˇr´ıpadnˇe od ITouchLayer nebo ITiltLayer (pokud bude cht´ıt vyuˇz´ıvat vstup z dotykového displeje nebo akcelerometru). 56

• Pokud uˇz p˚ uvodn´ı tˇr´ıda Game1 obsahovala nˇejakou hern´ı logiku, jej´ı kód se m˚ uˇze pˇresunout do nového objektu grafické vrstvy. Logika z metody Update, zab´ yvaj´ıc´ı se uˇzivatelsk´ ym vstupem, se m˚ uˇze oddˇelit do metod HandleTouch a HandleTilt. • Pokud p˚ uvodn´ı kód ve tˇr´ıdˇe Game1 vyuˇz´ıval naˇc´ıtán´ı objekt˚ u pomoc´ı Content Pipeline, nebo vyuˇz´ıval grafického rozhran´ı, v novém objektu vrstvy je potˇreba nahradit promˇennou Content za contentManager a promˇennou GraphicsDevice za game.GraphicsDevice. Pˇr´ıpadné volán´ı this.Exit() je potˇreba nahradit za game.Exit(). • Do metody Initialize tˇr´ıdy Game1 je potˇreba pˇridat inicializaci objektu pro zpracován´ı uˇzivatelského vstupu: EngineParams . U s e r I n p u t = new U s e r I n p u t ( t h i s , t r u e ) ;

• V metodˇe Initialize je dále potˇreba vytvoˇrit nov´ y objekt Screen a do nˇej vloˇzit odkazy na vytvoˇrenou vrstvu (zde pro ukázku pojmenovaná GamePlan). S c r e e n gameScreen = new S c r e e n ( t h i s , ” gameScreen ” ) ; GamePlan gamePlan = new GamePlan ( t h i s ) ; gameScreen . G r a p h i c a l L a y e r s . Add( gamePlan ) ; gameScreen . TouchLayers . Add( gamePlan ) ; gameScreen . T i l t L a y e r s . Add( gamePlan ) ;

• Na konec metody Initialize je potˇreba doplnit nastaven´ı této obrazovky jako aktuáln´ı a jej´ı pˇridán´ı mezi hern´ı komponenty. EngineParams . A c t u a l S c r e e n = gameScreen ; Components . Add( gameScreen ) ;

• Posledn´ı vˇec, kterou je potˇreba udˇelat, je zapsat do metody Update tˇr´ıdy Game1 jeˇstˇe volán´ı aktualizace uˇzivatelského vstupu. EngineParams . U s e r I n p u t . U p d a t e S t a t e s ( ) ;

• Je potˇreba si zkontrolovat, ˇze na konci metody Initialize se nacház´ı ˇra´dek pro volán´ı inicializaˇcn´ı metody vybrané obrazovky: base . I n i t i a l i z e ( ) ;

• Stejnˇe tak, ˇze i v metodách LoadContent, UnloadContent, Update a Draw se nacház´ı obdobná volán´ı. V této chv´ıli by mˇel plnˇe fungovat systém správy obrazovek a dan´ ych vrstev. Na kompletn´ı implementaci se lze pod´ıvat do pˇriloˇzeného projektu WP7 Game do souboru Game1.

57

Hernı 3D engine pro Windows Phone 7

Recommend Documents