kandi_sammandrag.tex

Inom spelindustrin har spelgrafik spelat en stor roll: kraftigare datorer har möjliggjort användningen av mera detalj och komplexitet inom spelvärldar. Under de senaste åren har nya web-teknologier dessutom gjort det lätt att producera spel för ett stort antal konsumenter: i princip vem som helst som har en modern webbläsare. Dessa två spår av teknologisk framgång har dock svårt att mötas. Komplex grafik måste ritas med kraftiga datorkomponenter som webbläsare inte förr har kunnat utnyttja utan utomstående program. Den nya standarden WebGL bör möjliggjöra ritandet av komplicerad grafik utan att användaren behöver installera nya program. Speldesigners kunde i bästa fall göra grafiskt avancerade spel som är tillgängliga åt en stor publik utan att behöva göra enskilda versioner åt olika platformer och operativsystem. Detta arbete undersöker med hjälp av en litteraturöversikt WebGL från speldesigners perspektiv: huruvida teknologin är tillräckligt kraftig och hurudana för- och nackdelar dess användning innebär. Dessutom dras det slutsatser om hurudana projekt WebGL kunde vara passligt för, samt insikter om vilka saker det lönar sig att beakta då man använder programbibliotket.
Teknologin som oftast används för att rita spelgrafik på internet är HTML5 canvas-elementets Canvas 2D Context API. Detta API låter en programmerare rita bilder på en canvas-ruta som i sin tur placeras på en webbsida. Allt räknande som krävs för att producera bilder med Canvas 2D Context görs i datorns centralprocessor. Detta fungerar bra så länge bilderna som ska ritas inte är för detaljerade. I så fall räcker inte centralprocessorns räknekapacitet, varmed datorn kan bli långsam och oresponsiv.
En grafikprocessor är en datorkomponent som är speciellt gjord för grafisk räkning. Svårigheten med att använda grafiska processorer är att de ofta kräver så kallad intern kod. Intern kod är kod som är skriven speciellt för den maskinuppsättningen koden utförs på. Därmed krävs det olika kod för olika datorer och operativsystem. 
WebGL är liksom Canvas 2D Context ett API för canvas-elementet. Det tillåter en programmerare att rita bilder på en webbsida. WebGL skiljer sig dock från 2D Context i och med att man med hjälp av WebGL-kod kan använda datorns grafikprocessor för att utföra räkningarna som krävs för ritandet.
Både WebGL och Canvas 2D Context används med hjälp av programmeringsspråket JavaScript. JavaScript används i webbläsare för att programmera webbsidor. Språket är mycket populärt och program som skrivs med det fungerar i princip i alla moderna webbläsare. För att kunna åstadkomma en sådan flexibilitet måste det dock göras kompromisser. JavaScript kod är i nästan alla fall mycket långsammare än intern kod som C++, vilket är det programmeringsspråket med vilket i princip alla grafiskt krävande spel är skrivna.
Kraven spel ställer på mjukvara är något unika. I undersökningar har det påvisats att bildens resolution och i mindre grad uppdateringstakten starkt påverkar människors åsikt angående kvaliteten av video, där man med uppdateringstakten menar hastigheten med vilken en ny bild ritas på rutan. I spel kan man utöver spelarens åsikt också mäta hur framgångsrik spelaren är. I undersökningar har man funnit att speciellt uppdateringstakten kan ha en dramatisk inverkan på spelförmåga då spelet kräver snabba reaktioner. Spelarnas åsikt om spelets kvalitet stiger dessutom i takt med rutans resolution. Spel som ska se bra ut och kräver snabba reaktioner kräver därmed mycket processorkraft för att fungera.
En jämförelse av olika implementationer visar att WebGL är snabb, dock inte snabbast. Jämfört med Canvas 2D Context är WebGL mångfaldigt snabbare: ritande med Canvas 2D Context tar väl över 5 gånger den tid som med WebGL i samma webbläsare. Ändå tar ritande med WebGL  i sin tur över 5 gånger den tid som intern C++-kod kräver.
Ett intressant fynd är dock att det inte nödvändigtvis är WebGL API:et som står för största delen av skillnaden. Mätningar visar att framställningen av bilden (som utförs i grafiksprocessorn) i själva verket kan vara snabbare i WebGL än i intern kod. Den stora skillnaden inträffar i simulationen, det vill säga då datorn räknar ut var alla objekt som ska ritas befinner sig. I intern kod görs beräkningen i C++-kod, medan den i WebGL görs i JavaScript-kod. Skillnaden i hastighet mellan dessa språk leder därmed till den stora skillnaden i total ritningstid.
Det är dock viktigt att inse att kodens snabbhet inte är den ända faktorn i hur bra ett grafiskt program fungerar. En viktig aspekt är bildkomponenternas laddande från minne. Då grafikprocessorn ritar en bild på rutan måste den veta vilka färger som ska ritas i vilka bildpunkter. Detta görs med hjälp av texturer och 3D-modeller som måste laddas från minne. WebGL kan inte ladda många olika saker på samma gång så som många andra programbibliotek. Ifall en scen som ska ritas är invecklad kan det behövas många olika saker från minne, vilka i WebGL måste laddas enskilt. Detta gör bildens uppdatering långsamt. Designern måste i sådana fall använda sig av något utomstående programbibliotek.
När 3D-objekt väl är laddade kan dock designern inte direkt manipulera dem så som bild- och tet-objekt. HTML5 har API:n för de flesta media-element, så som bilder och ljud, som kan manipuleras direkt från JavaScript-kod. 3D-objekt har dock inget sådant API, och designern måste därmed manipulera dem via andra metoder.
Manipulation av 3D-objekt görs via matematiska transformationer, oftast med hjälp av linjär algebra. Mera etablerade 3D-programbibliotek har vanligen inbyggda bibliotek av sådana matematiska funktioner. WebGL har dock inte sådana inbyggda funktioner, utan de måste antingen hittas i något annat bibliotek eller skrivas av designern.
Olikheterna mellan WebGL och mera etablerade programbibliotek beror på att WebGL baserar sig på OpenGL ES (Open Graphics Library Embedded Systems). OpenGL ES är en förminskad version av ett etablerat programbibliotek, OpenGL, där asynkronisk laddning och linjär algebra är inbyggda. OpenGL ES är menat för att kunna användas i vad som hälst för datorsystem, även pekplattor och mobiler. Därmed är den simplifierad jämfört med det fullt utrustade OpenGL-programbiblioteket. Meningen är att WebGL, liksom OpenGL ES, ska kunna användas i vilken slags dator som helst.
På kodnivå är WebGL dock inte värst mycket mera komplicerat än intern kod: en optimerad ritningsloop i WebGL är 23 rader medan samma i intern kod är 17. Den klara skillnaden ligger mellan WebGL och Canvas 2D Context. Att göra en ritningsloop för Canvas 2D Context API:et kräver 2 rader kod. Man kan därmed definitivt säga att koden blir betydligt mera invecklad då man byter från Canvas 2D Context till WebGL.
Den stora teoretiska fördelen med WebGL är dess universalitet. Om designers behöver endast en kopia av spelkoden, istället för en för varje platform, blir spelproduktion mycket lättare och billigare. Dessvärre är WebGL i praktik inte lika universell som Canvas 2D Context. 2D Context fungerar med säkerhet där webbläsaren fungerar: om inte den ena fungerar så fungerar inte den andra. Men WebGL behöver grafikprocessorn för att fungera, medan webbläsaren behöver endast centralprocessorn. Därmed finns det många grafikprocessorer som inte fungerar tillsammans med vissa webbläsare. Designern kan alltså inte förvänta sig att ett WebGL-program skulle fungera lika vida som Canvas 2D Context-program. 
Det viktigaste sakerna speldesigners borde beakta gällande WebGL är valet av programbibliotek och hur koden skall optimeras. Valet av programbibliotek ger designers möjligheten att använda sådana funktionligheter som inte är inbyggda i WebGL, såsom asynkroniskt laddande. Därmed kan WebGL användas som ett mera komplett grafikprogrambibliotek. Det är också viktigt att koncentrera sig på JavaScript-koden då man optimerar spelprogrammet. På grund av JavaScript-kodens långsamhet kan det till exempel löna sig att förflytta så många räkningar som möjligt till grafikprocessorn, eftersom till exempel fysikaliska räkningar kan vara mycket snabbare att lösa där.
WebGL ligger emellan Canvas 2D Context och intern kod. I fråga om snabbhet är WebGL klart bättre än 2D Context, men når inte nivån av intern kod. Å andra sidan är WebGL-kod mycket mera universellt funktionlig än intern kod, men är ändå inte på 2D Contexts nivå. Projekt där det lönar sig att använda WebGL bör därmed vara någonslags hybrider av dessa två ändor av spektret: inte så pass grafiskt krävande att det behövs kraftiga datorer för att rita spelvärlden, men ändå för invecklade för Canvas 2D Context att klara av. Man ska heller inte förvänta sig att spelet ska fungera på precis alla webbläsare och platformer, men man kan lita på att spelet kommer att fungera på flera platformer än om spelet gjordes med en kopia av intern kod. 
Det är viktigt att inte tro att WebGL är som internt kodade grafikprogrambibliotek som råkar fungera var som helst. WebGL är passlig för en ny nisch emellan små, simpla webbspel och stora, invecklade internt kodade spel. Speldesigners bör tänka på om deras projekt passar in i en sådan nisch.