SFML Hilfe!



  • Hallo Leute,

    habe folgendes Problem:
    Übergebe ein Fenster(sf::RenderWindow window) per Funktion(void Function(sf::RenderWindow &window)) an einen Konstruktor einer Klasse. Dort will ich einer privaten Variable (sf::RenderWindow GWindow) das Fenster (window) übergeben(this->GWindow = window). Das klappt nicht, weiß einer warum?

    Hier nomma der Code:

    // Ausschnitt der Main
    sf::RenderWindow window(sf::VideoMode(GetSystemMetrics(SM_CXSCREEN) * ScrnSize, GetSystemMetrics(SM_CXSCREEN) * Screenscale * ScrnSize, 64), "Game", sf::Style::Close);
    Menue Main(window);
    
    // Ausschnit aus der Menue.h
    class Menue
    {
    private:
    	sf::RenderWindow GWindow;
    public:
         Menue(sf::RenderWindow &window);
    	~Menue();
    };
    
    // Ausschnitt der Menue.cpp
    Menue::Menue(sf::RenderWindow &window)
    {
    	this->GWindow = window;
    }
    

    Das Klappt ned 😕



  • Der Kompiler dürfte es wissen... bitte Fehlermeldung mitliefern.

    Vermutlich ist sf::RenderWindow nicht kopierbar.



  • Fehler C2280 "sf::RenderWindow &sf::RenderWindow::operator =(const sf::RenderWindow &)" : Es wurde versucht, auf eine gelöschte Funktion zu verweisen

    Das ist sie.

    Wie kann ich es sonst machen, das ich auf das Fenster in mehreren Klassen zugreifen kann. Weil ich nicht jeder Funktion das Übergeben will.


  • Mod

    Dann hatte theta mit seiner Vermutung vollkommen Recht. Die Zuweisung ist nicht erlaubt; wie sollte das selbe RenderWindow 2x existieren? Vielleicht möchtest du bloß einen Verweis auf das existierende RenderWindow?



  • Ja ich will hald aus jeder Funktion in der klasse auf das Fenster zugreifen können ohne es an jede Funktion zu übergeben.

    Und wenn wir schon dabei sind, kann man klassenobjekte allgemein in einer klasse nutzen?


  • Mod

    1234567890 schrieb:

    Und wenn wir schon dabei sind, kann man klassenobjekte allgemein in einer klasse nutzen?

    Die Frage macht sprachlich nicht wirklich Sinn, du scheinst die Begriffe "Klasse" und/oder "Klassenobjekte" nicht recht zu verstehen.

    Instanzen einer Klasse unterscheiden sich in der Regel¹ nicht von Instanzen der Basisdatentypen (wie int, double, usw.) und können in jedweder Hinsicht genau so benutzt werden.

    ¹: Hier liegt eine Ausnahme von dieser Regel vor, weil die Programmierer von RenderWindow ausdrücklich das Kopieren und Zuweisen von Instanzen dieser Klasse verboten haben, weil es semantisch keinen Sinn macht, wenn eine Instanz eines RenderWindow zwei Mal existiert.



  • 1234567890 schrieb:

    Ja ich will hald aus jeder Funktion in der klasse auf das Fenster zugreifen können ohne es an jede Funktion zu übergeben.

    Ja, aber dazu willst du ja nicht 2 verschiedene Fenster haben. Das würde nämlich das Kopieren bedeuten - die 2 Kopien wäre danach unabhängig. Da es nur ein Fenster gibt, ist das Kopieren nicht erlaubt (das wäre ja blödsinnig).

    Also: speichere nur, wie schon geschrieben, einen Verweis (Pointer) auf das Fenster, wie wär's also mit einer Variablem vom Typ: sf::RenderWindow* - also mit *.

    Und wenn wir schon dabei sind, kann man klassenobjekte allgemein in einer klasse nutzen?

    Ja, zumindest wenn ich deine Frage richtig verstehe (kannst du die genauer erklären - was sind Klassenobjekte?)



  • Ich hab mir bei sfml ne button class geschrieben und ich will auch hier wieder aus jeder funktion in der Manü klasse auf die button zugreifen können, aber ich weiß nicht wo ich den button "bauen" soll.

    Und ja bin noch anfänger und kann eig nur das nötigste, aber unsere geniale schule kommt auf die idee uns einfach so ohne sowas überhaupt dran genommen zu haben sollen wir n programm schreiben, mit grafik etc aber ham wir nie durchgemacht...



  • Du solltest in deiner Klasse eine Referenz auf das RenderWindow speichern (und den public Teil zuerst aufführen):

    class Menue
    {
    public:
         Menue(sf::RenderWindow &window);
    
    private:
        sf::RenderWindow& GWindow;
    };
    
    Menue::Menue(sf::RenderWindow &window)
        :GWindow{window}
    {
    }
    

    Eindeutig das Grundproblem: Programmieren mit SFML, ohne C++ selbst zu verstehen (war bei mir auch das Problem)! Die Buttons kannst du in einem vector speichern (standard container aus der standard bibliothek)

    Was man oft sieht: Menü hat einen vector<shared_ptr<Button>> und eine Funktion addButton(const shared_ptr<Button>& btn). Die Buttons erstellst du irgendwo mit make_shared (da wo auch dein Menü erstellt wird) und fügst alle Buttons dem Menü hinzu. Danach wird in die main-loop übergegangen, wo Menü alle Buttons "drawt" und "updatet". Meist besitzten die Buttons so genannte "callbacks", d.h. Funktionen die ausgeführt werden, wenn der Button geclickt wird.

    Um eine mögliche Implementation eines einfach gehaltenen GUI systems mit SFML zu sehen, siehe :https://github.com/SFML/SFML-Game-Development-Book/tree/master/06_Menus, im speziellen die Klassen "Container", "Component", "Button". Die Buttons werden hier zwar über die Tastatur betätigt, aber den Grundaufbau kannst du abschauen.

    Frage: Müsst ihr die GUI selbst implementieren, oder dürft ihr auch was fertiges verwenden (TGUI, SFGUI, ...)? Muss es SFML sein, oder könnt ihr auch mit QtCreator die GUI zusammenclicken?#

    LG



  • Danke für die Hilfe.

    Wie wir das machen ist egal, also könnte ich schon die anderen sachen benutzen, nur ich habe mich hald schon mit sfml vertraut gemacht, daher würde ich ungern wechseln.

    Und ich muss sagen ich hab mit der Gui keine Probleme, ich hatte hald vorher alles in einer Klasse und das war total unübersichtlich und deswegen hab ich mehrere Klassen gemacht und alles nur da hab ich jetzt Probleme mit meinen eigenen Anforderungen. Ich kann das Programm so umschreiben das es problemlos Funktioniert, nur ich will hald so wenig wie möglich doppenlt als code haben und alles möglichst in funktionen packen.

    Und ich will dich jetzt nicht schocken aber ich wollte da ei noch mit opengl arbeiten.

    Und an die die jetzt sagen ich sollte erstma programmieren können sag ich nur Learning by doing


Anmelden zum Antworten