Vector



  • Guten Tag,
    wenn ich ein Objekte, welche ein Sprite beinhaltet, in einen Vector speichere und
    diese dann später zeichnen lasse werden keine Texturen mehr angezeigt (alle Objekte sind ein weißes Kästchen). Wenn ich die Objekte einzeln erstelle und sie zeichnen lasse funktioniert alles einwandfrei. Wo könnte der Fehler liegen?
    LG: Niclas

    int main()
    {	
    	sf::RenderWindow window(sf::VideoMode(700, 700), "NEG v.001");
    	window.setFramerateLimit(120);
    
    	std::vector<gegner> Monster;
    
    	for(int i=0; i<100; i++)
    	{
    		gegner G = gegner(20,30,100);
    		Monster.push_back(G);
    	}
    
    	sf::Clock clock;
    	sf::Time timer = clock.getElapsedTime();
    
    	while(window.isOpen())
    	{
    		sf::Event event;
    		while(window.pollEvent(event))
    		{
    			switch(event.type)
    			{
    				case sf::Event::Closed:
    					window.close();
    					break;
    				case sf::Event::KeyPressed:
    					if(event.key.code == sf::Keyboard::Escape) window.close();
    					break;
    			}
    		}
    
    		timer = clock.getElapsedTime();
    		std::cout << "FPS: " << 1/timer.asSeconds() << std::endl;
    		clock.restart().asSeconds();
    
    		window.clear(sf::Color::Black);
    
    		for(int i=0; i<Monster.size(); i++)
    		{
    			Monster[i].Update(window,4);
    			Monster[i].Render(window);
    		}
    
    		window.display();
    	}
    
    	return 0;
    }
    

  • Mod

    glaskugel: rule of 5





  • Der Glaskugelspruch ist sowasvon 2010.



  • Zeig mal die ganze Klasse gegner. Das sf::Texture Objekt muss solange "am Leben" bleiben, wie dein sf::Sprite Objekt, sonst funktioniert es nicht.

    Du musst die sf::Texture Objekte also irgendwo speichern, du kannst nicht einfach ein temporäres erstellen, dann der Sprite übergeben und anschließend das sf::Texture Objekt out-of-scope gehen lassen.

    LG


  • Mod

    @camper: Ich habe gerade Deinen Beitrag im anderen Board gesehen. Ich wusste nicht, dass OT Dich tatsächlich nervt; Ich wollte nur einen dummen Spruch machen. Nimm's mir nicht übel, alter Hase; Ich schreibe gerade Examen und bring nicht mehr zustande. In zwei Wochen, und mit etwas Glück bald danach auch unter einer neuen Forensoftware, kann ich mich etwas hilfreicher verhalten.

    Zur Feier des Tages sag ich sogar was (offensichtliches) zum Thema: gegner wird wahrscheinlich einen Zeiger auf die Ressource (e.g. sf::Texture ) halten, der im Destruktor zerstört wird, im (womöglich implizit definierten) Kopierkonstruktor aber anstatt der Ressource (Textur) kopiert wird. Das ist nur eine Vermutung, aber die Idee, dass du wohl auf ein zerstörtes Objekt zugreifen willst, ist fast schon sicher. Ich schließe mich meinem Vorposter an: Zeig uns den Rest von gegner .

    Falls du tatsächlich einen Zeiger speicherst, könntest du mal probieren, einfach direkt einen Member vom Typ sf::Texture zu halten. SFML ist erfrischend modern designed, und die Klassen haben Kopierkonstruktoren! 😮 Das könnte dein Problem also direkt lösen. Und noch ein Tipp von mir (aber wende ihn nicht einfach an und ignoriere den Rest dieses Threads!):

    gegner G = gegner(20,30,100);
    Monster.push_back(G);
    

    ...kann man auch als

    Monster.emplace_back(20, 30, 100);
    

    fassen.



  • Kurze Frage nebenbei (aber relevant zum Thema): Wäre das emplace_back denn effizienter als

    std::vector<gegner> Monster{ 100, {20, 30, 100} };
    

    ?

    Oder ist das blöd, weil dann gegner kopiert wird?


  • Mod

    Richtig: kopiert, nicht mal gemoved, dank dem immutable initializer_list Problemchen. Aggregate ( std::array und native Arrays) müssen, ab C++17, bei solcher Initialisierung hingegen weder kopieren noch moven, stichwort temporary materialization (bzw. in diesem Fall sowieso nicht, wegen aggregate initialization).



  • O.K. gut zu wissen, danke.


Anmelden zum Antworten