Gestion des classes entre elles et organisation.

**Hybrix** · 07/08/2007, 21h07

Merci beaucoup,

Si le jeu fonctionne c'est déjà ça, mais c'est bizare que je n'ai rien lorsque je lance le jeu chez moi (A partir du dossier ).

Le code source n'est pas très propre, jelerefait entièrement actuellement (D'ou toutes les questions de ce topic

).

Le problème des sacades est corrigé, j'avais ma configurer la partie limitant les fps ( Mauvaise initialisation )

Merci encore.
Hybrix.

**dolanor** · 08/08/2007, 12h04

Envoyé par Hybrix

je débute sous linux (Très rarement utilisé avant), j'ai installé toutes les bibliothèques par Adept, exepté Fmod ou j'ai lu la doc.

Ok, ben tu t'y es bien pris alors.
Donc fmod est une plaie a installer sous GNU/Linux ?

[/HS]

**fearyourself** · 08/08/2007, 13h05

Envoyé par dolanor

Donc fmod est une plaie a installer sous GNU/Linux ?

Moi je n'ai eu aucun problème pour l'installer sous Ubuntu. Faut juste mettre les fichiers aux bons endroits.

Jc

**Hybrix** · 08/08/2007, 14h44

Facile à installer, mais je ne connaissait aucune commandes donc difficile de copier/coller dans un repertoire où l'on as pas l'autorisation (Maintenant je sais faire)

.

**Hybrix** · 13/08/2007, 16h56

Suite à vos conseils,

Je me suis documenté sur l'héritage, lu divers tutoriels en les testant, ainsi que le tutoriel de Pierre Schwartz sur l'architecture d'un jeu vidéo 3D (Même si le mien sera en 2D ).

J'ai donc plusieurs questions, je livre une archive pour mieux voir le problème : Ici (900Ko)

(J'utilise la bibliothèques SFML de Laurent Gomila).

Dans le fichier Game.cpp, j'ai inclus tout les moteurs du jeu : Physic, Graphic, Game, ainsi qu'une classe Player.

J'ai décidé (Est-ce de bonnes idées ?) de crée la fenêtre dans le moteur Graphique, et de gerer les événement dans la classe Player (Seul le joueur obéit au clavier).

Le problème, pour gerer les évenements il me faut l'objet de type sfWindow présent dans la classe GraphicEngine, et l'envoyer à la classe Player.

Ce qui donne :

Je rencontre dans tout mes programmes se problème, et je n'y trouve jamais de solution, les accesseurs et mutateurs ne fonctionne pas toujours et ne sont pas très propre au niveau du code je trouve.

Y a t-il d'autres solutions à ce problème ?

J'ai lu le tutoriel sur l'architecture d'un jeux vidéo 3D comme je l'ai dit plus haut, et j'utilise la méthode décrite, mais je ne comprend pas certains points

.

Désolé pour toutes ces questions.
Hybrix.

**Laurent Gomila** · 13/08/2007, 17h14

Quel est le problème exactement ? Je veux dire, d'une part pourquoi as-tu besoin de l'objet qui représente la fenêtre dans Player, et d'autre part pourquoi n'arrives-tu pas à y accéder ?

**Hybrix** · 13/08/2007, 17h21

J'ai besoin de la fenetre dans player pour gérer les évènements :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  /*while (windows.GetEvent(Event))
  {
       // Traitement de l'évènement
  }
  */

Lorsque j'utilise les accesseurs et mutateurs, je reçoit le message suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 
E:/Logiciels/CodeBlocks/SFML-1.0/include/SFML/System/NonCopyable.hpp:55: error: `sfNonCopyable::sfNonCopyable(const sfNonCopyable&)' is private
 
////////////////////////////////////////////////////////////
    /// Copy constructor : declare it private and don't implement
    /// it to prevent from calling it
    ///
    ////////////////////////////////////////////////////////////
    sfNonCopyable(const sfNonCopyable&);

**Laurent Gomila** · 13/08/2007, 17h31

J'ai besoin de la fenetre dans player pour gérer les évènements

Typiquement c'est la classe de plus haut niveau (celle qui contient la fenêtre) qui devrait vider la pile d'évènements, et les dispatcher à qui en a besoin.

Lorsque j'utilise les accesseurs et mutateurs, je reçoit le message suivant

C'est que tu tentes de renvoyer une copie de la fenêtre (qui ne sont bien sûr pas copiables), il faut plutôt renvoyer une référence.

**Hybrix** · 13/08/2007, 17h38

D'accord,

Mais je ne voit pas comment organiser tout ça alors (il me faut du temps pour comprendre

), si l'on reprend l'archive fourni, l'architecture est incorrect, comment je doit réorganiser tout ça ?

J'oubliais, la classe GameEngine contiendra tout les éléments du jeu (caisses, sols, monstres, ...) je devrait tous les envoyés à la classe GraphicEngine pour les affiché, ou bien je devrait appeller la classe GraphicEngine depuis la classe Game Engine ? (ça revient a l'autre problème, je ne voit pas comment faire communiquer les classes entre elles

).

**Laurent Gomila** · 13/08/2007, 17h44

Par exemple, ta classe Game peut contenir une liste de EventListener*, qui serait une classe abstraite pouvant recevoir les évènements et dont Player hériterait. Ainsi à chaque tour de boucle, Game viderait la pile d'évènements de sa fenêtre, et les renverrait aux EventListener* de sa liste.

**Hybrix** · 13/08/2007, 17h47

Désolé, mais pour moi ça reste incompréhensible, je suis loin d'avoir votre niveau

.

Aurait-tu des exemples ?

**Laurent Gomila** · 13/08/2007, 18h18

Désolé, mais pour moi ça reste incompréhensible, je suis loin d'avoir votre niveau

Toi t'es pas au bout de ton jeu

Aurait-tu des exemples ?

Ecrit à l'arrache pour te montrer le principe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
class EventListener
{
public :
 
    virtual ~EventListener() {}
 
    virtual void OnEvent(sfEvent& Event) = 0
};
 
class Game
{
public :
 
    void AddEventListener(EventListener* Listener)
    {
        myListeners.push_back(Listener);
    }
 
private :
 
    void GameLoop()
    {
        AddEventListener(&myPlayer);
 
        bool IsRunning = true;
        while (IsRunning)
        {
            sfEvent Event;
            while (myWindow.GetEvent(Event))
            {
                if (Event.Type == sfEvent::Close)
                    IsRunning = false;
                else
                    for (std::vector<EventListener*>::iterator i = myListeners.begin(); i != myListeners.end(); ++i)
                        (*i)->OnEvent(Event);
            }
 
            ...
        }
    }
 
    sfWindow myWindow;
    Player myPlayer;
    std::vector<EventListener*> myListeners;
};
 
class Player : public EventListener
{
private :
 
    virtual void OnEvent(sfEvent& Event)
    {
        ...
    }
};

**Hybrix** · 13/08/2007, 18h22

Toi t'es pas au bout de ton jeu

Non, je fait ça pour apprendre

, (j'ai tout de même sortie une démo : Ici )

Je vais regarder de plus près le code donné. Merci.

**Hybrix** · 13/08/2007, 21h20

Je ne connais pas certaines "actions/fonctions" utilisées, aurait tu des mots clés où bien comment s'appelle ce que tu as employé (Par exemple Classe abstraite ), pour que je trouve de la documentation.

**Laurent Gomila** · 14/08/2007, 08h59

Il y a effectivement une classe abstraite. Sinon pour le reste, dis toujours ce que tu ne comprends pas.

**Hybrix** · 14/08/2007, 16h20

J'ai essayer de comprendre le code que tu as écrit, mais je ne suis pas sûr d'avoir compris l'utilité, voilà ce que j'ai compris :

La classe Game possède un vector contenant la liste des évènements.
Dans la classe Player, si l'utilisateur déclenche un évènement, on ajoute un évènement à la liste ( vector ).
La classe Player hérite de la liste des évènements, elle peut donc réagir à ça.

Je pensais qu'il existait un moyen plus facile de faire communiquer les classes entres elles.
Pour la démo plus haut, j'avais utilisé des classes statiques, ils étaient plus facile de les appeller depuis n'importe ou

.

**Hybrix** · 15/08/2007, 17h51

Je pense avoir compris le but de la classe abstraite, Player est déclaré dans la classe Game, il ne peut donc pas herité de Game donc de sfWindow, je doit donc passé par une classe abstraite.

Et puis ça évite le même problème pour graphicEngine, la classe heritera aussi de EventListener.

Est ce que c'est ça ?

**Laurent Gomila** · 15/08/2007, 18h00

En fait, EventListener est une interface qui signifie "si tu hérites de moi, tu seras notifié des évènements générés par la fenêtre". Comme on veut que Player reçoive ses évènements, on l'en fait dériver.

Ensuite c'est la classe Game qui maintient la liste des EventListener existant, et qui s'occupe de leur notifier les évènements de sa fenêtre.

**Hybrix** · 15/08/2007, 22h07

Ah ! J'ai enfin tout compris !

Bon j'ai un petit problème par contre, Player est alloué dynamiquement dans Game.cpp, le fait que Player hérite d'EventListener le compiler n'apprécie pas la classe abstraite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
cannot allocate an object of type `Player' because the following virtual functions are abstract: "EventListener ...."

Maintenant que j'ai compris l'héritage, l'utilisation de friend et de virtual, je me posait la question :

Si Player hérite de Game, il peut tres bien hériter de sfWindow non ?

De plus pour la suite, est ce que c'est propre si Player hérite du moteur physique, graphique, audio, ... ? ( Je pense à ça, car enrevoyant le début de ce sujet, dans l'exemple player héritait du moteur physique.

**deadalnix** · 16/08/2007, 04h22

Dans eventListener, certaines fonctions ne sont pas definies. le prototype fini par "= 0;"

cela signifie que tout les eventListener auront cette fonction, mais qu'elle n'est pas decrite dans eventListener. Ca fait de eventListener une calsse abstraite, c'est a dire qu'on ne peut pas creer d'objet de type eventListener, mais de classe heritées.

Toutes les classe heritées de eventListener seront elle aussi abstraite sauf si elles definissent les fonctions non definies dans eventListener.

Gestion des classes entre elles et organisation.

Développement 2D, 3D et Jeux

Discussions similaires

Partager

Partager