[Gelöst] Speicherleiche bei Texturenerzeugung mit SDL und OpenGL

[cooky451]

Ki schrieb:

Ich habe nur den Datentyp geändert, bei dem ich mich vertippt habe.

Ja.. und ein paar Sternchen gemacht, die die Bedeutung deines Codes völlig verändert haben.

Ki schrieb:

Es liegt mir fern, Trolle zu unterstützen, aber du solltest vielleicht mal darüber nachdenkt, ob man schnelle Code-Beispiele nicht eventuell immer auf das notwendigste reduziert.

Du schreibst also ernsthaft:

void foo()
{
  int *i = new int;
  *i = 5;
  delete i;
}

statt

void foo()
{
  int i = 5;
}

? Super.

Ki schrieb:

Klassen anlegen kann ich selbst, dennoch danke.

Ja, das sehe ich.

[Ki]

Auch wenn es amüsant ist, zu sehen, wie deine Arroganz deine Fähigkeit, Sachverhalte und den beabsichtigten Sinn dahinter korrekt zu reflektieren, trübt:

CLOSED

Deal with it.
Auf weiteren Streit werde ich nur via Mail eingehen.

[dot]

Ki schrieb:

Auch wenn es amüsant ist, zu sehen, wie deine Arroganz deine Fähigkeit, Sachverhalte und den beabsichtigten Sinn dahinter korrekt zu reflektieren, trübt:

Ich würde mir seine Anmerkungen an deiner Stelle zu Herzen nehmen. Er hat dich auf ein Problem mit deinem Code hingewiesen, offenbar mangelt es dir noch an wesentlichen Grundlagen, was C++ angeht. Ich kann dir nur empfehlen, zumindest mal ernsthaft drüber zu reflektieren.

Ki schrieb:

Ich will loadTexture() nutzen, um in der Laufzeit einer Variable, z.B. texture , eine Textur zuzuweisen. Die Textur soll nur im Gültigkeitsbereich dieser Variable existieren.

Und die Lösung dafür, hat cooky451 dir in seinem vorletzten Post geliefert. Du solltest versuchen, ihn zu verstehen.

Der aus dem Westen ... schrieb:

Persönlich würde ich versuchen, das zu vermeiden. Lieber am Anfang versuchen, alles direkt zu initialisieren, einzuladen und zu sortieren, als die Textur dann zu laden, wenn Sie gebraucht wird.

Ja, das kannst du vielleicht bei einem Pong machen. Aber bei nem richtigen Spiel wird man alles mögliche unternehmen, um gerade bei Texturen den Speicherverbrauch unter Kontrolle zu halten. 512MB sind sehr schnell mal voll.

[Ki]

dot schrieb:

Ich würde mir seine Anmerkungen an deiner Stelle zu Herzen nehmen. Er hat dich auf ein Problem mit deinem Code hingewiesen, offenbar mangelt es dir noch an wesentlichen Grundlagen, was C++ angeht. Ich kann dir nur empfehlen, zumindest mal ernsthaft drüber zu reflektieren.

Ich verstehe die Aufregung darüber nicht. Ich habe bei einem simplen Beispiel für das "Löschen" einer Variable, nach dem ich gefragt wurde, den Datentyp wegen Schussligkeit falsch gesetzt. Spätestens beim kompilieren merkt man das doch.

dot schrieb:

Und die Lösung dafür, hat cooky451 dir in seinem vorletzten Post geliefert. Du solltest versuchen, ihn zu verstehen.

Für die Lösung bin ich auch, wie gesagt, sehr dankbar, aber man muss doch nicht immer mit allen Mitteln trollen, erst recht nicht in einem Forum. Mehr als das habe ich nicht kritisiert.

[cooky451]

Um das mal aus meiner Sicht zu schildern, vielleicht hast du dann etwas mehr Verständnis dafür, Ki.
1. Der Eingangspost. Du hast dir scheinbar noch nicht mal die Doku zu jedem Befehl durchgelesen.
2. "Das Löschen", Version 1:

SDL_Surface *s = new SDL_Surface; // Oder so. Ich habe keine Ahnung von SDL, aber das sah noch in Ordnung aus.
s = loadImage("abc.png"); // Okay, hier hast du den Pointer verworfen und gleichzeitig zeigt s jetzt irgendwo in die Pampa.
delete s; // Hier versuchtest du irgendwas zu löschen, wo auch immer "s" gerade hinzeigt.

Der Code ging ja schon mal gar nicht. Sah wie kopiert und überhaupt nicht verstanden aus. Nachdem ich dich dann darauf hingewiesen hatte, kam das Edit auf die jetzige Version. Da dir new und delete weglassen aber wohl als zu auffällig erschien, kam halt extremer Quatsch dabei raus. (Den du auf Nachfrage auch noch rechtfertigen wolltest. oO)

Dann noch Frage:

Ich will loadTexture() nutzen, um in der Laufzeit einer Variable, z.B. texture, eine Textur zuzuweisen. Die Textur soll nur im Gültigkeitsbereich dieser Variable existieren.

Nachdem ich dir dann eine Lösung gezeigt habe, kam:

Klassen anlegen kann ich selbst, dennoch danke.

Super.

[Der aus dem Westen ...]

dot schrieb:

Ja, das kannst du vielleicht bei einem Pong machen. Aber bei nem richtigen Spiel wird man alles mögliche unternehmen, um gerade bei Texturen den Speicherverbrauch unter Kontrolle zu halten. 512MB sind sehr schnell mal voll.

Mag sein, dass ich ein speicherverwöhnter , nichtsahnender Westentaschenprogrammierer bin (an meinem Notebook habe ich 8 GBs, die locker reichen da sollen mir 512 MB mal kommen). Aber ich rede jetzt von den Rohdaten.

Wir entwickeln uns langsam in eine Richtung, in der ein Spiel durchaus komplett in den Arbeitsspeicher geladen werden kann. Gut, vielleicht habe ich in letzter Zeit kein allzu neues Spiel gespielt, aber wenn du 8 oder gar 16 GB an Speicher hast, sollte man in der Lage sein, große Teile des Spiels da rein laden zu können, und da berechne ich die 1-2 GB, die eventuelle Teile des Betriebssystems belegen, mit ein. Wenn ein Spiel 8 GB an Daten fasst und ich verhältnismässig dynamisch programmiere, kann ich dafür sorgen, dass kaum auf die Festplatte zugegriffen werden muss.

Oder noch besser, man teilt das Spiel in mehrere gedankliche Sektionen und lädt für jede Sektion den Pulk an Daten, den man für diese Sektion braucht. 4 GB in den Speicher geladen, und solange man sich in dieser Sektion aufhält, muss nur wegen automatischer Sicherung und eventuelles Logging auf die Festplatte zugegriffen werden.

Die einzige Behinderung, die mir da einfallen würde, wäre die Abwärtskompatibilität zu bereits bestehenden Architekturen - um Speicher über 4 GB nutzen zu können, brauchst du nun mal ein 64-Bit-Betriebssystem. Auf 32-Bit-OSs wäre das Programm nicht lauffähig, da es mit den Adressen nichts anzufangen wüßte. Oder sehe ich das so falsch?

@Ki: Auf mich wirkst du wie ein Troll. cooky451 berichtigt dich, und du reagierst recht arogant.

[dot]

Dir ist wohl nicht klar, dass wir hier von VRAM und nicht vom normalen Arbeitsspeicher reden. Und selbst wenn wir 100GB VRAM hätten, dann würden wir die nicht dafür verschwenden wollen, einfach gedankenlos alle Texturen reinzupacken, sondern lieber die Auflösung der gerade benötigten Texturen verachtfachten oder sowas. Außerdem musst du mal 100GB an Texturen von der Platte zur GPU schaufeln. Bei den Ladezeiten die du dir da schaffst, wird keiner dein Spiel spielen wollen.

[Der aus dem Westen ...]

dot schrieb:

Dir ist wohl nicht klar, dass wir hier von VRAM und nicht vom normalen Arbeitsspeicher reden...

Das war das Stichwort. Ich bin bis jetzt davon ausgegangen, dass man die Sachen auch im Arbeitsspeicher parken kann, bis sie gebraucht werden. Immer von der Festplatte zu laden stelle ich mir langsamer vor, als den Mist beim Bedarf im Arbeitsspeicher zu cachen und von dort zu holen.

[dot]

Der aus dem Westen ... schrieb:

dot schrieb:

Dir ist wohl nicht klar, dass wir hier von VRAM und nicht vom normalen Arbeitsspeicher reden...

Das war das Stichwort. Ich bin bis jetzt davon ausgegangen, dass man die Sachen auch im Arbeitsspeicher parken kann, bis sie gebraucht werden. Immer von der Festplatte zu laden stelle ich mir langsamer vor, als den Mist beim Bedarf im Arbeitsspeicher zu cachen und von dort zu holen.

Gegen cachen im Arbeitsspeicher sagt niemand was, aber wenn du die Textur verwenden willst, dann willst du sie im VRAM haben.

[Der aus dem Westen ...]

dot schrieb:

Gegen cachen im Arbeitsspeicher sagt niemand was, aber wenn du die Textur verwenden willst, dann willst du sie im VRAM haben.

Ja klar, bei der Darstellung. Aber wenn sie gerade nicht genutzt wird, soll man sie dann wieder aus dem VRAM verbannen, ohne eine Kopie im RAM zu haben?

Deswegen meine ich, bei Programm alles in den RAM laden, und von dort aus die Ausgabe berechnen. Wenn man nicht die ganze Zeit von der Festplatte laden muss, beeinflusst das den Spielspaß enorm. Ich weiß nicht, ob du Tony Hawk American Wasteĺand kennst, aber hier frage ich mich, was sich die Programmierer beim Levelwechsel so alles reingepfiffen haben. Von Arbeitsspeicher kann man immer schneller als von der Festplatte laden, bei der der Lesekopf auch erst einmal mechanisch in die richtige Position gebracht werden will.

[dot]

Der aus dem Westen ... schrieb:

Aber wenn sie gerade nicht genutzt wird, soll man sie dann wieder aus dem VRAM verbannen, ohne eine Kopie im RAM zu haben?

Man sollte sie auf jeden Fall aus dem VRAM nehmen, wenn man sie nicht braucht und den Platz braucht. Um nichts andres geht's hier...

[Der aus dem Westen ...]

Ich meinte, es wäre ersichtlich, dass ich den RAM meinte ... na egal, hat sich jedenfalls erledigt.