Architecture v.0.4.12.31b.7843.9334.2294.28947.0694548.3832c

Bon, le code en toujours en chantier, je ne me suis même pas relu, mais commence à ressembler à quelque chose donc voilà :

xerius.nuxit.net/glouglou/ter-minmax_(2009_02_10).rar

Le système de communication entre les moteurs ne fonctionne toujours pas (quoi que, peut-être en partie, mais je n'ai rien testé). Par contre, toutes les classes relatives à la gestion des données de l'appli sont à peu près faites, et elles ont l'air de fonctionner. Je n'ai pas fait énormément de tests, vu que j'ai passé des heures à me faire chier avec SFML et VS2008 puis 2005 (pour finalement résoudre le problème en 5 min avec Code::Blocks ). Par contre, il y a tout ce qu'il faut pour que Quentin puisse bosser. Quelques explications, pour vous éviter de vous taper tout le code :

- j'ai mis dans le fichier main.cpp une fonction montrant le principal à savoir à propos de manipulation des données (il y a certains trucs que je pourrais rendre un peu plus facile d'accès d'ailleurs, je créerai des méthodes supplémentaires au besoin).

- Pour faire un chargement des données à partir des fichiers, il faut remplacer le contenu de la méthode GestionnaireDonnees::chargerDonnees(...). Pour le moment, j'ai fait un fake (4 types de terrains, 4 types d'unité, une carte avec le scénario allant avec, le tout écrit en dur dans le code :p), ce qui permettra de pouvoir avancer sur le reste de l'appli tant que le vrai chargement des données n'est pas fait. Mais Quentin, jettes-y quand même un oeil avant de tirer la chasse, vu qu'une partie du code que tu as à faire ressemble au mien (La construction des objets Partie, TypeUnite, etc...)

- Les fichiers de données sont présents dans le répertoire "donnees". Ils sont en nombre restreints, et très proches de ce que j'avais présenté dans mon post là-dessus.

- J'ai mis dans le fichier Defines.h les chemins des répertoires utiles pour le chargement du schmilblick.

Et sinon, Sébastien et Anthony, bah... Vu que ce n'est pas fini, il va encore falloir continuer un peu (ou commencer :p) à mettre votre code n'importe où. Ceci-dit, vous pouvez au moins maintenant vous appuyer sur les classes en place (GestionnaireDonnees::getInstance().getPartie() pour accéder aux données en question).

Voilà... Bonne lecture ! (ou pas )
(et bon courage si vous voulez le lancer avec Visual Studio )

Peut-on récupérer le terrain en entier ? j'ai vu un TypeTerrain getTerrain(x,y) mais pas un TypeTerrain[] getTerrain().
Parcque bon pour le a* il me faudra le terrain complet

Et une fois que tu auras le terrain complet, ce que tu feras c'est des terrain[x][y], ce qui est la même chose que partie.getTerrain(x,y) :p

Bon, c'est sûr que casser l'encapsulation du truc te ferait gagner quelques caractères... Mais c'est vraiment important ?

oui car je vais partir du terrain ac modificateur pour accélérer un poil le truc. a la création de l'objet pathfinding, il calculera les terrains pour chaque type d'unité et a la place de stocker :

map[][]
pl mt mt
pl pl ma
pl mt pl

il stockera :

mapArcher[][]
1 1.25 1.25
1 1 1.3
1 1.25 1

mapFtLourd[][]
1 1.5 1.5
1 1 1.8
1 1.5 1

par exemple. Comme ça j'aurais le terrain de base que je ne calcule qu'une fois pour toute la durée d'un scénario. puis quand je lancerais un pathfinding sur un groupe d'archet j'utiliserais la matrice de poids archer etc... Plus rapide que de demander à l'interface ce que contient la case (3,4) puis de l'oublier pour le coup de pathfinding suivant ^^

je peut faire ça en faisant une boucle pour recuprer tt la matrice au début mais vu que tu l'a déjà en un bloc autant que tu me l'envoie direct nan ?

Euuuh, ce que tu me décris, c'est un tableau de float, pas de TypeTerrain. Je n'ai rien de tel. Donc que tu ais accès au tableau de TypeTerrain directement ou via une méthode, il faudra que tu fasses un parcours dans tous les cas pour construire tes tableaux de float...

Ah ouai ok. Bon bah je ferrait un parcours alors, c'est pas ça qui me va me tuer ^^