(21-01-2011, 03:19 PM)Argorate a écrit : Bon, alors là je pense avoir un peu plus cerné la chose.Ben niveau perf, au pire tu peux placer le rendu de tes bordures en cache (fichier, bdd, ...) ce qui permettrait de ne plus devoir refaire le calcul à chaque fois, mais dis toi que c'est jamais que des comparaisons, pour être tout à fait complet, j'ai 4 groupes de 5 comparaisons pour chaque case. Je doute que ça bouffe considérablement plus de mémoire que tout autre moteur de rendu et il est prévu, une fois qu'on est in game, d'avoir un champ de mon tableau qui comprenne directement le rendu, comme ça plus besoin de faire de comparaison ^^
Le truc c'est que je pensais pas à ce cas de figure particulier : tu part d'une map par zone comme tu dis, c'est a dire une map définit et qui est fixe (en taille), à la rpgmaker en gros. Système différent du mien, où la carte est un monde continue comme dans la réalité. Du coup, dans ton cas, tu pourrais même ne plus te faire chier a faire tes map avec l'éditeur, tu pourrais mettre un fond qui est une seul image pour chaque zone et c'est terminer, mais bon on perd la possibilité de changer dynamiquement les terrains in game (après ça dépend de se qu'il est possible de faire ou non dans ton jeu, mais si les terrains ne peuvent être modifié dans le GP, ça peut être une solution).
Sinon effectivement ton découpage en 4 avec plusieurs possibilités pour les 4 quart me plait bien, je trouve que c'est judicieux.
Mais du coup, en résumé, ta méthode c'est le calcul : tu as un algo qui regarde pour chaque case ce qu'il y a autour et qui met les bords en conséquence (tu me dit si je me trompe ).
J'avoue que je chercher justement un moyen de substitution à cette méthode qui dois être fastidieuse à coder - mais qui une fois fait doit être un vrai régal, je l'avoue ^^
Faut coder tous les cas de figure, c'est assez chian non? Et de point de vue performance, ça n'alourdir pas trop le rendu, quand la map s'affiche si a chaque case il faut faire une moulinette pour regarder autour?
En tout cas y a de l'idée, mais j'avoue clairement que devoir coder un éditeur en sachant déjà tout ce qui me reste a coder m'enchante guère, limite me décourage pour l'instant.
Voilà exactement le passage avec les comparaisons :
if($content == $sN && $content != $sW) {
$aReturn[] = 'i';
}
elseif($content != $sN && $content != $sW) {
$aReturn[] = 'a';
}
elseif($content != $sN && $content == $sW) {
$aReturn[] = 'c';
}
elseif($content == $sN && $content == $sW && $content != $sNW) {
$aReturn[] = 'q';
}
elseif($content == $sN && $content == $sW && $content == $sNW) {
$aReturn[] = 'k';
}
if($content == $sN && $content != $sE) {
$aReturn[] = 'l';
}
elseif($content != $sN && $content != $sE) {
$aReturn[] = 'd';
}
elseif($content != $sN && $content == $sE) {
$aReturn[] = 'b';
}
elseif($content == $sN && $content == $sE && $content == $sNE) {
$aReturn[] = 'j';
}
elseif($content == $sN && $content == $sE && $content != $sNE) {
$aReturn[] = 'r';
}
if($content == $sS && $content != $sW) {
$aReturn[] = 'e';
}
elseif($content == $sS && $content == $sW && $content == $sSW) {
$aReturn[] = 'g';
}
elseif($content != $sS && $content != $sW) {
$aReturn[] = 'm';
}
elseif($content != $sS && $content == $sW) {
$aReturn[] = 'o';
}
elseif($content == $sS && $content == $sW && $content != $sSW) {
$aReturn[] = 's';
}
if($content == $sS && $content == $sE && $content != $sSE) {
$aReturn[] = 't';
}
elseif($content == $sS && $content != $sE) {
$aReturn[] = 'h';
}
elseif($content != $sS && $content != $sE) {
$aReturn[] = 'p';
}
elseif($content != $sS && $content == $sE) {
$aReturn[] = 'n';
}
elseif($content == $sS && $content == $sE && $content == $sSE) {
$aReturn[] = 'f';
}
Et dans aReturn j'ai le code bordure (les lettres correspondent aux classes générées dans le fichier css ^^).Sinon, j'utilise sur ma carte actuelle un système avec des images en fond sur toute une zone, alors certes c'est pratique, mais c'est lourd à modifier (dépendance externe) et ça rend le contenu du jeu très statique. Sans parler du poids des images qui peut être handicapant ou alors faut compresser et appauvrir les couleurs (ce que je fais). Avec le système actuel, je conserve qualité et rapidité. Mes 20 images par tuile font 10k, donc si j'ai 20 tuiles différentes, ça me fait 200k à charger "une" fois (avec un petit loader javascript pour faire pro xD), pour avoir une carte plutôt sympa et qui se charge rapidement. Les interfaces de Motion Twin, et notamment leurs applications flash, font souvent plus de 1Mo ^^
Concernant le fait que c'est une carte infinie, ça n'est problématique que si tu n'as pas de mapping des zones. On pourrait imaginer que tu aies une sorte de "cartographie des zones" qui indique à ton script quel zone il doit charger si il se trouve à tel endroit de la carte. Moi j'ai pas besoin de mapping vu qu'un bête calcul en fonction de la largeur et de la hauteur de map me permet de savoir qu'en [39-10] on est en zone 10 (par exemple). Enfin, de toute façon, les fichiers ne sont pas la seule solution et comprennent quelques soucis, notamment niveau de l'exclusivité en écriture, mais ça c'est pour plus loin, quand y a beaucoup de modifications successives.
Faut aussi faire le rapport entre investissement et intérêt ludique. Etant donné que je voulais recentrer la v1 de Terres de Cy autour de la carte, je m'y suis consacré à fond, avec gestion des niveaux, possibilité de placer des villes, des routes, etc. Mais je pense que ça vaut le coup "in fine".
Je suis revenu globalement trois fois en profondeur sur mon module de carte et là je pense que je tiens le bon bout niveau qualité, automatisation et compression du retour ajax.