C# XNA - Ska man endast ha kod som ritar i Draw()?

Permalänk
Medlem

C# XNA - Ska man endast ha kod som ritar i Draw()?

Jag håller på att göra ett Blackjack spel och är lite förvirrad när det kommer till var jag bör placera min kod. Ska jag endast placera sådant som har att göra med att rita upp saker på skärmen i Draw() metoden i Game1 klassen?

Just nu har gör jag allt i Draw() metoden, jag kollar om spelaren klickar på knappar, jag kallar metoder som drar kort åt spelaren, jag modifierar spelarens pengar beroende på vad resultatet av spelrundan blev etc, allt i Draw() metoden och det funkar perfekt att spela spelet utan felmeddelanden.

Är det något fel med att göra allt i Draw() metoden?

Permalänk
Inaktiv

Logik ska göras i Update metoden. I Draw() ska endast grafikrelaterat vara.

Permalänk
Medlem

Jag tycker du borde köpa en bok i spelprogrammering, finns till XNA, så du kan lära dej det lite bättre.

Kortfattat, kör inte allt i draw metoden, det kommer medföra problem för dej längre fram.

Kortfattat så finns det tre delar (utöver laddning och sådant):
1) Input. Här läser du alla tangentnedtryckningar, var musen är och liknande. Och lagrar all data, inte processerar något.
2) Update. Här kollar du inmatningarna från 1, och uppdaterar efter det. Samt alla övriga uppdateringar, kortutdelning, förflyttning, ai osv.
3) Draw. Här tar du endast upp det grafiska som ritas på skärmen. DVS. ritar de kort osv. som ska visas på skärmen.

Sedan finns det många fler sätt att förbättra allting.
Synkronisering och liknande. Ex. input och update måste inte alltid köras på max fsp, utan på en 25 fps.
Att rita allting, behövs kanske heller inte ske allt för ofta. Ex. kör spelet på 150 fps, så skulle det räcka att klocka ned uppdateringen till 60 fps.

Det finns fall där det är bra att klocka ned spelets olika delar, och fall där det är bättre att låta det härja fritt. Men det tas upp i spelprogrammeringsböcker, som du bör läsa själv. Det är mycket teori.

Permalänk
Medlem

Eftersom att jag använder olika switch statements med massa olika case för att hålla koll på vad som ska ritas upp och vilken logik som är aktuell så måste jag skriva alla olika switch statements och case i Update() också om jag separerar det och då blir koden nästan dubbelt så lång.

Det blir mycket finare att lägga allt i Draw(), jag har läst att logik ska vara i Update() och skulle gått efter det om det inte blev så mycket snyggare och dessutom funkade perfekt att lägga det i Draw().

Men jag separerar koden nu ändå, även om jag inte riktigt förstår vilka de negativa konsekvenserna av att ha allt i Draw() är.

Permalänk
Medlem

Varför du ska dela upp koden är för att Update() prioriteras framför Draw() om det börjar gå tungt för den, eftersom logiken alltid ska köras även om den inte hinner rita upp allting.

Permalänk
Medlem
Skrivet av Skogga:

Varför du ska dela upp koden är för att Update() prioriteras framför Draw() om det börjar gå tungt för den, eftersom logiken alltid ska köras även om den inte hinner rita upp allting.

ok, tack.

Permalänk
Inaktiv

Om switchen är till för att visa olika "states" av spelet, dvs. huvudmeny etc. så tänker du fel. Du borde istället använda dig av sk. Gamestates. Finns lite olika tutorials för XNA om det om du googlar.

Permalänk
Medlem
Skrivet av anon150287:

Om switchen är till för att visa olika "states" av spelet, dvs. huvudmeny etc. så tänker du fel. Du borde istället använda dig av sk. Gamestates. Finns lite olika tutorials för XNA om det om du googlar.

Använder en enum (vid namn GameState) som innehåller alla olika "states". Switchen har ett case för varje state i enumen.