Messages

1

Fenêtrage / Re : Singleton RenderWindow

« le: Avril 30, 2012, 08:15:31 am »

D’acore, merci pour tout. 

2

Fenêtrage / Re : Singleton RenderWindow

« le: Avril 30, 2012, 05:53:02 am »

Merci pour toute ces réponses!

Code: [Sélectionner]

    static GameWindow& GetInstance()
    {
        static GameWindow instance;
        return instance;
    }


Laurent, j'ai essayé ça tantôt.
Petite question, est-ce que instance est alors réaffecté à chaque appel de GetInstance()?

En fait le destructeur de ton object static est bien appellé, mais après le main.

Vraiment? ça expliquerait pourquoi j'entre jamais dedans avec mon breakpoint.   
J'ai vérifié tout ça au Virtual Leek Detector et en effet, ya aucune fuite. 

Merci

Code: [Sélectionner]

template <class T>
class CSingleton
...
Mais la je vais plutôt opté pour une solution un peu plus simpliste.

3

Fenêtrage / Re : Re : Singleton RenderWindow

« le: Avril 29, 2012, 09:07:53 pm »

class GameWindow
{
public:

    static GameWindow& GetInstance()
    {
        static GameWindow instance;
        return instance;
    }

    ...
};
 

Je vais essailler ça ce soir 

Et pourquoi avoir un membre statique (autre que l'instance de la classe) dans une classe singleton ?

Parce que j'ai pas dormit de la nuit? 

Merci pour les réponses rapides.

4

Fenêtrage / Re : Re : Singleton RenderWindow

« le: Avril 29, 2012, 08:33:00 pm »

sf::RenderWindow* GameWindow::screen = (sf::RenderWindow*)NULL;
GameWindow* GameWindow::instance =(GameWindow*)NULL;

en déclarant instance comme un pointeur dans le .h

Mille fois merci! 

J'ai toutefois, un autre petit souci qui se crée alors.
Si j'utilise dynamiquement l'instance de mon singleton, je dois alors aussi le supprimer.
Ce que j'ai remarqué c'est que, quand je met un "break point" dans le destructeur de GameWindow, il n'est jamais lu.
Cela m'inquiète un peu, car delete instance; et delete screen; ne seront jamais appelé et... tu sait... les memory leeks... 

Est-ce que les classes static on besoin d'un destructeur? 

Bref, cela revient à mon problème de départ où je dois appeler le destructeur à la main et ça, ce n’est pas de la programmation conventionnelle.

5

Fenêtrage / Re : Singleton RenderWindow

« le: Avril 29, 2012, 06:56:14 pm »

Oui, j'avait oublier 

GameWindow.h

Code: [Sélectionner]

class GameWindow
{
public:
static GameWindow& GetInstance();

private:
GameWindow(void);
~GameWindow(void);
GameWindow(const GameWindow& _source);
GameWindow& operator = (const GameWindow& _source);

static GameWindow instance;
static sf::RenderWindow* screen;
};

GameWindow.cpp

Code: [Sélectionner]

#include "GameWindow.h"

GameWindow GameWindow::instance;

GameWindow::GameWindow(void)
{
this->screen = new sf::RenderWindow();
}

GameWindow::~GameWindow(void)
{
delete screen;
}

GameWindow& GameWindow::GetInstance()
{
return instance;
}

Que je mette "sf::RenderWindow* screen;" static ou non j'ai des problèmes...
Si j'le mets pas, j'ai une violation d'écriture dans mlock.
Si j'le met, j'ai des symboles externes non résolus.

6

Fenêtrage / Singleton RenderWindow

« le: Avril 29, 2012, 05:56:10 pm »

Bonjour.

J'aimerais faire un singleton qui contient ou hérite d'un RenderWindow.
Il semblerait que je ne puisse pas le déclarer en static 

Ça fait déjà plusieurs heurs que je travail la dessus et il semble que le seul moyen d'y parvenir est de déclarer le singleton en pointeur tout comme le renderwindow d'ailleur, et de les allouer ensuite après l'initialisation du main.

Mon problème est que j'ai besoin de ce singleton pour avoir tous mes points dans mon travail scolaire et que je ne peux pas utiliser la technique des pointeurs mentionnés, car il faut alors créé une sorte de methode "destroy" pour aller "delete" le singleton à la fin du programme et ce n'est pas de la bonne programmation que dit mon prof de toute façon.

Comment dois-je créé mon singleton utilisant un RenderWindow? 

7

Discussions générales / Re : SFML 2.0 RC

« le: Avril 22, 2012, 12:27:43 am »

J'ai remarqué une petite erreur de syntaxe dans le \brief de sf::RenderTexture.
"\brief Target for off-screen 2D rendering into an texture"
"an" devrais être "a"

8

Discussions générales / Re : Re : SFML 2.0 RC

« le: Avril 19, 2012, 07:16:42 pm »

je dirais que tu as sur ton système des headers et des binaires de deux versions différentes de la SFML et que tu les mélanges en compilant.

C'était ça 

J'avais laissé traîné une version 1.6 de sfml dans le répertoire de visual studio, il l'incluait probablement par défaut en créant des conflits de compatibilité 

J'ai tout balayé et je recommence à zéro avec SFML2-rc.

Bon, tout compile, il me reste qu'à me familiariser avec la nouvelle convention de nommage

Merci pour les réponses rapides.

9

Discussions générales / Re : Re : SFML 2.0 RC

« le: Avril 19, 2012, 06:31:43 am »

Les fonctionnalités sont gelées

Est-ce que c'est pour ça qu'avec SFML2-rc je n'arrive qu'à instancier des classes (du genre comme dans ton exemple tutoriel avec sf::Clock), mais que je n'arrive pas à utiliser leur méthode ou fonction?

Comme exemple, quand je fais clock.GetElapsedTime() dans mon programme d'essais, ça compile, mais me sort une erreur à l'exécution: "The procedure entry point?GetElapsedTime@Clock@sf@@QBEIXZ could not be located in the dynamic link library sfml-system-d-2.dll."