Remake Zelda sur GBC

**Aspic** · 29/08/2011, 11h56

Envoyé par fearyourself

En fait dès que cela va en-dessous de la lib SFML, il n'y a plus grand chose à faire. J'ai le même type de souci avec la lib SDL.

Jc

Je suis d'accord mais il y a quand même des limites surtout que toutes les fuites ne proviennent pas que des lib extérieures et le total est énorme :

==2045== Conditional jump or move depends on uninitialised value(s)
==2045== at 0x414BF75: sf::priv::Joystick::Initialize(unsigned int) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414B0F1: sf::priv::WindowImpl::Initialize() (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A097: sf::Window::Initialize(sf::priv::WindowImpl*) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A5B0: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A915: sf::Window::Window(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x804890A: main (main.cpp:13)
==2045==
==2045== Use of uninitialised value of size 4
==2045== at 0x414BF7C: sf::priv::Joystick::Initialize(unsigned int) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414B0F1: sf::priv::WindowImpl::Initialize() (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A097: sf::Window::Initialize(sf::priv::WindowImpl*) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A5B0: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A915: sf::Window::Window(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x804890A: main (main.cpp:13)
==2045==
==2045== Conditional jump or move depends on uninitialised value(s)
==2045== at 0x414BA51: sf::priv::Joystick::UpdateState() (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414B113: sf::priv::WindowImpl::Initialize() (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A097: sf::Window::Initialize(sf::priv::WindowImpl*) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A5B0: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A915: sf::Window::Window(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x804890A: main (main.cpp:13)

==2045== LEAK SUMMARY:
==2045== definitely lost: 9,310 bytes in 10 blocks
==2045== indirectly lost: 39,868 bytes in 196 blocks
==2045== possibly lost: 0 bytes in 0 blocks
==2045== still reachable: 40,269,522 bytes in 2,255 blocks
==2045== suppressed: 0 bytes in 0 blocks
==2045== Reachable blocks (those to which a pointer was found) are not shown.
==2045== To see them, rerun with: --leak-check=full --show-reachable=yes

==2045== 2 errors in context 3 of 15:
==2045== Conditional jump or move depends on uninitialised value(s)
==2045== at 0x414BA51: sf::priv::Joystick::UpdateState() (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414B113: sf::priv::WindowImpl::Initialize() (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A097: sf::Window::Initialize(sf::priv::WindowImpl*) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A5B0: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A915: sf::Window::Window(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x804890A: main (main.cpp:13)
==2045==
==2045==
==2045== 2 errors in context 4 of 15:
==2045== Use of uninitialised value of size 4
==2045== at 0x414BF7C: sf::priv::Joystick::Initialize(unsigned int) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414B0F1: sf::priv::WindowImpl::Initialize() (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A097: sf::Window::Initialize(sf::priv::WindowImpl*) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A5B0: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A915: sf::Window::Window(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x804890A: main (main.cpp:13)
==2045==
==2045==
==2045== 2 errors in context 5 of 15:
==2045== Conditional jump or move depends on uninitialised value(s)
==2045== at 0x414BF75: sf::priv::Joystick::Initialize(unsigned int) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414B0F1: sf::priv::WindowImpl::Initialize() (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A097: sf::Window::Initialize(sf::priv::WindowImpl*) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A5B0: sf::Window::Create(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x414A915: sf::Window::Window(sf::VideoMode, std::string const&, unsigned long, sf::WindowSettings const&) (in /usr/local/lib/libsfml-window.so.1.6)
==2045== by 0x804890A: main (main.cpp:13)

J'en ai parlé sur le forum officiel apparemment les fuites ont été corrigées dans la version 2.0 mais c'est pas vrai car j'ai refait un test et c'est même pire qu'avec l'ancienne version

Je ne sais pas si il y a un rapport avec le fait que j'émule Ubuntu sur virtualbox mais je ne pense pas car je n'ai jamais eu de problème avec d'autres librairies graphiques.

**LittleWhite** · 29/08/2011, 13h18

En théorie, il n'y a pas de rapport avec VirtualBox, du moins, je ne comprendrai pas pourquoi il y en aurait (sauf si leur gestion d'OpenGL est foireuse ...)

Les fuites signalées, peuvent aussi être à cause du fait que la libération mémoire est à la limite du main (à la sortie du main). Essayez de faire la même chose, mais dans une fonction, qui serai appeler par le main. Enfin, c'est une idée, je dis peut être des bétises.

**Aspic** · 29/08/2011, 19h43

Envoyé par LittleWhite

En théorie, il n'y a pas de rapport avec VirtualBox, du moins, je ne comprendrai pas pourquoi il y en aurait (sauf si leur gestion d'OpenGL est foireuse ...)

Les fuites signalées, peuvent aussi être à cause du fait que la libération mémoire est à la limite du main (à la sortie du main). Essayez de faire la même chose, mais dans une fonction, qui serai appeler par le main. Enfin, c'est une idée, je dis peut être des bétises.

Non ca ne change rien

Je pense que je vais garder Allegro dans un premier temps, de toute manière si je veux changer vu que j'aurais séparé tout ce qui touche à la librairie du reste, ca ne devrait pas être trop difficile

J'ai une question, dans ton projet OpenAWars, as tu utilisé pour ton moteur des pattern design ou pas ?

Autre chose, pour séparer le moteur de jeu de l'affichage, j'avais fais pour la plupart des classes, une fonction dessiner() et une fonction gerer() mais je vois que tu n'as pas fait comme ca. Je n'arrive pas à comprendre à travers ton code comment tu as réussi à séparer l'affichage du reste ?

**LittleWhite** · 30/08/2011, 13h50

Des design pattern ... hum
J'ai évité le Singleton, qui est le plus "evil" des design pattern, pour certains.
J'utilise au maximum le principe de la responsabilité unique
Hum, si j'en utilise d'autre, je ne me rappelle plus trop des noms (faut que je les réapprenne bien). Peut être une Factory ... ou alors un truc proche de ce que l'on peut appeler les Interfaces :p
Désolé pour le manque de précision.

Moi, ma fonction "gerer" s'appelle "update" et c'est là que je mets à jour certains éléments (déplacement des UI / déplacement curseur / changement d'états du jeu)

**GR3lh442kR** · 30/08/2011, 16h49

Envoyé par LittleWhite

J'ai évité le Singleton, qui est le plus "evil" des design pattern, pour certains.

Salut LittleWhite,
tu peux expliquer pourquoi s'il te plait ? moi j'utilise beaucoup de pattern alors je suis curieux de connaitre ses défaults.

**dourouc05** · 30/08/2011, 17h12

Envoyé par bebaijhi

Salut LittleWhite,
tu peux expliquer pourquoi s'il te plait ? moi j'utilise beaucoup de pattern alors je suis curieux de connaitre ses défaults.

Un peu de recherche ne fait pas beaucoup de mal : http://en.wikipedia.org/wiki/Singlet...tern#Drawbacks.

**LittleWhite** · 30/08/2011, 18h06

Oui, des recherches peuvent trouver des résultats. Notamment, il y a un site d'une université américaine (Portland) qui possède pleins d'aperçus sur les design patterns.
Sinon, avec mes mots à moi:
Singleton => Variable globale qui empêche l'évolution d'un logiciel (dans le genre, nous avions prévu un seul et unique Logger et puis un beau jour, on veut changer cela ... et paf on doit tout casser)

**GR3lh442kR** · 31/08/2011, 10h50

Merci pour vos réponses.
Mes excuses pour la recherche, je vais creuser un peut sur google.

**Aspic** · 01/09/2011, 13h55

Voilà, j'ai tenté d'implémenter le moteur de jeu de LittleWhite pour mon projet Zelda.

J'espère que je n'ai pas trop fait de bêtise. Pouvez vous me dire ce que vous en pensez ?

Lien :
http://www.tutoworld.com/temp/nouvel...sion_zelda.zip

Pour l'instant, le programme n'utilise que la librairie allegro 4.2.3 (même si dans le makefile il y a d'autres librairies) et ne fait que déplacer avec les flèches un carré rouge.
Pour quitter le jeu, il faut appuyer sur la croix de la fenêtre.
Normalement, pas de fuite de mémoire

Bonne journée

**gbdivers** · 01/09/2011, 14h20

Envoyé par Aspic

Voilà, j'ai tenté d'implémenter le moteur de jeu de LittleWhite pour mon projet Zelda.

Le début de la gloire pour LittleWhite

Tu as vérifié la licence d'utilisation du LittleWhiteMostBeautifulInTheWorldGameEngine ?

**Aspic** · 01/09/2011, 17h44

Envoyé par gbdivers

Le début de la gloire pour LittleWhite

Tu as vérifié la licence d'utilisation du LittleWhiteMostBeautifulInTheWorldGameEngine ?

Oui je la connais

mais je n'ai pas copier/coller son code !
Je me suis juste inspiré de la structure de son moteur de jeu

Et puis si LittleWhite estime que j'ai trop "copier" son code, je mettrais sa licence ce n'est pas un problème

**fearyourself** · 01/09/2011, 20h12

Envoyé par Aspic

Oui je la connais

mais je n'ai pas copier/coller son code !
Je me suis juste inspiré de la structure de son moteur de jeu

Et puis si LittleWhite estime que j'ai trop "copier" son code, je mettrais sa licence ce n'est pas un problème

En principe, tu devrais toujours mettre : ceci est en inspiration de cela. Et tu peux mettre au fur et à mesure des changements la distance à laquelle tu te trouves...

Jc

**Aspic** · 02/09/2011, 12h25

Envoyé par fearyourself

En principe, tu devrais toujours mettre : ceci est en inspiration de cela. Et tu peux mettre au fur et à mesure des changements la distance à laquelle tu te trouves...

Jc

Bien sur

, et c'est déjà le cas dans les entêtes .h des fichiers dont je me suis inspirés

**LittleWhite** · 02/09/2011, 12h28

Notez que je commence à penser que je devrais faire mon moteur à fond, avec support OpenGL / SFML / Qt aussi

/ et autre et le mettre au niveau d'un moteur digne du nom de moteur de jeu.
(Soit, et j'ai déjà du code pour la SFML, faire en sorte d'avoir du son et des threads en plus)

**LittleWhite** · 02/09/2011, 12h43

Voilà, je reprends mes tests.

Le fichier Logger.cpp a un include incorrect car il faut mettre Logger.h en majusucule (la première lettre) car le fichier Logger.h possède le l en majuscule (GNU/Linux est très pointilleux pour ça)

Hum, j'ai enfin compilé, et je n'ai qu'un carré rouge sur un fond noir O_o
D'ailleurs, faudra penser à gérer les diagonales

**Aspic** · 02/09/2011, 12h59

Envoyé par LittleWhite

Voilà, je reprends mes tests.

Le fichier Logger.cpp a un include incorrect car il faut mettre Logger.h en majusucule (la première lettre) car le fichier Logger.h possède le l en majuscule (GNU/Linux est très pointilleux pour ça)

Hum, j'ai enfin compilé, et je n'ai qu'un carré rouge sur un fond noir O_o
D'ailleurs, faudra penser à gérer les diagonales

Oui c'est normal pour le carré en fait je voulais que tu vérifies si j'avais bien agencé les classes correctement selon le principe de ton moteur de jeu car j'ai l'impression que j'ai fais des bêtises...

Merci pour l'erreur d'include. Sous Windows, ca ne pose (malheureusement) pas de problèmes.

**LittleWhite** · 02/09/2011, 13h05

Envoyé par Aspic

Oui c'est normal pour le carré en fait je voulais que tu vérifies si j'avais bien agencé les classes correctement selon le principe de ton moteur de jeu car j'ai l'impression que j'ai fais des bêtises...

Ok, je vais regarder ça plus tard

Merci pour l'erreur d'include. Sous Windows, ca ne pose (malheureusement) pas de problèmes.

De rien

**Aspic** · 02/09/2011, 13h17

Envoyé par LittleWhite

Ok, je vais regarder ça plus tard

Merci beaucoup

Maintenant j'ai une question de conception (et oui ca m'arrive de réfléchir avant de coder ^^)

1) Dans un Zelda, il y a des donjons et des zones extérieures (qui font la transition entre les donjons). Il y a aussi des zones intérieures (maisons, magasins) et des cavernes. Le but est d'implémenter ces différentes "zones".

Je pense que les zones extérieures et intérieures ainsi que les cavernes ont les mêmes propriétés (peuvent contenir des coffres, n'ont pas de gestion de portes à clés, pas de boss...) mais j'en suis même pas sur alors qu'un donjon est plus compliqué : on a des portes automatiques, des portes à clés, la porte du boss, une carte, une boussole, des énigmes, un téléporteur, des mini-boss...

Qu'elle serait selon vous la meilleure implémentation possible de cela ?

2) La gestion des sprites : Le héro principal, les personnages, les ennemies sont des sprites. Mais les ennemies ont tous des capacités différentes (dans leur déplacement par exemple).

Dans ma première version, j'avais créé une classe Hero, une classe Perso et une Classe Ennemie abstraite et je créait une classe pour chaque type d'ennemie en utilisant le polymorphisme. Mais ca faisait beaucoup de classes...

Maintenant j'ai créé une classe Sprite qui contient une position, une taille et une image (propriétés qu'un ennemie, un perso ou le héro possèdent). Je ne sais pas trop comment l'utiliser à l'heure actuelle.

Si vous avez des idées, je suis preneur

Merci à tous pour votre aide

**gbdivers** · 02/09/2011, 14h19

Envoyé par Aspic

1) Dans un Zelda, il y a des donjons et des zones extérieures (qui font la transition entre les donjons). Il y a aussi des zones intérieures (maisons, magasins) et des cavernes. Le but est d'implémenter ces différentes "zones".

Je pense que les zones extérieures et intérieures ainsi que les cavernes ont les mêmes propriétés (peuvent contenir des coffres, n'ont pas de gestion de portes à clés, pas de boss...) mais j'en suis même pas sur alors qu'un donjon est plus compliqué : on a des portes automatiques, des portes à clés, la porte du boss, une carte, une boussole, des énigmes, un téléporteur, des mini-boss...

Qu'elle serait selon vous la meilleure implémentation possible de cela ?

Conceptuellement, c'est la même chose => même classe
Ce sont des maps, qui contiennent des objets. La seule différence sont les objets qui sont dans les maps extérieures et intérieures mais aucune raison de créer 2 classes différentes.

Envoyé par Aspic

2) La gestion des sprites : Le héro principal, les personnages, les ennemies sont des sprites. Mais les ennemies ont tous des capacités différentes (dans leur déplacement par exemple).

Dans ma première version, j'avais créé une classe Hero, une classe Perso et une Classe Ennemie abstraite et je créait une classe pour chaque type d'ennemie en utilisant le polymorphisme. Mais ca faisait beaucoup de classes...

Maintenant j'ai créé une classe Sprite qui contient une position, une taille et une image (propriétés qu'un ennemie, un perso ou le héro possèdent). Je ne sais pas trop comment l'utiliser à l'heure actuelle.

Ce que tu veux faire, c'est une classe (par exemple "Personnage") dont une partie du comportement (le déplacement par exemple) est définit en dehors de la classe.
Si tu veux un comportement statique (ie définit à la compilation), tu peux utiliser les "class policies" (méta programmation par template) :

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
class WalkMovePolicy
{
   bool isValidMoving(Position from, Position to) //vérifie si un mouvement est valide
   {
      foreach_position(from, to)
         if (sol[position] == "eau") return false; // on marche pas sur l'eau
   }
 
   void move(Position from, Position to) {} // effectue le déplacement
};
 
class FlyMovePolicy
{
   bool isValidMoving(Position from, Position to) //vérifie si un mouvement est valide
   {
      return true; // on vole au dessus de l'eau
   }
 
   void move(Position to) {} // effectue le déplacement
};
 
template<typename MovePolicy>
class Personnage
{
   void move(Position from, Position to)
   {
      if (MovePolicy::isValidMoving(from, to))
         MovePolicy::move(from, to);
   }
};
 
Personnage<WalkMovePolicy> hero; // personnage qui marche
Personnage<FlyMovePolicy> monstre; // monstre qui vole

A lire: Présentation des classes de Traits et de Politiques en C++

Si tu veux un comportement modifiable à l'exécution (par exemple pour créer des personnages dans des scripts avec un desgin pattern factory) : "design pattern stratégie"

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
class MoveStrategy// classe abstraite parent
{
   virtual bool isValidMoving(Position from, Position to) = 0;//vérifie si un mouvement est valide
 
   virtual void move(Position from, Position to) = 0; // effectue le déplacement
};
 
class WalkMoveStrategy : public MoveStrategy
{
   virtual bool isValidMoving(Position from, Position to) //vérifie si un mouvement est valide
   {
      foreach_position(from, to)
         if (sol[position] == "eau") return false; // on marche pas sur l'eau
   }
 
   virtual void move(Position from, Position to) {} // effectue le déplacement
};
 
class FlyMoveStrategy : public MoveStrategy
{
   virtual bool isValidMoving(Position from, Position to) //vérifie si un mouvement est valide
   {
      return true; // on vole au dessus de l'eau
   }
 
   virtual void move(Position to) {} // effectue le déplacement
};
 
class Personnage
{
private:
   MoveStrategy* m_moveStrategy;
 
public:
   Personnage(MoveStrategy* s) : m_moveStrategy(s) {}
 
   void setMoveStrategy(MoveStrategy* s) { m_moveStrategy = s; }
 
   void move(Position from, Position to)
   {
      if (m_moveStrategy->isValidMoving(from, to))
         m_moveStrategy->move(from, to);
   }
};
 
Personnage hero(WalkMoveStrategy); // personnage qui marche
Personnage monstre(FlyMoveStrategy ); // monstre qui vole

A lire : Présentation des principaux design patterns en C++

La second solution est moins performante (héritage, vtable, déréférencement) mais permet d'adapter dynamique (script) le comportement. A voir en fonction des besoins.

Tu peux même aller plus loin et considérer que tous les objets sont des "Objet" qui sont contrôlés par plusieurs types de personnes : le(s) joueur(s) (classe "Personnage" = classe "Object" avec une politique/stratégie "PlayerControled"), l'IA (classe "Monstre"= classe "Object" avec une politique/stratégie "IAControled") ou personne (classe "Item"= classe "Object" avec une politique/stratégie "NoControled").

Voila pour les bases mais on peut compliquer encore plus...

Bonne(s) réflexion(s)

**LittleWhite** · 02/09/2011, 19h03

La réponse de gbdivers est très juste.
Pourtant, cela me chagrine que pour chaque comportement, il faille faire une nouvelle classe.
Dans OpenAWars, j'ai utilisé un système de flags ... j'avouerai que c'est largement moins beau. La gestion est géré dans une fonction, qui analyse les flags pour donner le comportement voulu. Ainsi, il est facile de créer de nouvelle unité avec des comportements qui pourrait être le mixe entre plusieurs comportements.

Remake Zelda sur GBC

Projets

Discussions similaires

Partager

Partager