Kalle en funksjon i en annen klasse.

[GeirGrusom]

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

[Lycantrophe]

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

Vennligst ikke ødelegg denne tråden også.

 

Dessuten virker det ikke som et spill.

[LonelyMan]

Om tråden blir ødelagt så er det en tolkning du må selv gjøre, men at en tråd blir ødelagt av å fortelle sannheten har fint lite å gjøre med hva du synes ødelegger tråder eller ikke.

[Lycantrophe]

Det er ikke et snev av sannhet i det du påstår.

[LonelyMan]

Om du ikke vet hva jeg snakker om når jeg skrev det jeg skrev så kan du jo ikke vite.

[Lycantrophe]

Om du ikke mener det du skriver må du jo ikke skrive det.

[LonelyMan]

Jeg har da ikke sagt jeg ikke mener det.

[etse]

Det finnes ingen universell sannhet som sier at objekt-orientert programmering ikke egner seg til spillprogrammering. Jeg vet det alltid har vært folk opp i gjennom som kritiserer OOP, men det er fortsatt blitt veldig populært fordi det er en måte å skrive kode på som mange synes er lettere å forstå.

[LonelyMan]

Det er ikke noen som sier at det ikke egner seg til spillprogrammering, men derimot anbefaler jeg å styre unna objekt orientert om du skal kode et spill som er glatt og raskt. Men det handler ikke utelukkende om hastighet, det handler om å økonomisere ressursene også.

 

Jeg kvoterer meg selv:

 

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

 

Jeg skriver ikke i søvne skjønner du, når jeg skriver noe så mener jeg det, og er ganske bevisst over det

Endret 14. januar 2013 av LonelyMan

[etse]

Det er ikke noen som sier at det ikke egner seg til spillprogrammering, men derimot anbefaler jeg å styre unna objekt orientert om du skal kode et spill som er glatt og raskt. Men det handler ikke utelukkende om hastighet, det handler om å økonomisere ressursene også.

 

Jeg kvoterer meg selv:

 

 

 

Jeg skriver ikke i søvne skjønner du, når jeg skriver noe så mener jeg det, og er ganske bevisst over det

Selvfølgelig vil OOP gi større overhead. Men du skal enten ha en veldig treg maskin, eller et veldig tungt spill før denne overheaden vil føre til en betydelig dårligere framerate.

 

Det er jo bare å se på Unity, en spillmotor hvor nesten alt er OOP. Du kan lage ganske gode spill i denne motoren uten problemer med framerate. Og det største performancesluket der er neppe det faktumet at det er OOP.

 

Som en person som kun nylig har begynt med spillprogrammering (mitt inntrykk i denne tråden), ser jeg ingenting galt i at han bruker OOP til å lage enkle spill. Tror nok heller ikke har vil merke noe til denne overheaden eller ekstra minnebruker dette føre til. Jeg kan i hvertfall ikke si at jeg har opplevd at det har vært noen issue med dagens maskiner.

 

I dette scenarioet mener jeg han egentlig skal bare glemme akkurat de bakdelene som OOP gir, da de ikke er merkbare før han lager veldig store og/eller avanserte spill. Og selv da er det trolig helt andre ting han nok vil tjene mer på å optimalisere enn å skrive om koden så den ikke er objekt-orientert.

[Lycantrophe]

Jeg kvoterer meg selv:

Dette MÅ være en freudian slip.

[LonelyMan]

Et ballspill som benytter kanskje 40 bytes med minne vil ikke være noe problem

 

Du kan jo ta en titt på civilization 5, det er objektorientert og utvidelser skrives i python. Om du finner et spill som er treigere enn civilization så skal du lete iallefall en stund.

 

Det er ikke bare overhead jeg tenker på, ei heller hvor mye minne oop konsumerer, men jeg tenker på hvor effektivt det utnytter maskinen.

Endret 14. januar 2013 av LonelyMan

[LonelyMan]

F.eks en kvalitet OOP gir som man ikke kan styre unna er at strukturer/klasser og objekter generaliserer dataformer og objekter er ofte alignet, dvs om du skal aksessere 4 verdier i 4 forskjellige objekter og hvert objekt er 2048 bytes stort så sløser du 4 linjer med L1 cache bare for å få tak i 4 ints. Dette er problemet med økonomisering, det er som å stable bruskasser i boden din, i halve slottene i kassa har du brusflasker, og i resten ligger det alt mulig rart, verktøy, bananskall, sokker, ølflasker, og fyrstikkesker. Skal du ha tak i en fyrstikkeske i den store kassa, fremtvinger du sløsing med ressurser som treger ned maskinen.

 

Når folk programmerer oop så tenker de primært "Organisering, strukturert, oversiktlig, fint, klart, elegant, lettleselig kode"

 

Datamaskinen tenker helt annerledes enn programmereren, den tenker slik: "Gi meg data, helst lineære data, og samme type data hvert virtuelt objekt representerer for en datatype, og gi meg den i et svært jafs"

 

Nå tenker ikke datamaskinen, men det er slik den oppfører seg og det er slik den trives best i.

 

Jeg kan gi et lettforståelig eksempel. Du har et rom med bruskasser, i hver slot i bruskassa finner du mer eller mindre unike objekter, akkurat som i en klasse. Noen slotter inneholder brusflasker, noen inneholder andre objekter. Så får du som oppgave å gå inn i rommet og hente alle fyrstikkesker som du finner i enkelte av slottene.

 

Så gir jeg deg en annen oppgave, gå i et annet rom og hent alle fyrstikkeskene som ligger på rekke og rad på et bord.

 

Hvilken av disse oppgavene tror du er mest økonomisk og effektiv? Hvor mange sekunder bruker du for hver fyrstikkeske i hver av rommene.

 

oop ødelegger også flyten og i noen tilfeller ødelegger den muligheten for å benytte seg av simd operasjoner.

 

En annen ulempe med objekt orientert spill programmering er at når en arbeider med data så må en ofte arbeide med alle data i et objekt for å unngå å måtte gå tilbake å bearbeide det samme objektet igjen. Å arbeide med alle data i et objekt fører ofte til at man må bruke forskjellige metoder for alle typer data, og det fragmenterer trace cachen på noen prosessorer og andre så fragmenterer det uop cachen. Den delen handler om å økonomisere prosessorens interne ressurser, uop cachen er en veldig fattig ressurs som er utrolig viktig å økonomisere. Derfor favoriserer jeg å arbeide med store mengder med samme type data i et kjør, og så bevege seg videre til å arbeide på en annen veldig stor mengde data av samme type data, for da bruker en mindre antall metoder da man arbeider på samme type data behøver en minimalt med metoder, som igjen økonomiserer uop cachen, som igjen øker hastigheten spillet kjører.

Endret 14. januar 2013 av LonelyMan

[Valkyrex]

Bare for å slenge meg på, med en annen løsningsmetode:

 

Overordnet tenkt: Lag datastrukturen din som en "linked-list-ring".

- En struct som representerer en spiller. Her er den dataen som trengs om spilleren, og en peker til spilleren på venstre side, og den på høyre side. Her kan du da slenge på funksjonene kast til venstre / høyre (eller hva nå enn som er "reglene" i systemet ditt)

- En peker som peker til spilleren som har ballen nå.

 

Med et sånt system så kan du raskt utvide og minske spiller massen din, og enkelt bare henvende deg til "harBallenNaa" pekeren (eller hva nå enn den skal hete) for å si "dinTur". Og hvis du skal finne en spiller er det bare å søke igjennom ringen for å finne den du vil kaste til (for å spare tid her kan du ta en peker som beveger seg til høyre, og en til venstre, slik at du i worst-case kun må traversere halvparten av ringen, kontra worst-case hele ringen ved å kun bevege seg f.eks mot høyre).

 

P.s. Kan jo også sette opp "spiller" datastrukturen som et objekt kontra en struct, men kjappere å teste ut.

 

Eller er jeg helt på bærtur etter hva du var ute etter orginalt?

[GeirGrusom]

Du kan jo ta en titt på civilization 5, det er objektorientert og utvidelser skrives i python. Om du finner et spill som er treigere enn civilization så skal du lete iallefall en stund.

 

Fallacy of the single cause

[Gjest Gjest slettet-ld9eg7s96q]

Ha deg vekk, ditt troll. Er lei av at du kaprer tråder, for å komme med kvalmende selvskryt. Narsissist kaller man sånne som deg.

 

Han kommer jo ikke med selvskryt her, han argumenterer bare for et standpunkt (selv om argumentasjonen er svak), uansett er det vel temmelig likegyldig om OP bruker c++ i dette tilfellet da besparelsen av ressurser uansett er minimal. Eksempelet med Civilization 5 synes jeg forøvrig var fornøyelig. Freeciv er kodet i C, men kartrenderingen med GTK i dette spillet regnes som tregt da grafikkbibliotekene i GTK ikke akkurat er noe lyntog å regne, selv om GTK er programmert i et ikke objektorientert miljø - C.

 

Det finnes C biblioteker for spilleprogrammering btw, f.eks http://alleg.sourceforge.net/ som jeg har brukt litt tid på å sette meg inn i. Sidespor, men tenkte jeg bare skulle nevne det.

[etse]

LonelyMan: De fleste, i hvertfall med litt høyere kompetanse innenfor faget er fullt klar over at abstraksjonen OOP gir går på bekostning av ytelse. Poenget er jo bare at kostnaden er relativt liten i forhold til den totale mengden ytelse du har tilgjengelig at det trolig ikke blir å være et problem. Som oftest vil det være helt andre ting enn det at språket ditt er objekt-orientert som gjør at performance i spillet blir dårlig.

 

Med mindre du jobber opp mot maskiner som har veldig begrensede ressurser (som litt eldre konsoller), eller satser på å lage det neste Crysis så har jeg ingen tro på at OOP vil lage store problemer for deg når det kommer til performance. Er jo bare å se på hvor mange indie-spill som blir laget med XNA. Det er helt klart et objekt-orientert; men jeg kan ikke si at det ser ut til å lage store problemer for utviklere.

[LonelyMan]

Er jo bare å se på hvor mange indie-spill som blir laget med XNA. Det er helt klart et objekt-orientert; men jeg kan ikke si at det ser ut til å lage store problemer for utviklere.

 

OOP fungerer, og det yter bra, det er ikke slik at ting stopper opp om du bruker oop, men ytelsen er relativt nedsatt. Spill som type first person shooter er mer grafisk intensiv enn det er cpu intensiv. Spill som er potensielt slitende er nesten utelukkende strategispill, for de fleste strategispill er cpu intensiv. Spill utviklere leverer spill som klarer å kjøre på den generelle datamaskin, det er de nødt til å gjøre, men som jeg sa og som du også nevner så er oop ikke optimalt.

Endret 15. januar 2013 av LonelyMan

[LonelyMan]

Han kommer jo ikke med selvskryt her

 

Stemmer, godt at noen har fornuften i orden.

 

Fallacy of the single cause

 

Det er ikke en single cause, det er et single example. Huge difference.

[etse]

OOP fungerer, og det yter bra, det er ikke slik at ting stopper opp om du bruker oop, men ytelsen er relativt nedsatt. Spill som type first person shooter er mer grafisk intensiv enn det er cpu intensiv. Spill som er potensielt slitende er nesten utelukkende strategispill, for de fleste strategispill er cpu intensiv. Spill utviklere leverer spill som klarer å kjøre på den generelle datamaskin, det er de nødt til å gjøre, men som jeg sa og som du også nevner så er oop ikke optimalt.

Du har selvfølgelig rett i dette. Men mener fortsatt ikke dette er god nok grunn til å styre vekk fra objektorienterte språk når man skal programmere spill. I hvertfall ikke på indie-nivå.

 

Om man ønsker mye ytelse er min mening at C++ leverer mer enn nok i nesten alle tilfeller. Og i hvertfall nok i alle tilfeller jeg ser for meg TS kommer til å være på i nærmeste fremtid.

 

Man må ikke være redd for å noen ganger ta i bruk suboptimale løsninger og det gjør prosessen lettere for deg selv. Personlig er jeg veldig fan av å skrive objekt-orientert kode - da jeg føler det er lettere å arbeide på dette abstraksjonsnivået. Men jeg også fullt klar over at OOP både gir performance loss, samt at det er lett å få litt rotete kode med OOP om man ikke er forsiktig.

 

Det er ikke en single cause, det er et single example. Huge difference.

Men du hintet jo til at CIV5 var tregt fordi det var laget i et objekt-orientert språk. Mens i realtiteten er det nok mange flere årsaker (og andre årsaker som nok har mye mer å si på hvorfor det spillet er tregt)

Endret 15. januar 2013 av etse