spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Soll das heißen, jedes deiner Tiles hat ein eigenes Bitmap?
Dann ist ja klar, dass du massig Speicher verbrauchst. Verschwendung pur.
sizeof(Klasse) sagt übrigens wenig über den tatsächlichen Speicherverbrauch aus, denn der Konstruktor kann ja mehr Speicher vom Heap anfordern.

Warum sollte ein Leveleditor alles einzeln auf dem Heap anlegen müssen?
Nebenbei, bist du vielleicht zufällig noch im Debug-Modus?

Ich kenne mich mit Qt zu wenig aus für eine weiterführende hilfreiche Antwort, aber für mich sieht das stark so aus, als ob diese Basisklasse dann schuld ist. Vermutlich erledigt sie weitere Allokationen und frisst Speicher. Ich vermute außerdem hier stark, dass schon Vererbung hier fehl am Platz ist und Qt eine effizientere Lösung ermöglicht. Aber mehr dazu weiß ich leider nicht.

Wenn es ruckelt kann es auch an ganz anderen Dingen liegen. Zum Beispiel gibt es sowas wie Cache-Kohärenz, was stark vereinfacht bedeutet, dass es schneller ist, Daten zu verarbeiten, die dicht hintereinander liegen, als welche die über den ganzen Hauptspeicher verstreut sind. Erzeugst du also 10.000 Tiles mit new, musst du die an 10.000 zufälligen Stellen im Speicher suchen. Erstellst du einen Vektor mit 10.000 Tile-Objekten liegt alles schön beieinander und du kannst sie in einem Rutsch abarbeiten. Der Effekt ist derartig stark, dass es z.B. in der Regel schneller ist, ein Element in einem Vektor zu suchen und zu löschen, als in einer Liste (obwohl man beim Löschen aus dem Vektor alle Elemente kopieren muss, bei listen aber nur 2 Zeiger ändern muss - aber da alle Elemente verteilt sind, dauert das Suchen einfach ewig.)

Und anstatt von QGraphicsPixmapItem zu erben, solltest du lieber folgendes tun: Du erstellst ein QGraphicsPixmapItem für jede Grafik die vor kommt genau einmal und speicherst dann im Tile nur einen Zeiger darauf. Im Normalfall werden ja Grafiken bei Tiles sehr häufig wiederverwendet, es könnte also durchaus sein, dass du nur 1/1000 vom Speicher brauchst, wenn du sie einfach referenzierst.

Äh, ein QGraphicsPixmapItem ist doch dafür da, es in einer QGraphicsScene hin und her zu bewegen, auszuwählen etc. Sind deine Tiles beweglich? Wenn nicht, ist das die falsche Lösung.
Falls du Objekte hast, die du vor den Tiles hin- und herbewegen können willst, dann wäre das die richtige Klasse.

Die Tiles würde ich, wenn es eben normale Tiles sind, über den Hintergrund der QGraphicsScene zeichnen (QGraphicsScene::drawBackground(...) ) und intern eine 2D Struktur verwenden, wo nur eine Nummer gespeichert ist. Die Nummer dient als Index in ein internes Tileset, wo dann die Grafiken liegen. Oder so ähnlich.

Zitat

Du erstellst ein QGraphicsPixmapItem für jede Grafik die vor kommt genau einmal und speicherst dann im Tile nur einen Zeiger darauf

Das ist also nicht der richtige Ansatz. Ein QGraphicsPixmapItem ist, wie gesagt, dafür da, es in einer QGraphicsScene herumschieben zu können etc. Das geht weit über das Speichern von Grafiken hinaus. Die Grafiken werden über bloße QPixmaps gespeichert.

Übrigens:

Zitat

QPixmap objects can be passed around by value since the QPixmap class uses implicit data sharing.

Das sollte also nicht das Problem sein. Aber die QGraphicsItems haben schon recht viele Features...

Es gibt noch einen zweiten Grund, warum hier wesentlich mehr Speicher verbraucht wird, als erwartet: irgendwo muessen intern diese 1 Million Allokationen auch verwaltet werden. Je nachdem welche Runtime etc. wird dann bei einer Allokation nicht nur 8 Byte (wenn das wirklich so waere...) sondern doch eher sowas in der Richtung 40-100 Byte benoetigt. Solche kleine Klassen/ Strukturen sollte man daher nicht einzeln anlegen, sondern immer blockweise.

DerKlaus sagt es schon ganz richtig.
Es ist der falsche Weg, jedes Tile zu einem QGraphicsItem zu machen. Über den Background zu zeichnen reicht hier vollkommen!
Möchte man Tiles über den Objekten zeichnen, muss man eben im Foreground zeichnen.