Upload carte

[OncleJames]

Bonjour,


J'avais posté il y a de cela un moment, un peu le même problème, ayant trouvé une solution ( peu satifaisante ), j'ai préféré passer sur un autre point. Mais aujourd'hui je cherche justement à améliorer ce petit bout de code qui montre bien vite ses limites.

Le but est de partir d'une image ( bmp,png, ou autres ) qui correpond à une carte et d'arriver à insérer dans la base de donnée un codage de terrain par exemple vert = plaine, orange = montagne, jaune = desert, ..

Actuellement je suis obligé de prendre les images en .bmp pour garder le pixel par pixel et éviter tout dégradé de couleur.
Je récupère la couleur du pixel à l'aide de imagecolorat, je compare avec un switch, sa correspond à la couleur plaine, j'insère plaine, etc .
Cela répété pour chaque pixel avec un for.

La limite de ce script apparait bien vite :
Carte de jeu trés simple ( à moins d'y passé la semaine pixel par pixel )
Un dégradé de couleur, non reconnaissable
Temps de travail pour trouver les couleurs de chaque terrain, les noter, .. long
Beaucoup d'erreurs de case lors de l'insertion des données dans la base de donnée

Donc je suis à la recherche d'une méthode différente, peut être est ce ma facon d'aborder le problème qui ne va pas, je ne sais pas, une méthode ou le départ est une image et l'arrivée l'insertion des terrain dans la base de donnée.
Quand au milieu, je suis ouvert pour tester toutes méthodes proposées.

Merci d'avance

Bonne soirée

OncleJames

[Bob le Pointu]

Ça ne me semble pas mauvais comme méthode, peut-être un peu long si ta carte est longue.

Mais en tout cas, on peut l'améliorer.

Premier point, la création de la carte. Il existe pas mal d'algorithmes de génération de terrain naturel, ça peut peut être t'aider pour le début, à toi ensuite de placer les bâtiments.

Je me souviens d'un article dans un vieux magasine qui expliquait la façon dont ça marchait pour Civilization, mais impossible de le retrouver.

Donc, en attendant, tu peux essayer la technique du Perlin Noise (en).

Tu peux peut-être aussi utiliser un autre format d'image plus léger, ou utiliser ton propre format de fichier.
En l'occurence, si tu travailles avec une profondeur de 24 bits, cela signifie que tu peux avoir environ 16 millions de couleurs, soit 16 millions de types de terrain différents. Ca me semble énorme, donc je pense que 8 bits suffiraient.

Second point, l'insertion. Chaque pixel peut donc être codé sur une valeur numérique, allant de 0 à 255, il suffit que cette valeur numérique corresponde à l'identifiant de ton terrain pour pouvoir gagner du temps en évitant de faire un switch.

----
Tu peux gagner énormément de temps avec un format purement binaire où chaque octet serait l'identifiant de ton type de terrain. Plus besoin de calculer la couleur du pixel, il suffit de lire la valeur de l'octet.

[Ludvig]

Tu peux dabord créer ta carte en couleurs indexés comme ça tu pourra pas faire des dégradés.

Ensuite convertisse en BMP 24/32 bits quand tu veux l'inserer.

[Zamentur]

Second point, l'insertion. Chaque pixel peut donc être codé sur une valeur numérique, allant de 0 à 255, il suffit que cette valeur numérique corresponde à l'identifiant de ton terrain pour pouvoir gagner du temps en évitant de faire un switch.

Et meme si l'identifiant est different rien ne t'empeche d'utiliser les tableaux array en faisant correspondre id_couleur => id_terrain

Carte de jeu trés simple

Il y a des outils d'edition d'image qui permetent un beau rendue, evidement un rendue en Bitmap demande un grand Bitmap...
Il ya notament ce tuto http://www.jeuweb.org/board/showthread.php?tid=1202
Je sais pas si çà peut aider, mais effectivement là çà fait une trés grande map!

-Un dégradé de couleur, non reconnaissable
-Temps de travail pour trouver les couleurs de chaque terrain, les noter, .. long

Rien ne t'empeche de dire que tout les rouges represente tel terrain... Et ainsi aller plus vite dans la generation de l'image qui sert à decrire la map!
composante rouge entre 200 et 250, verte entre 0 et 100, bleu entre 0 et 100 (evidement j'ai mis au pif faut trouver les bon reglage)
Et en plus çà te permet de garder un visuel avec dégradé
[/quote]

Beaucoup d'erreurs de case lors de l'insertion des données dans la base de donnée

là çà doit etreun bug tout betement, je ne vois pas pourquoi il y aurrais ce genre d'imprecision!

Et sinon moi aussi je pense que tu as la bonne methode à moins bien sur de pousser la technique beaucoup plus loin:
- generation aleatoire (déjà dit)
- generation carte vectorielle (ou assimilé) (ainsi tu peux faire des dégradée, mais çà change tout ton systeme de jeu). L'idée est donc de faire disparaitre le damier.
Ces 2 points demandent de creer un outil d'edition de la map

[OncleJames]

Le problème quand je parlais de dégradé vient lorsque qu'un pixel ne correspond pas à la couleur exacte ( sous photoshop par exemple, il crée lui même des petits pixels de couleurs différentes.

Je n'ai pas énormément de terrain ( dizaine ) mais sa demande une précision extrême lors de la réalisation de la carte.

Paint est bien pour le pixel par pixel mais travailler sous paint n'est pas vraiment tip top :glace:

[Harparine]

Justement, la proposition de Zamentur est bonne pour t'éviter ce travail de précision (j'écrivais une réponse plus ou moins similaire quand il a posté) : l'idée est de mettre en place une certaine "tolérance" dans la reconnaissance de la couleur.

Personnellement, je crois que je convertirais aussi le résultat de imagecolorat en RVB pour jouer avec des intervalles de valeurs. Je me suis justement amusé à faire quelques tests sur la couleur. Par exemple, ici, la couleur de référence correspond à R : 60, V : 60 et B : 200. Après j'ai joué avec -30 ; +30 max sur chacune des trois couleurs et ça me donne une plage de couleurs plus ou moins similaires sans être parfaitement égales :


Après, il faut jouer avec les couleurs pour arriver à quelque chose de sympa...

[OncleJames]

J'avais pas vu pour le RVB. Je vais essayer cette méthode et je posterai le résultat.