Kalle en funksjon i en annen klasse.

[LonelyMan]

Jeg fraråder ikke å bruke oop for generelle programmer og små til medium store spill, 3d first person shooter spill er også veldig lite cpu intensive så der går oop også an å bruke, men som sagt anbefaler jeg å styre unna det i cpu intensive spill, som jeg også nevnte så er et lite ballspill ikke noe problem.

 

Ang. Civ5, alle spill har flere årsaker til hvorfor det kjører tregt, det er ikke et eneste spill i verden hvor èn årsak bidrar til nedsatt hastighet, i absolutt alle spill og programmer så gjelder alle faktorer, noen mer enn andre, men alle gjelder likevel i sum. Når det gjelder Civ5 så er det selvfølgelig en kombinasjon av mange dårlige ting, det ene er sterk oop programmering, uhorvelig mange unødvendige oop oppdelinger, altfor mange metoder, mye brukt python for oppgaver som er veldig tidkrevende, AI i civ5 er ekstremt cpu intensiv. Nå bruker civ5 lua og python, python kan være enda en årsak til hastighetsdropp da python programmering er langt ifra optimalt å bruke. Om du har 30 ai konkurrenter så skal du kalkulere AI, pathfinding, økonomi, strategi, diplomati, grafiske objekter, posisjoner, nummerere hver eneste unit i spillet for lokal taktikk (noe som kan ta veldig lang tid) spillet er veldig cpu intensiv, og da er det desto viktigere å ha en god overall optimalisering for det er så mange biter som henger sammen i spillet. Vanligvis så er det nok å optimalisere deler av et spill, men spill som typen civ 5 så er overall optimalisering viktigere for alle delene lider mer eller mindre like mye. Noen områder gir bedre optimalisering enn andre og kan gi økt hastighet, men slike spill som civ5 som er så utrolig fragmentert (metodevis) så er overall optimalisering viktig. Når du summerer metodebruken i spillet så blir det som å gå gjennom en pakke med smør, motstand hele veien.

Endret 16. januar 2013 av LonelyMan

[GeirGrusom]

Jeg fraråder ikke å bruke oop for generelle programmer og små til medium store spill, 3d first person shooter spill er også veldig lite cpu intensive så der går oop også an å bruke, men som sagt anbefaler jeg å styre unna det i cpu intensive spill, som jeg også nevnte så er et lite ballspill ikke noe problem.

 

Ang. Civ5, alle spill har flere årsaker til hvorfor det kjører tregt, det er ikke et eneste spill i verden hvor èn årsak bidrar til nedsatt hastighet, i absolutt alle spill og programmer så gjelder alle faktorer, noen mer enn andre, men alle gjelder likevel i sum. Når det gjelder Civ5 så er det selvfølgelig en kombinasjon av mange dårlige ting, det ene er sterk oop programmering, uhorvelig mange unødvendige oop oppdelinger, altfor mange metoder, mye brukt python for oppgaver som er veldig tidkrevende, AI i civ5 er ekstremt cpu intensiv. Nå bruker civ5 lua og python, python kan være enda en årsak til hastighetsdropp da python programmering er langt ifra optimalt å bruke. Om du har 30 ai konkurrenter så skal du kalkulere AI, pathfinding, økonomi, strategi, diplomati, grafiske objekter, posisjoner, nummerere hver eneste unit i spillet for lokal taktikk (noe som kan ta veldig lang tid) spillet er veldig cpu intensiv, og da er det desto viktigere å ha en god overall optimalisering for det er så mange biter som henger sammen i spillet. Vanligvis så er det nok å optimalisere deler av et spill, men spill som typen civ 5 så er overall optimalisering viktigere for alle delene lider mer eller mindre like mye. Noen områder gir bedre optimalisering enn andre og kan gi økt hastighet, men slike spill som civ5 som er så utrolig fragmentert (metodevis) så er overall optimalisering viktig. Når du summerer metodebruken i spillet så blir det som å gå gjennom en pakke med smør, motstand hele veien.

Hvis noe går for tregt burde du starte med å analysere algoritmene dine, og implementasjonen av disse. Det er som regel der man har mest å hente.

[LonelyMan]

Det er ikke snakk om optimalisering, som i bedre algoritme, men hvorfor oop degraderer ytelsen, ren skadekontroll. Minimalisere skade, ikke optimalisere kode, for du optimaliserer ikke noe som er skadet, det kalles å rette noe som var i en god tilstand til å begynne med, men som du ødela ved uforsiktig programmering.

 

Om du koder noe og får X ytelse. Og du gjør noe dumt som gjør at du får X-5 i ytelse, og du så gjør noe for å rette opp feilen igjen slik at du får X ytelse igjen, så er dette skadekontroll, ikke optimalisering. For X-5 X+5 = X. (0 i gevinst)

 

Jeg skjønner hva du mener, de fleste er enige med deg, men jeg er ikke helt enig der. Jeg mener at et seriøst planlagt program, med excellent layout, excellent planlegging, excellent koding kan utkonkurrere en bedre algoritme. Spesielt om vi snakker om assembler, så kan man implementere hva jeg kaller "hardware-algoritmer" det er typer algoritmer som er umulig å implementere i andre språk, dvs du benytter en algoritme som ikke er pseudo i software, men du benytter deler av maskinvaren som del av algoritmen.

 

Et eksempel på at bedre koding utkonkurrerer en bedre algoritme er quicksort. Den vanlige quicksort varianten har sine egne fordeler, men så har du dual pivot quicksort som er enda raskere enn quicksort. Etter det har du qs1/qs2 som er enda raskere enn dual pivot quicksort.

 

Min standard iterative quicksort utkonkurrerer qs1/qs2 og kjører 5 ganger raskere hvor jeg bruker den dårligste algoritmen og motparten benytter den beste algoritmen ut av 3 forskjellige varianter.

 

Men ikke ta meg feil, det bør kombineres med en bedre algoritme (i tillegg) for å få det beste ut av det. Så vil jeg også nevne at i enkelte tilfeller er det så stor forskjell i ytelse mellom to algoritmer, at det du sier er sant. Nå er jeg heldig som ikke behøver å velge eller å kompromisse, jeg velger begge deler, god implementering og god algoritme når det passer, og en god implementering krever at en god algoritme først er på plass så jeg leter alltid etter en god algoritme før jeg begynner å kode.

Endret 16. januar 2013 av LonelyMan

[Gjest Gjest slettet-ld9eg7s96q]

Jeg fraråder ikke å bruke oop for generelle programmer og små til medium store spill, 3d first person shooter spill er også veldig lite cpu intensive så der går oop også an å bruke, men som sagt anbefaler jeg å styre unna det i cpu intensive spill, som jeg også nevnte så er et lite ballspill ikke noe problem.

 

Med baller som kastes kan det høres ut som et spill, da anbefaler jeg å styre unna klasser og objekter helt og fullstendig.

 

[GeirGrusom]

Min standard iterative quicksort utkonkurrerer qs1/qs2 og kjører 5 ganger raskere hvor jeg bruker den dårligste algoritmen og motparten benytter den beste algoritmen ut av 3 forskjellige varianter.

 

Dette er veldig spillspesifikt, men jeg synes fokuseringen på at algoritmer skal gå så fort som mulig er på en måte feil. Ikke at det er en uting at de går kjapt, men bortimot all spillmekanikk er ikke tidskritiske prosesser. Path-finding trenger ikke bli ferdig i løpet av millisekunder, ei heller AI. Den eneste reelle tidskritiske prosessen i et spill er rendering og input, og rendering er i stor grad tatt over av GPU-en, og Input må bare ha lav latency men krever lite prosessering.

 

Når man faktisk er klar over dette er det ikke noe problem å få et spill til å gå flytende i et hvilket som helst programmeringsspråk. En må bare kjenne til kravene en bruker setter til opplevelsen, og disse er langt ifra så høye som dine krav til algoritmer. Ved å benytte et programmeringsspråk på et høyere nivå, kan man fokusere mer på å lage en fornuftig algoritmer fremfor å fokusere på at funksjonskall skal gå så forbanna raskt.

 

Det er selvsagt en middelvei her, men fra mitt syn burde man ikke fokusere for mye på dyptgående konsepter fordi de er ikke kritiske til spillopplevelsen og man bruker tiden på noe helt annet enn å faktisk utvikle god spillmekanikk.

[LonelyMan]

Det avhenger fullstendig hva slags spill det er snakk om, er det et turn based spill, ja da vil pathfinding måtte kalkuleres ferdig med en gang, er det et real time strategi spill da behøver man ikke kalkulere det ferdig med en gang, men glem likevel ikke at om du deler opp kalkuleringer i biter så opptar det cpu tid og en del av ressursene som kunne vært brukt til noe annet opptar likevel cpu tid i det intervallet det kjøres, det er ikke slik at cpu tid spares, den blir opptatt likevel og jeg mener det er viktig at den er rask, jo raskere den er jo mer ressurser frigjort for andre ting å kjøre som gjør at andre deler kjører saktere.

 

Når jeg snakker om oop så mener jeg ikke funksjonskall 'skal gå så forbanna raskt', det jeg mener er at hele spillet bør gå 'forbanna raskt', og en del av å få det til er å økonomisere ressursene. Det er utrolig hva vi mennesker kan venne oss til, vi spiller noe og opplever det med full flyt, mens i realitetene har vi vent oss til de delene som ikke flyter så godt. Faktumet er at noen ganger venter vi sekunder på at noe skal skje, men i de sekundene vi venter er vi kanskje tolmodige nok fordi visse forutsetninger gjør at vi tillater oss å ta midlertidige pauser i spillet. Man vet ikke hva god flyt er og god respons er før man går fra bra til meget bra. Vi venner oss til det som er bra, og om en opplever den luksusen av å ha ting meget bra, så vil en skjeldent gå tilbake igjen, god ytelse ser ikke ut til å være viktig, men om en har det så gjør det en spiller lykkelig. Det gjelder ikke bare i spill. Jeg har laget en del programmer og har fått tilbakemeldinger på dette at de ikke visste hvor mye de satte pris på ytelse før de hadde sett noe som yter bedre. Dette er noe jeg er helt sikker på, jeg vet at folk venner seg til noe som er bra, men de vet ikke hva de liker og ikke liker før de prøver noe som yter veldig mye bedre.

 

Det er sant at first person shooters spill at rendering er den eneste tidskritiske prosessen, men i strategispill, spesielt turn based strategispill hvor du venter sekunder for at du får din tur igjen, så er ikke rendering den tidskritiske prosessen. Renderering er forutsetningen for at spill skal fungere, man vet at den har sine begrensninger, og om du bumper borti en del av spillet som krever mer av cpu så vil du oppleve frame drop fordi spillet ikke klarer å levere nok ferdig kalkulert data, og denne framedropen oppleves i stort sett alle spill, den kritiske delen er ganske tydelig der.

 

cpu skal gjøre ganske mange ting samtidig, om du ikke tar det seriøst, du legger inn noe medium bra i en del, så opptar det cpu tid og mindre er tilgjengelig for andre deler, og det senker hastighet for andre deler av spillet. DirectSound f.eks, hvor lyd samples i software, det skal også kjøre i cpu. Det er mange ting som skal kjøre samtidig.

 

Om du skal opprettholde 75 fps i et spill så har du 13 millisekunder å gjøre ferdig ting per frame. Det er veldig lett å overstige denne begrensningen. Økonomiserer man ikke ressursene så må maskinen slite med å gjenopprette forutsetningene for full flyt igjen og da kan man oppleve framedrops (noe som alle spill gir, alle spill har framedrops og det er en grunn til at alle spill har framedrop, det er ikke tilfeldig)

Endret 17. januar 2013 av LonelyMan

[GeirGrusom]

Om du skal opprettholde 75 fps i et spill så har du 13 millisekunder å gjøre ferdig ting per frame. Det er veldig lett å overstige denne begrensningen. Økonomiserer man ikke ressursene så må maskinen slite med å gjenopprette forutsetningene for full flyt igjen og da kan man oppleve framedrops (noe som alle spill gir, alle spill har framedrops og det er en grunn til at alle spill har framedrop, det er ikke tilfeldig)

Den éneste prosessen som ikke kan overskride 13 ms er rendering. Alle andre prosesser kan deferres. Selv i et turbasert spill. Det er ikke noe problem å få rendering til å ta mindre enn 13 ms. Som regel går det av erfaring langt under dette også, selv i C# som er det jeg benytter.

 

Framedrops kommer av at spillet vil kreve ulik prosessering for hver frame. Det kommer helt an på hva som befinner seg innenfor viewport frustum ettersom alle fornuftige implementasjoner bruker både rompartisjonering, viewfrustum culling og occlusion queries for å ikke bruke CPU/GPU-tid på ting som ikke synes. Ettersom logikken foregår i en egen prosess, så vil ikke dette påvirke frameraten, og logikken er ikke tidskritisk.

[LonelyMan]

Den éneste prosessen som ikke kan overskride 13 ms er rendering. Alle andre prosesser kan deferres.

 

Om du bruker programmer for å måle grafikk ytelse så vil du i nesten alle tester se at en sterkere cpu gir grafikkkortet sterkere frame rates, og det har en sammenheng.

 

"Den eneste prosessen" ja, men ingenting vil skje der om ikke cpu gir ordre om det, og den gir kun ordre når noe er ferdig produsert, man kan ikke gi halvbearbeidede data, man må rotere data, man må kalkulere fragmenter i eksplosjoner, selv om det er noe som heter uorden mellom frameratene så må det likevel eksistere en viss form for orden i uordenen også før man rendererer, og det er her tiden tas opp, i tillegg så kommer jo spillets dynamikk også på toppen.

 

Selv i et turbasert spill. Det er ikke noe problem å få rendering til å ta mindre enn 13 ms. Som regel går det av erfaring langt under dette også, selv i C# som er det jeg benytter.

 

Ja jeg sier ikke at det ikke er noe problem, dagens spillutviklere lærer seg hvor begrensningene er, men sier ingenting om hvorfor de har havnet på disse begrensningene. De fleste spill har en terskel de ikke kan overstige, maks antall objekter, maks antall personer eller karakterer samtidig, maks intensitet/kvalitet i pathfinding osv osv. Men dette gjelder som regel i spill hvor du lever i en 3d verden, first person shooters. Men i strategispill er det ikke noe standard performance, for der er det antall units og hvor langt ute i spillet du er som bestemmer ytelsen, der er det ingen mal for performance, og som jeg sa er det i disse typer spill man mest får se effekten av ytelsestap.

 

Framedrops kommer av at spillet vil kreve ulik prosessering for hver frame. Det kommer helt an på hva som befinner seg innenfor viewport frustum ettersom alle fornuftige implementasjoner bruker både rompartisjonering, viewfrustum culling og occlusion queries for å ikke bruke CPU/GPU-tid på ting som ikke synes. Ettersom logikken foregår i en egen prosess, så vil ikke dette påvirke frameraten, og logikken er ikke tidskritisk.

 

Grafikkkortet får sine egne oppgaver og kan utføre disse parallelt, det er sant, men de får ikke oppgaver om ikke cpu er klar for å gi den oppgaver. Om du har flere prosesser eller tråder spiller ingen rolle, flyten du opplever er bare rendering av identiske framer så du oppfatter ikke med øyet at cpu fremdeles arbeider på noe annet, lett å bli lurt her. Direct3D software layeret krever også mye mer av cpu om du bruker depth stencil og z buffer. Det er mange ting en cpu skal gjøre

 

Om man følger visse forhåndsregler, så kan man sikkert doble eller firedoble antall objekter i en virtuell verden, bare fordi utviklerne har senket detaljene i spillet så mye at spillet fungerer betyr ikke at det jeg sier om økonomisering ikke gjelder (faktisk betyr det det motsatte), det betyr bare at de har funnet et nivå hvor ting likevel fungerer for dem. At ting fungerer er ikke en pekepinn på at flere tekniske ting ikke gjelder. Jeg vet at de gjelder og jeg vet at det er vanskelig å være våken på de.

Endret 18. januar 2013 av LonelyMan