Il reste quelques taches a effectuer :
- Des bugs si on change les options pendant une partie.
- Les pieces sont stockées dans un tableau *TabSet[8][8] de type Cpieces. L index du tableau correspond là où une piece est sur l'echiquier (donc le tableau n'est jamais plein). Je me renseigne pour creer dynamiquement des pieces et stocke leurs positions dans une structure.
- Pas de moteur de jeu, pas de promotions, pas de roc, dans d'echec au roi... pour le moment.
- En cours de portage sous directgraphics.
C'est la premiere fois que j utilise la compilation séparé et j aimerai votre avis sur la facon dont j ai procede : toute les variable utilise dans main.cpp sont déclaré dans main.h, et si j ai besoin d une de ces variables dans un autre .cpp, je la redeclare en extern dans le .h correspondant.
J aimerai aussi votre avis sur les classes, j ai fait une classe Piece avec toute les fonctions de base (GetIndexX, GetIndexY par expemple renvoie l index d'une piece (entre 0 et 7, le coin superieur gauche de l echiquier a un index 0;0). et une fonction virtuel SetMatrice pour chaque classe derivée où les pieces choissisent leur destination spécifiquement celon leur type.
Conclusion :
J aimerai votre avis sur le code en general...
6 oct. 2006 à 02:36
Une petite precision sur la "philosophie" des fichiers "foo.c" "foo.h" :
Dans le "foo.h", on met tout ce qui peut être utile aux autres modules qui veuleut utiliser ce qui est dans "foo.c", on va donc y retrouver par exemple :
- les declarations de types de donnees necessaires a l'utilisation de "foo.c"
- les variables globales de "foo.c" utilisables par les autres (ex: "extern FooData data;")
- les prototypes des fonctions de "foo.c" que les autres modules peuvent utilises (ex: "int foo (int arg1);"
- et des constantes, des macros, voir les "#include" necessaires a l'utilisation du module
Dans le "foo.c", on met le code et toutes les donnees necessaire a la bonne execution de ce code, on y retrouvera entre autre :
- un '#include "foo.h"' pour recuperer ce qu'on a deja dedans ;-)
- l'instance des variables globales du ".h" (ex: FooData data)
- les fonctions proposees dans le ".h" (ex: "int foo (int arg1) { return arg1*2; }")
- et toutes les donnees et fonctions "internes" utiles qui pour bien faire seront explicitement declarees en "static" dans la mesure ou elles n'ont pas lieu d'etre appelles de l'exterieur si on ne les a pas rendues visibles dans le ".h"
ET si on fait du C++, on met tout ca dans des "class" et des "namespace" pour faire moderne :-P
Bon , je vais voir ce code tout de mem ;-)
26 avril 2006 à 21:07
22 avril 2006 à 01:39
PS : les 'extern' peuvent être locale à une fonction dans n'imoporte quel .cpp et pas obligatoirement en dehors des fonctions.
Ceci existe depuis les débuts du C (1972).
Bonne continuation...
14 avril 2006 à 20:58
j'ai pas testé mais je trouve que sur la capture le cavalier fait un peu maigrichon par rapport aux autres pieces. Sans ca niveau grafique c'est pas mal fait.
11 avril 2006 à 18:13
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.