Vektorer, finne berørte posisjoner

[GeirGrusom]

Det er nok best å lagre det rett i brettet hvis det er hastighet man er ute etter. Litt mer jobb for å oppdatere det, men ikke spesielt vanskelig, og man ender opp med kun én lookup.

[Lycantrophe]

Kommer brettet til å forandre seg under kjøring, da? Ser uansett ut som om vi er enige på denne fronten.

Endret 15. mai 2013 av Lycantrophe

[GeirGrusom]

Kommer brettet til å forandre seg under kjøring, da? Ser uansett ut som om vi er enige på denne fronten.

Ja absolutt. Jeg ville egentlig påpeke at branching generelt er unødvendig i dette tilfellet, og med resultatet som et bitfelt kan man enkelt sjekke naboceller uten å faktisk slå disse opp, samtidig som man har en logisk verdi for oppslag til tegning etc. Absolutt best å lagre dette i brettet. Oppdatering underveis ved endringer er trivielt.

[Lycantrophe]

Den ser jeg. Lurer på om noen, og i så fall hvilke, kompilatorer som klarer å optimalisere bort branchingen.

[Gjest Gjest slettet-ld9eg7s96q]

Det er nok best å lagre det rett i brettet hvis det er hastighet man er ute etter. Litt mer jobb for å oppdatere det, men ikke spesielt vanskelig, og man ender opp med kun én lookup.

 

Jeg må nok revurdere hele strategien for hvordan jeg lagrer og representerer kartet med Lycantrophes innspill, men det er absolutt verdt det. Slik jeg har kodet det nå blir det for arbitrært og rigid (se f.eks på hvordan jeg fastslår hvilken texture jeg skal bruke på de forskjellige flisene i OurMap.cpp). Kommer til å oppdatere tråden med eventuelle løsninger jeg kommer frem. Kjekt med innspill!

 

Jeg har cappet spillet på 60 FPS. Og OurMap::Draw funksjonen kalles av main loopen. Jeg slet med å toppe 60 FPS i spillet helt til jeg introduserte Hardware akselerasjon, jeg tar sikte på å tyne ut ytelse hvor jeg kan hente det, så.

 

https://github.com/failheap/Scrapheap-Starships/blob/master/Windows%20MSVC10/Scrapheap%20Spaceships/OurMap.cpp

 

Kommer brettet til å forandre seg under kjøring, da? Ser uansett ut som om vi er enige på denne fronten.

 

Nei, forutenom at kartet genereres tilfeldig for hver gang jeg initierer OurMap objektet (noe som bare skjer når man laster inn brettet ved starten), forblir brettet statisk.

[Lycantrophe]

OurMap::~OurMap() {
for (int i = 0; i < solids.size(); i++) {
	delete solids[i];
}
}

 

->

 

while(!solids.empty()) delete solid.back(), solid.pop_back();

 

Selv tror jeg at jeg hadde wrappet pekerene i et objekt og latt destructoren ta seg av det hele. Eller brukt std::unique_ptr i C++11 (som effektivt gjør dette).

[zotbar1234]

wallType OurMap::getAdjecentTiles(int tileXPos, int tileYPos) {

 

adjacent

 

Koden til hele spillet kan du se på github:

 

https://github.com/f...pheap-Starships

 

Fra samme fil, i en tilfeldig rekkefølge:

 

* Hvorfor 'ifstream tFile("textures.ifile", ifstream::in);', når 'ifstream tFile("textures.ifile");' gjør nytten?

* using declarations globalt er en uting

* std::vector<boost::shared_ptr<OurSolid>> solids; muligens? Så slipper du å gjøre ting i destructoren

* "while ( !tFile.eof() )" er en kanonisk måte å få VELDIG sære innlesingsfeil. Don't do that (bonus: hvorfor ikke?)

* "for (int y = 0; y < solids.size(); y++)" er en uting, siden du sammenligner signed med unsigned.

* I generateMap() kan definisjonen av temporaryVectorRow flyttes inn i løkken, så slipper du å kalle clear().

* I generateMap() kan for-løkken for spesialtilfellet med i == 0 erstattes med vector::assign()

* Du er veldig glad i sammenligning mellom signed og unsigned. Kanskje gcc sin -Wsign-compare evt. tilsvarende er en god ting?

* På slutten av loadTextures() er tFile.close() overflødig.

* #ifndef __Scrapheap_Starships__OurMap__ er heller ikke bra, da alt som begynner på __ er forbeholdt implementasjonen i alle kontekster.

 

Kanskje gjøre noe med innlesingen i loadTextures også. Det burde ikke være nødvendig å traversere hele kartet for hver linje du henter fra filen.

 

(og jeg burde lære å titte på datoen i trådene)

Endret 28. mai 2013 av zotbar1234

[Gjest Gjest slettet-ld9eg7s96q]

Hei, takk for tips. Setter pris på det samme når tråden ble opprettet Kommer tilbake med synspunkter når jeg får tid til å se mer konkret på koden og implementere forslagene til folk her!