[C++] [SFML] White-Square-Problem mit Listen

Frischling

Wohnort: Solingen

16.12.2013, 19:17

[C++] [SFML] White-Square-Problem mit Listen

Schönen guten Abend,

Im Konstruktor der Game-Klasse werden 2 Player erstellt. Im Konstuktor der Player-Objekte wird jeweils ein Sprite- und einTexture-Objekt erstellt und miteinander verbunden. Die beiden Player werden in eine Liste geschoben.
Nun fliegen im laufenden Spiel nur 2 weiße Quadrate umher, die Textur ist irgendwie verloren gegangen.

Wenn ich die beiden Player als Membervariablen von CGame installiere, also Klassenglobal, dann klappt es. Ich will die Player aber erst zur Laufzeit erstellen, weil ich theoretisch unendlich viele Player erstellen will.

Wo liegt da das Problem?

C-/C++-Quelltext

CGame::CGame()
: _timePerFrame(sf::seconds(1.f/60.f))
, _window(sf::VideoMode(1200, 750), "testgame", sf::Style::Close)
{
    CPlayer _player(_window);
    CPlayer _player2(_window);  
    _playerlist.push_back (_player);
    _playerlist.push_back (_player2);
}

Dank euch!

Zum Seitenanfang

Frischling

Wohnort: Solingen

16.12.2013, 19:36

Mhm, wenn man die Texturzuweisung

	C-/C++-Quelltext
1	_shipSprite.setTexture(_shipTexture);

nicht im Konstruktor der Playerklasse vornimmt, sonder zB in der Render()-Funktion der Playerklasse, dann klappt es auch. Also die Textur geht nicht verloren, das Sprite verliert nur die Information darüber.
Bleibt nach wie vor die Frage, warum?

Zum Seitenanfang

Checkmateing

Community-Fossil

Beiträge: 2 218

16.12.2013, 20:55

Kopierst du die Textur? Dann wird sie nämlich am Ende zerstört.
Ansonsten schiebt man sie oder eher deren verwendeten Verweise gern mal im Speicher hin und her (z.B. wenn man einen vector verwendet) was die Referenzen natürlich in diesem Sinne "ungültig" macht.
Außerdem solltest du, da du den Spieler ja in einen Container klatschst, den Kopierkonstruktor definieren und den Zuweiseungsoperator überladen, wo du die Textur dann eben setzt.

MfG
Check

Das gibt Übersicht! Stay gold.

Zum Seitenanfang

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

16.12.2013, 21:50

Jup, Texturen zu kopieren, weil sie by-value übergibt, verursacht genau solche Probleme. Möglichst - dringend - vermeiden. Am besten eine Unterklasse von sf::Texture erstellen, welche non-copyable ist. Ehrlich, das beseitigt viele Fehler und viele unnötige, ungewollt erstellte Kopien, so verrückt das auf den ersten Blick auf aussieht.

Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Zum Seitenanfang

Frischling

Wohnort: Solingen

17.12.2013, 00:42

Das klingt sinnvoll, werd ich so machen.
Allerdings dachte ich, das Problem besteht nur bei Pointern, weil wenn diese kopiert werden, sie immer noch auf die alte Adresse zeigen. Aber hier müsste _shipTexture doch komplett kopiert und zugewiesen werden.

ps: gibt es eigentlich eine möglichkeit, objekte direkt in einer Liste zu erstellen?

Zum Seitenanfang

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

17.12.2013, 06:35

Die Textur wird kopiert. Aber das Sprite zeigt per Referenz auf ein nicht mehr existierendes Objekt.

Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Zum Seitenanfang

eXpl0it3r

Treue Seele

Beiträge: 386

Wohnort: Schweiz

Beruf: Professional Software Engineer

17.12.2013, 08:47

Es empfiehlt sich Texturen nicht direkt in einem Container zu speichern, sondern am Besten verwendest du std::unique_ptr<sf::Texture> oder falls die Texture geshared wird std::shared_ptr<sf::Texture>, auf diesem Weg kannst du die Smartpointers einfach verschieben/kopieren, ohne die Ressourcen lastigen Texturen zu kopieren.

Zitat von »Asbestbrezel«

ps: gibt es eigentlich eine möglichkeit, objekte direkt in einer Liste zu erstellen?

Die Frage ist eher, brauchst du eine Liste um Texturen zu verwalten? Würde ein Vector oder eine Map nicht viel besser passen? Listen braucht man eigentlich nur, wenn die Reihenfolge wichtig ist und man mitten drin viele Objekte löschen muss, beides sollte eigentlich nicht so wichtig sein für das verwalten von Texturen.
Für die Frage selbst, kannst du dir gerne Mal die C++ Referenz anschauen.

Blog: https://dev.my-gate.net/
—————————————————————————
SFML: https://www.sfml-dev.org/
Thor: http://www.bromeon.ch/libraries/thor/
SFGUI: https://github.com/TankOs/SFGUI/

Zum Seitenanfang

Frischling

Wohnort: Solingen

17.12.2013, 19:42

Zitat von »eXpl0it3r«

Für die Frage selbst, kannst du dir gerne Mal die C++ Referenz anschauen.

Mhm, emplace_back scheint da genau das Richtige zu sein. Leider wirft der Compiler folgende Fehlermeldung aus(selbst mit dem code-bsp von cplusplus.com)

	Quellcode
1	»class std::list<std::pair<int, char> >« hat kein Element namens »emplace_back« mylist.emplace_back(30,'c');

neueste gcc-version ist installiert

Zum Seitenanfang

Spiele Programmierer

Alter Hase

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

17.12.2013, 20:09

Zitat

Es empfiehlt sich Texturen nicht direkt in einem Container zu speichern, sondern am Besten verwendest du std::unique_ptr<sf::Texture> oder falls die Texture geshared wird std::shared_ptr<sf::Texture>, auf diesem Weg kannst du die Smartpointers einfach verschieben/kopieren, ohne die Ressourcen lastigen Texturen zu kopier

Zum Einen sollte man ein solches Objekt am Besten gar nicht verschieben sondern wenn dann als Referenz nutzen und zum Anderen kann man so ein Objekt problemlos mit Move-Semantik verschieben. "unique_ptr" ist hier überflüssig.

Zitat

Leider wirft der Compiler folgende Fehlermeldung aus

Wie sieht den dein Code aus?
Du nutzt also den GCC?

Zum Seitenanfang

Frischling

Wohnort: Solingen

17.12.2013, 20:17

Mhm, ne, natürlich den g++.

Scheint so, als müsste man C++11 noch zusätzlich aktivieren, dann hagelts aber noch mehr Fehlermeldungen. Ich glaub ich lass das lieber erstmal...