Bonjour,
Pensez à bien faire un make clean avant de distribuer une quelconque version.
Design:
Pourquoi la position contiendrai un "compteurTile" , "typeBlocTraversable", "typeSol". Cela ne me semble pas vraiment être nécessaire pour une position.
(Soit, votre structure à trop de responsabilité).
1
2
3
4
| void setPositionX (int X); // Pour lire et mettre à jour la position de Link
void setPositionY (int Y);
int getPositionX();
int getPositionY(); |
Encore mieux, si on pouvait passer directement une position (la structure) en paramètre. Non?
1
2
3
4
5
6
7
8
| void setBougeHaut(bool H); // Pour lire et mettre à jour le sens de déplacement de Link
void setBougeBas(bool B);
void setBougeGauche(bool G);
void setBougeDroite(bool D);
bool getBougeHaut();
bool getBougeBas();
bool getBougeGauche();
bool getBougeDroite(); |
Si vous utilisiez un enum (ou autre) pour la direction, vous auriez qu'un setteur / getteur.
De plus, je ne suis pas sur que ce soit à un élément externe de dire la direction du personnage.
1
2
3
| void setTailleCarte(int X,int Y);
int getLargeurCarte();
int getHauteurCarte(); |
Cela n'a pas à être dans la classe du personnage ( http://blog.emmanueldeloget.com/inde...abilite-unique )
SDL_Surface* chargementImage(const char* fichier_image);
Même remarque. Si je n'ai pas de perso, je ne charge pas d'image ?
Mieux vaut faire un fichier par classe (je dis cela après avoir vu personnage.h).
Il me semble que toute vos classes possèdent trop de responsabilités (elles sont énormes).
Ah, finalement, la classe jeu à la même fonction:
SDL_Surface* load_image( std::string filename );
Pour une classe qui possède des pointeurs (donc il y aura allocation dynamique), vous n'avez pas implémenté de destructeur. Cela sent la fuite de mémoire.
1
2
3
4
5
6
| #define LARGEUR_TILE 16 // hauteur et largeur des tiles.
#define HAUTEUR_TILE 16
#define LARGEUR_PERSOLINK 16 // hauteur et largeur de Link.
#define HAUTEUR_PERSOLINK 24
#define LARGEUR_ECRAN 320 // hauteur et largeur de l'écran.
#define HAUTEUR_ECRAN 240 |
Cela est répété dans tout les fichiers ? O_o.
Mieux vaut que vous ne le mettiez qu'une seule et unique fois, dans un fichier .h ou dans une classe statique.
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
56
57
58
| // Pour la classe héro
SDL_Rect persoLink[26][9];
SDL_Rect persoLinkNage[4][5];
SDL_Rect persoLinkPorte[4][5];
SDL_Rect persoLinkSpecial[7];
SDL_Rect epeeLink[6][6];
SDL_Rect bouclierLink[4];
SDL_Rect mailletLink[4][3];
SDL_Rect baguetteFeuLink[4][3];
SDL_Rect baguetteGlaceLink[4][3];
SDL_Rect objetALancer[4][3];
SDL_Rect ombreObjetLance;
SDL_Rect jaugeLink[2];
SDL_Rect inscriptionDemiLink;
SDL_Rect cadreArmeLink;
SDL_Rect rubisLink;
SDL_Rect bombeLink;
SDL_Rect arcLink[2];
SDL_Rect cleLink;
SDL_Rect inscriptionVieLink;
SDL_Rect petitsCoeursLink[3];
SDL_Rect feuillesExplose[7][4];
SDL_Surface *pLink = NULL;
SDL_Surface *pEpeeLink = NULL;
SDL_Surface *pBouclier = NULL;
SDL_Surface *pObjets = NULL;
SDL_Surface *pStatut = NULL;
SDL_Surface *pObjetALancer = NULL;
SDL_Surface *pOmbreObjetLance = NULL;
SDL_Surface *pBuissonExplose = NULL;
// Pour la classe personnageJeu
// Pour la classe ennemi
SDL_Rect ennemi46[4][2]; // x 22 - y 27
SDL_Rect epee46[4];
SDL_Rect explo[7];
SDL_Surface *pExplo = NULL;
SDL_Surface *pEnnemi46 = NULL;
SDL_Surface *pEnnemi47 = NULL;
SDL_Surface *pEnnemi48 = NULL;
// Pour la classe ami
SDL_Rect personnage1[4][2]; // x 16 - y 25
SDL_Surface *pAmi1 = NULL; |
Des variables globales à foison ... alors que vous êtes en C++ et que vous avez le système de classes
Je ne veux plus jamais voir ça. C'est du code à retirer immédiatement (je plaisante pas)
Explication:
Une variable globale a une visibilité très étendue (surement de trop) et en plus, on ne sait pas trop qui gère sa durée de vie (construction / destruction). Il y a un grand risque que vous ayez des fuites de mémoire / ressources
Évitez les pointeurs pour vos tableaux. En C++, tout comme en java, vous avez des listes (std::list) et des vecteurs (sorte de liste en mieux 
std::vector)
Je vous conseille la lecture de quelques cours et de la FAQ
Niveau jeu, bah je dois dire que c'est impressionnant tout de même, que cela tienne autant debout . Bravo.
Par contre, les ennemies se bloquent lorsqu'ils suivent le joueur, à cause d'une mauvaise gestion des collisions. Notamment, il indique aller sur le bas, le buisson est sur la droite et il n'avance plus.
En haut à gauche, j'ai un carré de couleur uni, pas très normal.
Sinon, gestion des animations, ça semble correct.
Voilà pour le moment.
Alors je ne dis pas cela pour vous décourager. Juste qu'actuellement, votre code est imbuvable (genre, vous ne pourrez pas travailler en équipe). Mais encore, vous pouvez vous dire, ouep, mais là, c'est un projet perso. Il y a un deuxième point à voir. C'est que lorsque vous allez vouloir ajouté plein de trucs (nouvelles armes / actions) vous allez prendre beaucoup de temps pour ce faire, à retoucher des petits morceaux de code éparpillés / rajouter des bugs (et des corrections encore plus mauvaise). Cela peut être évité avec une bonne architecture (il y a 5 ans, je n'aurai jamais dit cela ).
De plus, si vous arrêtez de travailler sur votre, pendant, 1 mois, ou même 2 semaines, vous allez oublier des morceaux et vous ne saurez plus comment il fonctionne. Du coup, vous aurez du mal à continuer le projet. Certes les commentaires peuvent aider, mais si le code est bon, il est explicite (et inversement).
Voilà mes conseils, j'ai fait les remarques afin que vous vous amélioriez 
EDIT:
Ah ah ! J'ai trouvé un bug effectif \ o / (Je ne pouvais pas partir sans). Une fuite de mémoire.
On tue un ennemi, on entre dans la maison, on ressort, il réapparait, on le retue et on recommence. Le jeu prend plus en plus de place en mémoire.
Il semble que la fuite soit aussi lorsque tapons avec le maillet sur les trucs en bois
EDIT2:
La pause fait que mon CPU grimpe à 100%.
Mon projet zelda
Répondre avec citation
Envoyé par diabolos29
Freeze ?
et 
si la réponse vous a été utile !
Partager