JLI Spieleprogrammierung

[manu]

Hi, ich feile am Mapeditor eines 2d spiels.. Bis jetzt arbeite ich so, dass die ganze Karte in einem Array liegt und dann vom Benutzer die entsprechenden Tiles ausgewählt und bearbeitet werden können.

Eine Karte ist beliebig groß und die Größe dynamisch veränderbar, die einzige Grenze ist jetzt halt der Ram..

scroll ich im editor weiter und weiter.. hab ich z.B. bei einer Kartengröße von 800x800 ca.. 250MB ramauslastung.. ich mein die Karten werden wohl nie so groß. aber auch 60MB bei 200x200 sind schon irgendwie viel.


Jetzt wollt ich mal fragen wie ihr des angehen würdet.. also wie ich die Karte performanter verwalten kann.. Sollte ich immer nur einen kleinen Bereich in einem nicht dynamischen array geladen haben und den rest beim wegscrollen usw. gleich in die Mapdatei schreiben und bei weidergebrauch wieder auslesen.. Das wäre schon machbar, ich müsste halt einiges umstellen. Würde das was bringen?

mein Maparray sieht intern übrigens so aus:

[GreveN]

Im Prinzip schon, 800x800 sind ja immerhin satte 640.000 Tiles, je nach Größe der Tilestruktur kommt da schon einiges zusammen. Ich würde das System so umstellen, dass du keine kompletten Maps mehr verwaltest, sondern diese in viele kleinere "Maps" aufteilst. Da müsstest du dann eine vernünftige Größe ermitteln, vielleicht so, dass eine der kleineren Maps reichlich einen Bildschirm ausfüllt. Deine "große" Map teilst du nun entsprechend auf und musst eben deine Verwaltung so umstellen, dass du immer nur eine handvoll von den Kleineren im Speicher hälst. Man könnte das z.B. so machen, dass man ein 3x3 Array von diesen anlegt und der aktuelle Bildausschnitt ist ca. über die Mittlere gescrollt (2, 2). Scrollt man nun z.B. nach links und rutscht Quasi auf die Map (1, 2), löscht man die komplette rechte Spalte, verschiebt die verbleibenden beiden jeweils eins nach rechts (natürlich nicht mit memcpy, sondern einfach nur ein paar Zeiger umbiegen) und läd links parallel eine neue Spalte von der Festplatte. Idealerweise könntest du das in einem Thread machen. Das Problem wird eben sein, rauszukriegen, wie groß man diese kleinen Maps am besten dimensioniert. Wenn du sie zu klein machst, musst du dauernd nachladen, wenn du sie zu groß machst, dauert das Laden ansich wahrscheinlich zu lang. Man könnte das ganze natürlich auch etwas feiner skalieren und sagt eben, man hält sich nicht 3x3 Maps im Speicher, sondern vielleicht 10x10 oder so... Müsste man alles mal ausprobieren, ich kann dir da keine Erfahrungswerte mitteilen, aber würde mich auch mal interessieren... Der Vorteil von dem System ist, dass man sich quasi unendlich große Maps erschaffen und die Ladevorgänge unbemerkt im Hintergrund erledigen kann.

Naja, wenn das jetzt nicht so ganz klar geworden ist, kann ich auch nochmal ein paar Skizzen machen.

[KI]

Wie ist bei dir sTile definiert? Vielleicht kann man da was optimieren.

[GreveN]

Sicher, wenn du es auf 60MB bei 40.000 (200x200) Tiles bringst, dann umfasst ein Tile ja ~1,5KB. Das erscheint mir in der Tat auch recht viel, selbst wenn man da Platz im RAM für andern Kram wie Texturen mit berücksichtig. Ein Tile dürfte doch schlimmsten Falls kaum 50 Byte groß sein.

[manu]

also die zahlenwerte waren nur grob überschlagen..

grundsätzlich speichere ich keine texturen in der map, sondern nur identifier anhand derer ich sie aus dem grafikverwaltungssystem geliefert bekomme.. beim zeichnen der map.

[GreveN]

Die Strukur belegt zumindest bei mir genau 40 Byte (4 Byte Alignment), könnte man noch komprimieren, ist aber auch nicht weltbewegend gigantisch. Dazu kommen noch die eigentlichen Stringdaten (wobei wstring für IDs ungünstig gewählt ist), die aber vernachlässigbar gering ausfallen sollten.

Was hälst du denn noch so im Speicher? Hast du eventuell irgendwo mit new und delete geschlampt und erzeugst non-stop irgendwelche dicken Objekte?

[Fallen]

Wäre es nicht effektiver da etwas mehr aufzuteilen je nach nutzen? ala

[GreveN]

Naja, ich find die Lösung so oder so etwas eigenwillig, da ich die verschiedenen Aspekte wie grafische Darstellung, Kollisionserkennung, Spiellogik usw. sowieso eher trennen würde. Eine Klasse, eine Aufgabe. Vererbungshierarchien sind in dem Fall sicher auch nicht das Mittel der Wahl, da Vererbung im Prinzip performancetechnisch zwar nicht dramatisch kritisch, aber bei der Menge an Tiles und damit verbundener Operationen doch eventuell bedenklich ist. Außerdem macht das Aufteilen des Tileverhaltens in verschiedene Kindklassen spätestens dann Probleme, wenn man Tiles mit mehreren Eigenschaften braucht, da würde ich eine andere Lösung vorziehen, frag mich jetzt nicht welche, ich würde wahrscheinlich versuchen, dass irgendwie über Komposition hinzubiegen, hab mir da aber jetzt keine Gedanken gemacht.

Toll ist die Struktur in dieser Form sicher nicht, aber wenn abzusehen ist, dass man später niemals auf den Gedanken kommen wird zusätzliche Features usw. hinzuzufügen, sicher im Groben erstmal akzeptabel.

Aber...:

[manu]

ich werd jetzt schon bei den wstrings bleiben, sonst müsst ich grad alles umstellen.. auch die schnittstellen der anderen Klassen.

ich werd aber mal versuchen ein paar vorschläge bzgl. der verwaltung umzusetzten..

frage 2: ich hab eine speicherleckverursachende Funktion, weiss aber nicht das Problem zu lösen, die wird in jedem gameloopdurchlauf aufgerufen und frisst den speicher voller und voller.

[Deviloper]

[Hazel]

[fast hawk]

Hi
Ich würde dir empfehlen nicht für jedes Tile in der Map eine eigene Klasse anzulegen sonder eine eigene list oder ein vector..Wo du dann jewals deine Tiles angibt weil es unterscheidet sich nicht jedes Tile in der Map und in dem "MapTile" ist dann nurnoch die für jedes tile individuellen Variablen und ein Zeiger auf das Tile Element in der list(bzw. vecotr).

[manu]

Hey, danke für die vielen Antworten, wenn ich mal wieder en ruhiges Wochenende hab werd ich mal versuchen das ganze System entsprechend
umzubauen.

[Fallen]

Ich glaube Hazel meinte nicht f(x) sondern f(xpos,ypos).
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[Deviloper]

@manu: Ja stimmt std::basic_ostringstream muss spezifiziert werden ... sorry ... ich tipps nur hier ins Eingabe Feld ... da kann schon mal was schief gehen Allerdings kannst du schon einen Default-Type für Templates angeben ... aber nur bei class/struct ... ebenfalls sorry ... war wohl etwas durchn wind