Discussion :

[LittleWhite]

Je suis d'accord avec le premier point de lagwag. Et tout ce qui est de la notation hongroise, doit ce limité aux préfixes des variables membres ( m_ ) et aux pointeurs ( p ). Tout le reste pourri plus le code que n'en facilite la lecture.

De plus, pour les pointeurs, grâce au préfixe 'p' qui aide vraiment à leur repérage et leur suppression correcte, mais, il faut tout de même être un gars gérant son code sur le bout des doigts et être très précautionneux avec la gestion des pointeurs (et de la mémoire alloué).
Certes, j'ai entendu dire que les smart pointers de la STL sont trop faiblard, alors je préconiserai ceux de boost.
Comme le dirai Emmanuel, la gestion des pointeurs est assez compliqué et il en faut une classe à part pour les gérer.

Par contre, dans la structure présenté, je n'ai pas vu où vous cachiez les 'id' des tuiles afin de faire l'affichage de la bonne tuile

GroupArea peut être un std::vector d'un std::vector<Area*>. Cela permettra un accès en [x][y]

Après, pour la classe World, j'ai pas très bien compris pourquoi vous utilisez une std::map. Par contre, moi, je ne suis pas contre les std::map

[gbdivers]

Débat récurent : utiliser les conteneurs/pointeurs intelligents ou non ?
A mon sens, ces classes n'ont qu'une fonction : gérer automatiquement la mémoire. Pour une première version de jeu, préférer gérer manuellement la mémoire est une optimisation trop précoce. Fais déjà le jeu avec les outils disponible, ensuite, tu verras pour optimiser si tu trouves que ces outils ne sont pas adaptés. Pas avant.

[lagwag]

ce n'est pas une optimisation mais une facon de structurer son code... et vaut mieux apprendre dès le debut à maitriser les pointeurs standards...

ben sinon on peut aussi lui dire de commencer avec Unity pour un premier jeu... et il optimisera son code en apprenant le c++ plus tard

[gbdivers]

ce n'est pas une optimisation mais une facon de structurer son code... et vaut mieux apprendre dès le debut à maitriser les pointeurs standards...

ben sinon on peut aussi lui dire de commencer avec Unity pour un premier jeu... et il optimisera son code en apprenant le c++ plus tard

Ce n'est pas une façon de structurer son code, c'est un simple détail d'implémentation. La meilleure preuve est que l'on pourrait (presque) faire un rechercher-remplacer pour remplacer tous les pointeurs nus par des pointeurs intelligent et vice-versa.
Et si ce n'est pas une optimisation de gérer manuellement la mémoire, quel est l'intérêt de se casser les pieds à le faire ? Si les conteneurs/pointeurs intelligents sont aussi efficace mais en plus sont plus sur, c'est n'importe quoi de faire sans.

Pour le dernier point, c'est aussi une question récurrente : faut-il commencer pas les choses les plus simples et sur (les conteneurs, les pointeurs intelligents) ou faut-il commencer pas le bas niveau pour maîtriser ce qu'il y a derrière ces classes ?
Mon point de vue est clair là dessus aussi : on commence par ce qu'il y a de facile et sur et on apprend les techniques avancées après.

[LittleWhite]

Et le dernier point à avancer:
Vous ne devriez pas refaire les roues ( std::vector ; std::list ; std::map ; les smart ptr (qui ne sont pas une chose trop simple à faire en plus) si vous n'avez aucune obligation.
Et même, les perf sont rarement une obligation, car les std::vector et autres sont tout de même bien développer (bon, peut être que je suis une quiche aussi).

Maintenant, le seul cas que je vois, c'est si vous voulez porter votre jeu sur Amiga OS 4 et/ou GP2X, alors là, nous en reparlerons

[Aspic]

Je suis d'accord avec le premier point de lagwag. Et tout ce qui est de la notation hongroise, doit ce limité aux préfixes des variables membres ( m_ ) et aux pointeurs ( p ). Tout le reste pourri plus le code que n'en facilite la lecture.

Je n'aime vraiment pas cette notation et j'ai mes habitudes donc je me retrouve très bien dans mes variables

Par contre, dans la structure présenté, je n'ai pas vu où vous cachiez les 'id' des tuiles afin de faire l'affichage de la bonne tuile

C'est normal ce n'est pas géré comme ca, les maps sont déjà faite à l'avance donc je ne fais qu'un load de l'image en mémoire

GroupArea peut être un std::vector d'un std::vector<Area*>. Cela permettra un accès en [x][y]

Oui pourquoi pas mais dans ce cas, où mettre la méthode makeTransition() qui permet de passer d'une zone à une autre ?

Après, pour la classe World, j'ai pas très bien compris pourquoi vous utilisez une std::map. Par contre, moi, je ne suis pas contre les std::map

Pour distinguer les zones de la plaine, de celle d'une montagne par exemple et faire des accès : ["plaine"]->getAreas() ou ["montagne"]->getAreas()

[LittleWhite]

Je dois dire que je suis totalement perdu dans votre manière de faire et que du coup, je n'arrive pas à tout saisir. Pour moi Zelda, c'était des tuiles et non des écrans :p

[Aspic]

Je dois dire que je suis totalement perdu dans votre manière de faire et que du coup, je n'arrive pas à tout saisir. Pour moi Zelda, c'était des tuiles et non des écrans :p

EUh pas forcément, on peut préparer les maps avant et après la charger

Voici une image contenant 4 zones d'une ville :
http://www.tutoworld.com/temp/2.bmp

Donc la taille d'une zone est de 160 par 112px

[LittleWhite]

EUh pas forcément, on peut préparer les maps avant et après la charger

Oui très certainement. C'est juste que j'avais plus une logique tuile par tuile ... et non zone par zone, je dirai.
Enfin je crois que c'est ça

[gbdivers]

du coup, tu as des maps qui sont en basse résolution et qu'il va falloir redimensionner fortement, la qualité sera pourri. L'intérêt de la tilemap est de diminuer la taille (en mémoire) des maps. Chaque tile est codé sur 32 bits par exemple et représente des carrés de 16*16 pixels (ou plus) donc une taille divisée par 256. De plus, un même tile est utilisé à plusieurs endroit donc on à besoin que d'une image pour plusieurs endroit sur la map.

Pas étonnant que ta mémoire soit saturée si tu charges toutes la map sous forme d'image.
De plus, comment codes tu les informations de game play ? (zone que l'on ne peut pas traverser, zone correspondant à l'eau, etc.)

[LittleWhite]

Si je puis me permettre, je vais répondre à la question de comment ont été coder les informations des tuiles, la dernière fois (avant le redesign du projet).
Le tout avait été codé dans des fichiers images de la même dimension que les zones, avec des codes de couleurs pour indiquer le type de zone. (Un peu à la manière d'une heigh map).
Du coup, déjà que beaucoup de mémoire était en jeu, avec cette data map, il y a encore plus de mémoire utilisé.

[Aspic]

du coup, tu as des maps qui sont en basse résolution et qu'il va falloir redimensionner fortement, la qualité sera pourri. L'intérêt de la tilemap est de diminuer la taille (en mémoire) des maps. Chaque tile est codé sur 32 bits par exemple et représente des carrés de 16*16 pixels (ou plus) donc une taille divisée par 256. De plus, un même tile est utilisé à plusieurs endroit donc on à besoin que d'une image pour plusieurs endroit sur la map.

Oui je suis d'accord que niveau mémoire ca craint mais c'est plus facile à gérer car sinon il faut des matrices dans des fichiers textes qui définissent chaque zone et créer la matrice à la main c'est super long...

Pas étonnant que ta mémoire soit saturée si tu charges toutes la map sous forme d'image.
De plus, comment codes tu les informations de game play ? (zone que l'on ne peut pas traverser, zone correspondant à l'eau, etc.)

Bonne question : j'utilise des masques très utile avec Allegro.

Voilà un exemple de masque pour la map du post précédent :
http://www.tutoworld.com/temp/2m.bmp

[Anything]

Oui je suis d'accord que niveau mémoire ca craint mais c'est plus facile à gérer car sinon il faut des matrices dans des fichiers textes qui définissent chaque zone et créer la matrice à la main c'est super long...

Un Zelda sans tile.

Il te faut un éditeur de carte c'est tout. Tu n'es pas obliger de le faire, toi même. Tu peux utiliser un éditeur comme Tile Studio. Il permet de créer des scripts d'export personnalisés (ca m'avait servi avant que je ne créer mes propres éditeurs de maps et sprites pour mon jeu).

[lagwag]

Et si ce n'est pas une optimisation de gérer manuellement la mémoire, quel est l'intérêt de se casser les pieds à le faire ? Si les conteneurs/pointeurs intelligents sont aussi efficace mais en plus sont plus sur, c'est n'importe quoi de faire sans.

ca permet de controler l'ordre des creations et destruction... et d'avoir un modele de manager adapté pour chaque besoin... et de ne pas s'arracher les cheveux quand on tombe sur des cas vicieux des smart pointeurs... y a toujours un coté obscur...

Pour le dernier point, c'est aussi une question récurrente : faut-il commencer pas les choses les plus simples et sur (les conteneurs, les pointeurs intelligents) ou faut-il commencer pas le bas niveau pour maîtriser ce qu'il y a derrière ces classes ?
Mon point de vue est clair là dessus aussi : on commence par ce qu'il y a de facile et sur et on apprend les techniques avancées après.

ben à partir du moment où on a décidé d'apprendre le C++, il faut commencer par le bas niveau... faut savoir ce qu'on veut et y aller franchement... d'ailleurs on recommande toujours à un futur programmeur C++, de commencer par le C (sans s'eterniser)... il aura forcement besoin de beaucoup de rigueur pour apprendre un langage comme celui la... et les pointeurs c'est la base de la base de la base du C... y faire impasse ou contourner cette difficulté n'aidera en rien le programmeur, ca ne lui rendera meme pas service...

en revanche, si on souhaite juste faire des petits jeux par loisir ou apprendre un langage script par exemple, alors là je suis d'accord, rien ne vaut la simplicité pour avancer

[gbdivers]

On en reviens au débat stérile sur ce qu'est le C++ et comment on doit l'apprendre...

ca permet de controler l'ordre des creations et destruction... et d'avoir un modele de manager adapté pour chaque besoin... et de ne pas s'arracher les cheveux quand on tombe sur des cas vicieux des smart pointeurs... ya tjs un coté obscur...

Le fait d'utiliser des pointeurs intelligents n'est pas incompatible avec le fait d'avoir des gestionnaires de ressources et une vraie politique de gestion des objets. Cela garantie simplement leurs utilisations. A pire, cela veut dire que l'on aura 2 sécurités (le manager+ le smart pointer) au lieu d'une pour un temps de codage identique. Tu devrais aller de temps en temps sur le forum C++ pour voir les erreurs courantes des débutants. On retrouve régulièrement des problèmes de gestion de la mémoire (pointeur nu, tableau dynamiqe de style C, etc.) Leur apprendre les outils du C++ qui permet de sécuriser le code n'est pas une mauvaise chose. Et même pour quelqu'un de plus expérimenté, il est prétentieux de prétendre que l'on peut gérer les effets de bord sur des projets de plusieurs milliers de classes sans avoir de bonnes pratiques.

ben à partir du moment où on a décidé d'apprendre le C++, il faut commencer par le bas niveau... faut savoir ce qu'on veut et y aller franchement... d'ailleurs on recommande tjs à un futur programmeur C++, de commencer par le C (sans s'eterniser)... il aura forcement besoin de bcp de rigueur pour apprendre un langage comme celui la... et les pointeurs c'est la base de la base de la base du C... y faire impasse ou contourner cette difficulté n'aidera en rien le programmeur, ca ne lui rendera meme pas service...

Pourquoi s'arrêter au C et ne pas conseiller de commencer par le langage machine ? L'intérêt d'utiliser un langage plus haut niveau qu'un autre est normalement de gagner en productivité (codage, maintenance, évolution) pour un même résultat (ou tout au moins un résultat équivalent)

Tu as une vision différente que moi du C++ : pas de STL, pas de pointeur intelligent, pas de template, apprendre en commençant par le C... c'est pas du C++ que tu fais, c'est du C with class.
Ça me pose pas de problème : chacun est libre d'utiliser les fonctionnalités des langages comme il souhaite (le C++ est multiparadigme, il est fait pour ça) et donner sa vision des choses. Je n'essaies pas de te convaincre, ni même les autres lecteurs.

Le plus important est qu'ils sachent qu'il y a plusieurs approches et que les avantages et inconvénients de ces approches ont déjà été largement discuter sur les forums C et C++. Libre à eux de se renseigner et de faire leurs propres opinions. Tu as dis de ne pas utiliser de pointeurs intelligent. J'ai dis de les utiliser. A Aspic maintenant de se renseigner pour savoir les avantages et inconvénients de ces outils et coder comme il le souhaite.

EDIT : juste pour information pour Aspic sur l'utilisation de base des pointeurs intelligents. La plupart du temps, on peut utiliser le shared_ptr (boost ou c++11) :

Code :

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

1
2
3
shared_ptr<A> a = make_shared<A>(param1, param2);
// au lieu de :
A* a = new A(param1, param2);

[Aspic]

Salut à tous,

Donc tout d'abord, je vous donne la version DEMO complète de mon jeu :
http://www.tutoworld.com/temp/projet_zelda_2011.zip

Maintenant, je compte refactorer le code et la conception puisque mon premier objectif a été atteint : faire un jeu jouable style Zelda

C'est pour cela que j'ai acheté un livre "Design Pattern - Tete la Premiere" que je lis actuellement pour être moins bête sur les pattern qui me seront très utile dans mon projet.

Si vous le voulez bien, j'aurais besoin de votre aide niveau conception (vous le savez déjà ce n'est pas mon point fort ) donc je compte uploader par mal de version histoire que vous me disiez si je suis sur la bonne voie ou pas niveau conception.

Et pour commencer, voilà la première version (je repars de zéro) qui contient les classes suivantes :
+ GameEngine => moteur de jeu
+ Game => gère le jeu en lui même
+ Input => interface qui gère les I/O utilisateur
---+ InputKeyboard => gère le clavier
---+ InputJoystick => gère le joystick
+ InputManager => enregistre/désenregistre une classe de Type Input

+ Logger => le fameux logger de LittleWhite ^^

Rapport Valgrind :

==2089== HEAP SUMMARY:
==2089== in use at exit: 21,300 bytes in 399 blocks
==2089== total heap usage: 7,848 allocs, 7,449 frees, 399,491 bytes allocated
==2089==
==2089== Searching for pointers to 399 not-freed blocks
==2089== Checked 627,364 bytes
==2089==
==2089== 18 bytes in 3 blocks are definitely lost in loss record 10 of 59
==2089== at 0x4026864: malloc (vg_replace_malloc.c:236)
==2089== by 0x44F9942: XKeysymToString (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==2089== by 0x4132A68: _xwin_get_keyboard_mapping (in /usr/local/lib/liballeg-4.2.3.so)
==2089==
==2089== 24 bytes in 4 blocks are definitely lost in loss record 15 of 59
==2089== at 0x4026864: malloc (vg_replace_malloc.c:236)
==2089== by 0x44F9942: XKeysymToString (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==2089== by 0x41317C9: ??? (in /usr/local/lib/liballeg-4.2.3.so)
==2089==
==2089== 124 bytes in 1 blocks are definitely lost in loss record 45 of 59
==2089== at 0x4026864: malloc (vg_replace_malloc.c:236)
==2089== by 0x4629902: ??? (in /usr/lib/i386-linux-gnu/libxcb.so.1.1.0)
==2089== by 0x4629A04: ??? (in /usr/lib/i386-linux-gnu/libxcb.so.1.1.0)
==2089== by 0x46293D1: xcb_connect_to_display_with_auth_info (in /usr/lib/i386-linux-gnu/libxcb.so.1.1.0)
==2089== by 0x46295DB: xcb_connect (in /usr/lib/i386-linux-gnu/libxcb.so.1.1.0)
==2089== by 0x450CA22: _XConnectXCB (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==2089== by 0x44FC8F3: XOpenDisplay (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==2089== by 0x41437AC: _xwin_open_display (in /usr/local/lib/liballeg-4.2.3.so)
==2089==
==2089== LEAK SUMMARY:
==2089== definitely lost: 166 bytes in 8 blocks
==2089== indirectly lost: 0 bytes in 0 blocks
==2089== possibly lost: 0 bytes in 0 blocks
==2089== still reachable: 21,134 bytes in 391 blocks
==2089== suppressed: 0 bytes in 0 blocks
==2089== Reachable blocks (those to which a pointer was found) are not shown.
==2089== To see them, rerun with: --leak-check=full --show-reachable=yes
==2089==
==2089== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 52 from 13)
--2089--
--2089-- used_suppression: 52 U1004-ARM-_dl_relocate_object
==2089==
==2089== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 52 from 13)

Comme vous le voyez, il n'y a que des fuites en provenance d'Allegro donc on n'y peux rien

Il n'y a pas grand chose pour l'instant, c'est juste la gestion des touches qui est gérée, je veux vraiment y aller étape par étape ^^

Et enfin, le code source :
http://www.tutoworld.com/temp/zelda_version_1.zip

PS : il y a trois lib mais seul Allegro est actuellement utilisée (dans le répertoire ./lib)

J'attends vous retours

EDIT : Est ce une bonne idée d'encapsuler les fonctions spécifiques à Allegro, par exemple faire une classe singleton du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Allegro
{
private:
    Allegro();
    ~Allegro();
 
public:
    int loadImage(String path); // charge une image
    void destroyImage(int id); // detruit une image
    void doRectFill(...); // cree un carree
    void doTriangle(...); // cree un triangle
// ......
};

Voilà comme ca si on décide de changer de librairie, on aura pas à toucher au code du moteur de jeu
Bon j'avoue, le principe de responsabilité unique c'est pas très respecté mais bon

Vous en pensez quoi ?

Merci et bonnes fêtes !

[NevilClavain]

Comme vous le voyez, il n'y a que des fuites en provenance d'Allegro donc on n'y peux rien

Conclusion peut être hâtive
ça me parait étonnant qu'un produit aussi utilisé et éprouvé qu'Allegro comporte des fuites mémoires... Tu devrais peut être y regarder à deux fois, vérifier si ce n'est pas ton code qui serait la cause "indirecte" de ces leaks

[Aspic]

Conclusion peut être hâtive
ça me parait étonnant qu'un produit aussi utilisé et éprouvé qu'Allegro comporte des fuites mémoires... Tu devrais peut être y regarder à deux fois, vérifier si ce n'est pas ton code qui serait la cause "indirecte" de ces leaks

J'ai déjà vérifié à mainte reprise en faisant le programme allegro de base sur 4 lignes et c'est la fonction install_keyboard() qui fuit. J'ai reporté le leak sur le forum officiel et apparemment c'est connu des développeurs mais vu que la version que j'utilise n'est plus mise à jour alors ca ne sera pas corrigé

[NevilClavain]

mais vu que la version que j'utilise n'est plus mise à jour alors ca ne sera pas corrigé

Mais alors pourquoi ne pas passer à une version plus récente, dans laquelle cette fuite est corrigée (une contrainte technique particulière ????)

Et bonnes fêtes aussi, à propos

[Aspic]

Mais alors pourquoi ne pas passer à une version plus récente, dans laquelle cette fuite est corrigée (une contrainte technique particulière ????)

Et bonnes fêtes aussi, à propos

Parce que l'API d'Allegro dans la version 5 a complètement changé et je n'ai pas envie de réapprendre une nouvelle librairie. De plus, elle a aussi des fuites d'après ce que j'ai vu