Luku 10: Testaus ja optimointi. Pelien testaus Testityyppejä Suorituskyvyn analysointi Optimointikikkoja Grafiikkaliukuhihnan optimointi



Samankaltaiset tiedostot
Luku 6: Grafiikka. 2D-grafiikka 3D-liukuhihna Epäsuora valaistus Laskostuminen Mobiililaitteet Sisätilat Ulkotilat

Suorituskyvyn varmistaminen sovelluskehityksen eri vaiheissa Paavo Häkkinen, Presales Teamleader Compuware Finland

ELM GROUP 04. Teemu Laakso Henrik Talarmo

Pelisuunnittelua tulevaisuudessa. Karoliina Korppoo / Colossal Order

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Luento 1 Tietokonejärjestelmän rakenne

Luento 1 Tietokonejärjestelmän rakenne. Järjestelmän eri tasot Laitteiston nopeus

Yhteistyötä sisältämätön peliteoria

Testiraportti Android virtuaalikone vs. natiivikoodi Ville Laine, Delta 23

CUDA. Moniydinohjelmointi Mikko Honkonen

Kontrollilaitteet. Arsenaali

Luento 1 Tietokonejärjestelmän rakenne

Luento 1 Tietokonejärjestelmän rakenne. Järjestelmän eri tasot Laitteiston nopeus

Ohjelmiston toteutussuunnitelma

TK Palvelinympäristö

811312A Tietorakenteet ja algoritmit I Johdanto

Harjoitustyön testaus. Juha Taina

PC-LAITTEEN TESTAAMINEN

Ammatti: Pelisuunnittelija

Videotoisto Nexus 7 tableteilla: Android 4.4 KitKat selvästi edellistä versiota heikompi

Luku 6. Dynaaminen ohjelmointi. 6.1 Funktion muisti

58160 Ohjelmoinnin harjoitustyö

Kontrollipolkujen määrä

Johdanto. Olet rekisteröitynyt cined.eu -esitysalustalle ja käyttäjätilisi onaktivoitu.

18 Komponentit, ulkoasu ja visuaalisuus. Materiaalit CC-BY 4.0 Mikko Lampi

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Toinen harjoitustyö. ASCII-grafiikkaa

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana

Mitä mahdollisuuksia pelillisyys avaa vakavahenkisessä toiminnassa?

Onnistut yrittämässäsi, mutta jokin täysin epäolennainen. vikaan.

Sulautettujen järjestelmien skaala on niin laaja, että on erittäin vaikea antaa yleispätevää kuvausta siitä millainen on sulautettu järjestelmä.

Geogebra -koulutus. Ohjelmistojen pedagoginen hyödyntäminen

Moderneissa grafiikkakorteissa hyödynnetään myös samanlaista toimintamallia

Board Game Lab. 4 Teema. Materiaalit CC-BY 4.0 Mikko Lampi

TK Palvelinympäristö

Harjoitustyö: virtuaalikone

oppimispeli esi- ja alkuopetusikäisten lasten matemaattisten taitojen tukemiseen

ARVO - verkkomateriaalien arviointiin

Venekilpailu! Esteiden väistely ja hahmon ohjaaminen

Seuraavat kysymykset koskevat erilaisia tekijöitä, jotka liittyvät digitaaliseen mediaan ja digitaalisiin laitteisiin kuten pöytätietokoneet,

7.4 Sormenjälkitekniikka

Sudenkuoppia, yllätyksiä, pään vaivaa

Videon tallentaminen Virtual Mapista

Peilaus pisteen ja suoran suhteen Pythonin Turtle moduulilla

Algoritmit 1. Luento 1 Ti Timo Männikkö

Automaattinen regressiotestaus ilman testitapauksia. Pekka Aho, VTT Matias Suarez, F-Secure

PC-LAITTEEN TESTAAMINEN

Palomuurit. Palomuuri. Teoriaa. Pakettitason palomuuri. Sovellustason palomuuri

Algoritmit 1. Luento 3 Ti Timo Männikkö

Tietorakenteet, laskuharjoitus 7, ratkaisuja

Algoritmit 1. Luento 2 Ke Timo Männikkö

finnish BOI 2015, päivä 1. Muistiraja: 256 MB

Käyttöohjeet. Näppäimet. Kello tila. Pelitila

SX OS:n Ominaisuudet

TIE Tietorakenteet ja algoritmit 1. TIE Tietorakenteet ja algoritmit

Pelilabra. Pelilabra on noin minuuttia pitkä, pääasiallisesti nopaton skenaario jossa pelaajat kokevat tyypillisen Oululaisen pelikoulutuksen.

Yhteisöllisen toimintatavan jalkauttaminen!

BEYOND: Two Souls BEYOND Touch Sovellus

MS-C1340 Lineaarialgebra ja

Alkukartoitus Opiskeluvalmiudet

Algoritmit 2. Luento 10 To Timo Männikkö

Luku 4: Peliarkkitehtuuri

Uudelleenkäytön jako kahteen

Väylät. Prosessorin tie ulkomaailmaan Pienissä järjestelmissä vain yksi väylä. Osoite, data ja ohjaussignaalit Prosessori ainoa herra (master)

Ohjeet pelaajien siirtymiseen

Kirjoita oma versio funktioista strcpy ja strcat, jotka saavat parametrinaan kaksi merkkiosoitinta.

Tietorakenteet ja algoritmit - syksy

Vasteaika. Vasteaikaa koskeva ohje ei ole juuri muuttunut Robert B. Millerin vuonna 1968 pitämästä esityksestä:

Galactor and the Codebreakers: - oppimispeli online maailman sudenkuopista

Oppiminen ja oivaltaminen

Testaustyökalut. Luento 11 Antti-Pekka Tuovinen. Faculty of Science Department of Computer Science

Blackjack on korttipeli, jossa pelaajan tavoitteena on voittaa pelinhoitaja.

Algoritmit 2. Luento 9 Ti Timo Männikkö

TIES530 TIES530. Moniprosessorijärjestelmät. Moniprosessorijärjestelmät. Miksi moniprosessorijärjestelmä?

Antitammirobotti. Antti Meriläinen Martin Pärtel 29. toukokuuta 2009

75059 Suuri lajittelusarja

Ohjelmiston testaus ja laatu. Testausmenetelmiä

Tietorakenteet ja algoritmit Johdanto Lauri Malmi / Ari Korhonen

TIETOJEN TUONTI TIETOKANNASTA + PIVOT-TAULUKON JA OLAP-KUUTION TEKO

Jouni Huotari OLAP-ohjetekstit kopioitu Microsoftin ohjatun OLAP-kuution teko-ohjeesta. Esimerkin kuvaus ja OLAP-määritelmä

Testifantomit ja kuvanlaatutestit

Suunnitteluvaihe prosessissa

Ongelma 1: Onko datassa tai informaatiossa päällekkäisyyttä?

ANVIA ONLINE BACKUP ASENNUSOPAS 1(7) ANVIA ONLINE BACKUP ASENNUSOPAS 1.0

Sivuston nopeus. Poista hahmonnuksen estävä JavaScript ja CSS sivun yläosan sisällöstä

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmoinnin peruskurssi Y1

Internetin hyödyt ja vaarat. Miten nettiä käytetään tehokkaasti hyväksi?

Esimerkkejä vaativuusluokista

Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä. Simo Tauriainen

Neuroverkkojen soveltaminen vakuutusdatojen luokitteluun

Tietorakenteet ja algoritmit

OHJ-2710 Peliohjelmointi. Syksy 2012 Timo Kellomäki

Lumejärjestelmä Xen. Reino Miettinen

4 Tehokkuus ja algoritmien suunnittelu

797 E. matematiikka. Martti Heinonen Markus Luoma Leena Mannila Kati Rautakorpi-Salmio Timo Tapiainen Tommi Tikka Timo Urpiola

Jatkuvat satunnaismuuttujat

Sivuston nopeus. Tiivistämällä resursseja gzip- tai deflate-koodilla voit vähentää verkon kautta lähetettävien tavujen määrää.

HAKURATKAISUN ANATOMIA - KURKISTUS PELLIN ALLE

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Transkriptio:

Luku 10: Testaus ja optimointi Pelien testaus Testityyppejä Suorituskyvyn analysointi Optimointikikkoja Grafiikkaliukuhihnan optimointi

Testaus Monet normaalin ohjelmistotuotteen testauksen opeista ovat sellaisenaan hyödyllisiä myös peleissä Bugitietokanta, riskianalyysi, testikattavuus... Harvoin kukaan kuolee tai menettää valtavia summia rahaa, jos peli kaatuu Niinpä useimmat virheet eivät ole yhtä kriittisiä kuin vakavissa sovelluksissa Peleissä on enemmän liikkuvia osia kuin monissa muissa sovelluksissa, joten kaikkea on hankalampi kattaa jäykillä testitapauksilla

Testaus Pelit ovat usein läheisesti tekemisissä raudan kanssa (nykyään erityisesti GPU:t) Varsinkin PC:llä erilaisia rautakonfiguraatioita julmetun paljon kaikkien yhdistelmien testaaminen kaikissa eri pelitilanteissa äärimmäisen työlästä Kaiken tehon irti ottaminen vaatii monimutkaisia ja kummallisia kikkoja, joten bugit ovat usein mystisiä Ei siis ihme, että pelit ovat usein bugisia

Testaus Pelien testauksessa painopistealueet ovat hieman erilaiset kuin perinteisessä ohjelmistotuotannossa Peleissä tyypillisiä testityyppejä (McShaffry): toiminnallisuustestit rasitustestit suorituskykytestit pelattavuustestit käytettävyystestit konfiguraatiotestit

Suorituskyky ja konfiguraatiot Pelit vievät tyypillisesti laitteiston sietokyvyn rajoille, joten kuormitustestit ovat tarpeen Tutkitaan pelin toimintaa kun resurssit ovat vähissä, sekä muissa erikoistilanteissa Tippuuko fps jossain tilanteissa? Millainen CPU/GPU vaaditaan? Paljonko muistia? Entä jos levytila loppuu? Näyttötila vaihtuu kesken pelin? Verkkoyhteys katkeaa? Eri laitteilla (PC, Android) ja softaversioilla yllättävät interaktiot tulostinajureiden jne kanssa

Pelattavuustestit Pelattavuustesteillä on tarkoitus varmistaa, että pelin pelaaminen on (kohdeyleisön mielestä) hauskaa, viihdyttävää, mielenkiintoista tyypillisesti käytetään ulkopuolisia pelaajia, joille peli annetaan ja lopuksi haastatellaan kilpailijoidenkin pelejä voi pelauttaa ihmisillä, jolloin saa ideoita: miten voisi tehdä paremman huijauskoodeilla ja neuvoilla kannattaa yrittää antaa testaajalle kuva pelistä laajemmin, ei vain alusta

Metriikat, A/B-testit Verkossa toimivissa peleissä pelaajien toimista voi kerätä paljon hyödyllistä informaatiota (metriikat) esim. mitä toimintoja ei käytetä, mitä pelaajat tekivät vähän ennen lopettamista A/B-testaus: annetaan osalle käyttäjistä erilainen tuote ja tutkitaan onko tulos parempi vai huonompi esim. käyttöliittymän yksityiskohtien hiominen pitkään käytetty markkinoinnissa Tarvitaanko enää pelisuunnittelua, kun kaiken voi ratkaista metriikoilla?

Käytettävyystestit Käytettävyystestissä testataan, osaako pelaaja toimia pelissä esim. annetaan ulkopuoliselle tehtävä ilman ohjeita ja katsotaan, miten käy toisin kuin pelattavuustesteissä, tekijöiltä ei saa kysyä apua ensimmäistä kertaa pelin näkevän katselu on usein tekijälle silmät avaava kokemus videointi helpottaa analyysiä

Automaattinen testaus Joitakin osia pelien testaamisesta voidaan automatisoida Ei korvaa ihmistestausta Syöte voi tulla pelaajan sijaan testiskriptiltä Koodissa on testejä, jotka varmistavat, että peli on ehjässä tilassa Automaattiset testit voidaan ajaa jokaisen käännöksen jälkeen ja/tai joka yö Hankalaa jos pelin säännöt muuttuvat jatkuvasti, vanha skripti ei ole enää validi

Betatestit Varsinkin verkkopeleissä on yleistä käyttää julkista betatestiä: peli julkistetaan osalle yleisöstä ennen varsinaista julkaisua MMO-peleissä palvelinten kuormitusta on hyvin vaikeaa simuloida realistisesti muuten Yleisö kannattaa valita: hardcore-pelaajia, jotka oikeasti pelaavat riittävästi Testaajat kannattaa palkita, jotta heiltä saisi hyvää palautetta

Optimointi Optimoinnilla tarkoitetaan tässä suorituskyvyn parantamista Esimerkiksi prosessorin, muistin ja väylän käyttö Peruskäyttäjällä ei yleensä ole uusinta grafiikkakorttia; ihmiset yrittävät pelata uusia pelejä hyvinkin vanhoilla koneilla Mitä pienemmät laitevaatimukset, sitä suurempi potentiaalinen asiakaskunta

Optimoinnin tasot Optimoinnin voi jakaa kolmeen tasoon Järjestelmätaso: resurssienkäytön tasapainotus Sovellustaso: kertaluokkiin vaikuttavia muutoksia tietorakenteissa ja algoritmeissa octree, LoD, karsinta,... potentiaalia vaikuttaa ratkaisevasti epätarkkakin ajoajan analyysi voi olla avuksi Mikrotaso: yhden tai muutaman koodirivin tasolla tapahtuvaa suurimmassa osassa koodia turhaa

Analyysi Optimoinnin ensimmäinen vaihe on analyysi: jos ei tiedä, miksi peli on hidas, asialle on vaikea tehdä mitään Kun jossakin prosessissa on monta vaihetta, muodostuu yleensä yksi pullonkaula: minkään muun vaiheen nopeuttaminen ei auta yhtään grafiikassa keskeistä: CPU lähettää datan, kulkee väylässä, etenee kortin liukuhihnaa pitkin Analyysin tavoitteena selvittää, paljonko aikaa ja muistia kuluu mihinkin koodin osaan

Analyysi Täytyy mitata jotain, jotta sitä voisi parantaa hyvä mittari on toistettava, edustava ja käytettävä yleisin mittari peleissä fps epälineaarisuuden vuoksi ms/frame parempi Ajastimilla on helppo saada karkeita arvioita paljonko aikaa kuluu jossakin koodin osassa gettime() tai vastaava, lasketaan erotuksia Vastaavasti tutkimalla vapaan muistin määrää (tai pitämällä kirjaa) voi tutkia muistinkulutusta

Pullonkaulan etsiminen Pullonkaulaa voi etsiä kokeilemalla korvataan prosessin vaiheita yksi kerrallaan yksinkertaistetulla versiolla, esim. prosessori: törmäystarkistuksen ja AI:n poisto väylä: tekstuurien korvaus pienemmillä versioilla pikselien määrä: piirtoikkunan koon pienennys toinen vaihtoehto monimutkaisempi versio (varo kääntäjän optimointeja) Jos peli ei nopeudu, kyseinen vaihe ei luultavasti ole pullonkaula Ongelma: muutokset vaikuttavat muihinkin osiin

Työkalut Profilointityökaluilla voi tutkia tarkemmin, paljonko aikaa ja muistia kuluu koodin osissa voi aiheuttaa overheadia ja vääristymiä 3d-korttien valmistajilla on työkaluja, joilla voi tutkia eri liukuhihnan vaiheiden kuormitusta ym. Laitteiston nopeuden muuttaminen Välimuistihutien laskeminen Työkaluja: VTune, MS PIX, Intel GPA, NSight, gdebugger

Yleisiä optimointikikkoja Ajankäytön jakauma on hyvin vino: suurin osa ajasta kuluu pienessä osassa koodia, joten mikrotason optimointikin kannattaa usein kunhan sen tekee oikeaan paikkaan Tärkeämpää kuin tuntea joukko niksejä on tuntea kohdelaitteisto ja ohjelmistoympäristö prosessorin ja 3d-kortin toiminta (väli)muistiarkkitehtuuri (datan sijoittelu) kääntäjä, käytetyt kirjastot/ohjelmistokehykset

Yleisiä optimointikikkoja Katsotaan kuitenkin joukko niksejä :) usein ristiriidassa selkeyden ja luotettavuuden kanssa, joten ajattele ennen käyttöä! Prosessorinkäyttöä voi usein muuttaa muistinkäytöksi laskemalla arvot valmiiksi klassinen esimerkki trigonometriset funktiot tosin välimuistin tehokkuus huononee Sievennä matemaattiset lausekkeet x/z+y/z (x+y)/z

Yleisiä optimointikikkoja Ota operaatioiden kestot huomioon jakolasku on hidas: x/c (1/c)*x liukulukujen matkiminen kokonaisluvuilla Merkkijonojen vertailu on hidasta Käytä staattisia rakenteita dynaamisten sijaan jos mahdollista, dynaamisissa on overheadia dynaamiset tietotyypit, dynaaminen sitominen jatkuva dynaaminen muistinvaraus/-vapautus taulukko vs. dynaaminen vektori

Yleisiä optimointikikkoja Älä käytä ylimääräisiä bittejä tiedon tallentamiseen jos tiedetään, että arvo on aina 1..100, menee 32- bittinen luku paljolti hukkaan; 8 (tai 7) bittiä riittää mutta joskus 32-bittisiä on nopeampi käsitellä... Muistinkulutusta vähentää resurssien tallennusmuodon oikea valinta äänitiedostoksi voi riittää 11 khz mono 44 khz stereon sijaan, tilankäyttö 1/8 bittikarttojen/tekstuurien bittimäärät per väri pakkaaminen: sekä häviöllinen että häviötön

Yleisiä optimointikikkoja STL:n tietorakenteet muistirohmuja Symmetrian hyödyntäminen: joskus riittää puolet tai vähemmänkin muistista/ajoajasta, jos esim. toinen puoli datasta on sama peilattuna SIMD-arkkitehtuuri: koodin vektorointi Tiedon sijoittelu muistiin (alignment) Pelkkä poikkeusten olemassaolo hidastaa funktiokutsuja

Yleisiä optimointikikkoja Hyödynnä välimuisti: sekä data että käskyt peräkkäin käytetty data peräkkäin Kääntäjä pitää yksittäiset funktiot yleensä muistissa jatkuvana palana ja käännösyksikön funktiot peräkkäisinä, joten: pidä koodi lyhyenä (vähän konekielikäskyjä) sijoita käytetyt funktiot peräkkäin vältä varsinkin ulkopuolisten funktioiden kutsua ristiriita: funktiot lyhentävät koodia - inlining

Resurssivälimuisti Kovalevyltä lataaminen on erityisen hidasta, joten olisi tärkeää, että data mahtuu muistiin Koska tähän ei kuitenkaan päästä, peleihin toteutetaan usein erillinen resurssivälimuisti resursseja ovat esimerkiksi hahmoanimaatiot, kolmioverkot, tekstuurit, kentät, äänet, videot,... pitää kirjaa, mitkä resurssit on ladattuna ja paljonko niitä on käytetty lataa pyydettäessä resursseja levyltä ja heittää tarpeettomimmat pois muistista hallinnoi muistivarastoja, ei jatkuvaa new/deleteä

Pelimaailma ja resurssit Resurssit voi ottaa huomioon jo pelimaailmaa suunniteltaessa yksi kenttä tai sen osa käyttää juuri sen verran muistia kuin laitteessa on ladataanko jatkuvasti vai latauspisteissä segmentit ja puskurivyöhykkeet Halo 1 esimerkillinen Etenkin konsoleilla kätevää, koska voidaan usein optimoida tietylle tunnetulle laitteelle

Datan siirto Eniten väylää kuluttaa yleensä tekstuurien siirto pidetään tekstuurit mahdollisimman pitkään grafiikkakortilla ja vältetään niiden vaihtelua Tekstuuribudjetti: käytetään resurssit siellä missä se näkyy pelaajalle eniten kokeillaan peliä eri kokoisilla versioilla tekstuureista ja katsotaan, onko lisäresoluutiosta näkyvää hyötyä läpinäkyvyys ym. kikat ei kopioita samasta tekstuurista

Datan siirto Verteksien siirto harvoin nykyään ongelma kolmioketjut ja -viuhkat voivat olla jopa hitaampia kuin pelkät kolmiot; riippuu laitteesta verteksien optimointi GPU:n välimuisteja ajatellen tähänkin automaattisia työkaluja API-kutsujen määrän minimointi batching: useita pieniä tehtäviä samaan kutsuun kolmioketjut voi yhdistää degeneroituneilla 3d-mallien instanssit Tilavaihdosten minimointi materiaalin perusteella järjestäminen

Geometria Verteksisävytin nykyään harvoin pullonkaula tosin kuluttaa monilla laitteilla samoja resursseja kuin pikselisävyttimet Jos tehdään useita transformaatioita, kerrotaan matriisit yhteen ennen verteksien kertomista ei siis tehdä verteksisävyttimessä asioita, jotka voidaan tehdä kerran framessa tai kerran per objekti CPU:lla esim. jotkin koordinaatistomuunnokset Valitaan valonlähteet, jotka vaikuttavat objektiin

Rasterointi/pikselisävytin Rasteroinnissa minimoidaan sitä, montako kertaa kukin pikseli piirretään Varmistetaan, että pikselit karsitaan mahdollisimman aikaisessa vaiheessa Hi-z, early z, front-to-back, occlusion query Z-puskuri pois päältä skyboxissa, menuissa ym. Hyödynnä ilmainen interpolointi rasterointi, bilineaarinen suodatus Kaikkia vektoreita ei tarvitse normalisoida Tunne GPU-rauta (esim. vektorointi, pistetulot) Usein molemmat if-haarat suoritetaan jos jokainen pikseli ei ole samaa mieltä

Tekstuurikaista Pullonkaula voi myös GPU:n sisäinen muistikaistanleveys johtuen yleensä lukuisista tekstuurien arvojen hakemisista erityisesti monet efektit ottavat jopa kymmeniä näytteitä pikseliä kohti pienemmät tekstuurit, vähemmän bittejä/pikseli tekstuurien pakkaaminen mipmap vähentää myös kaistan käyttöä prefetching: rauta hakee arvon etukäteen, jos sävyttimen toiminta on ennustettavaa

Mobiiliympäristöt Mobiililaitteilla tehoa suhteellisen vähän GPU:lla yleinen pullonkaula pikseliprosessointi ei screen space -tekniikoita voi kannattaa siirtää kuormaa CPU:lle kaistanleveysongelmat (pakkaa tekstuurit) Myös akun kulutus pitää ottaa huomioon Mobiili-GPU:iden arkkitehtuuri voi olla erilaista esim. ipad2: tile-based deferred Visuaalisuus huijataan: artistit töihin, sisäänleivotut varjot ym., trilight-malli tekstuuriin