spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich habe so kein Fehler gesehen, aber wenn es so geht OK.

Ich würde Referenzen empfehlen. Und eventuell Klassenmember und Funktionsparameter nicht den gleichen Namen geben, das kann beim Code lesen verwirren was jetzt gemeint ist.

Meine spontane Vermutung beim Überfliegen ist, dass Du irgendwo eine Textur erstellst und einem Sprite gibst, dann das Besitzerobjekt kopierst, das Original zerstörst (womit die Textur weg ist) und in irgendeiner Kopie auf die Textur zugreifst, deren Referenz aber in's Nirvana zeigt. Damit machst Du den Stack kaputt und damit auch ganz wichtige interne Speicherstellen und Referenzen. Irgendwann knallt es dann natürlich, wenn darauf zugegriffen wird.
Ich wette, dass das Problem nicht auftreten würde, wenn Du verstanden hättest, was Referenzen sind und wie man sie benutzt. Ganz speziell der Punkt, dass man niemals Referenzen auf lokale Objekte setzt und fröhlich herumreicht und kopiert. Du übernimmst Dich meiner Meinung nach momentan absolut, weil Dir noch wesentliche Grundlagen fehlen. Ganz speziell Referenzen und Pointer.

In der Zwischenzeit kannst Du, damit zumindest die Textur-Kopiererei ein Ende hat (die andere üble Fehler erzeugt), alle sf::Texture-Verwendungen durch diese Klasse ersetzen:
Damit bekommst Du überall vom Compiler wilde Fehler um die Ohren gehauen, wenn Du sf::Texture falsch übergibst. Damit wirst Du also zu Pointern und Referenzen gezwungen, was sich für Dich natürlich erstmal schlimm anhört, weil Dir dazu das Verständnis fehlt. Aber es zwingt Dich auch Dich mit diesem sehr wichtigen Thema zu beschäftigen. Denn nur weil Du keine verwendest, heißt das nicht, dass SFML das auch tut. Im Gegenteil sogar, SFML verwendet für Texturen in Sprites eben Referenzen und Pointer.

Frage nebenbei:
Warum sf::NonCopyable nicht private vererben?

Zitat von »anti-freak«

Warum sf::NonCopyable nicht private vererben?

Weil alles entscheidende um es nicht kopieren zu können eh schon private ist.

Mag sein, aber ein SafeTexture ist semantisch gesehen kein Noncopyable, sondern hat lediglich die Eigenschaften desselbigen. Hier würde sich sowas doch anbieten. Boost schlägt das für ihr noncoypable doch auch vor, oder liege ich da falsch?

Private wäre durchaus legitim. Allerdings gehe ich mit dem ersten Satz nicht mit. Denn sie wäre damit semantisch gesehen natürlich sehr wohl ein Non-Copyable Object

PS:
Bitte unbedingt lesen und die eigenen Probleme entsprechend korrigieren: SFML Einsteiger-Tipps