HELP créer un niveau via une image

Bonjour à tous,

J'aimerai générer des niveaux dans mon jeu, de façon aléatoire, mais basé sur des images (ou des chunks). En gros, l'idée serais de créer une image d'un certaine taille, qui correspondrais en faite, à un morceau de niveau. J'utilise par exemple un code couleur, pour dire que, tout ce qui est en noir, correspond à un mur, et le vert, du vide, admettons.

Et donc, le soucis, c'est que je ne sais pas comment récupérer ce genre d'information sur une image pour pouvoir ensuite, les mettre dans un grid afin de faire ce que je veux. Conclusion, ne sachant pas trop par ou commencer, je sollicite votre aide.

Merci d'avance

Il faut balayer t'on image avec un retour de couleur.

Code:

//Level_create()
draw_sprite(spr_level,0,0,0)//Affiche l'image
screen_refresh()//Rafraichi l'ecran pour voir l'image
for(Y=0;Y<height;Y+=block_size)//Balaye en vertical
{
  for(X=0;X<width;X+=block_size)//Balaye en horizontal
  {
     col=draw_get_pixel(X,Y)//retourne la couleur de ton pixel
     switch(col)//créer les objets en fonctions de ta couleur de pixel
     {
        case c_black: instance_create(X,Y,o_wall) break
        case c_white: instance_create(X,Y,o_cequetuveu) break
        case c_green: instance_create(X,Y,o_cequetuveu2) break
     }
  }
}

C'est la solution simple mais draw_get_pixel() ext tres lent!

Merci pour ton aide.

Attention, avec GM, *_get_pixel c'est très lent... A utiliser avec parcimonie, seulement lors des temps de chargement...

J'ai déjà utilisé draw_get_pixel et effectivement, y'en a pour plusieurs minutes sur une grande image.
Tu ferais mieux de te baser sur une bitmap.

Mass a écrit:

J'ai déjà utilisé draw_get_pixel et effectivement, y'en a pour plusieurs minutes sur une grande image.
Tu ferais mieux de te baser sur une bitmap.

Effectivement, il y a aussi cette solution pour les grandes images.

Je pense qu'une DLL en C qui retourne la couleur d'un pixel ne devrais pas être compliquée à faire... Il en existe une mais tout les liens sont morts. Même sur le site gamemaker.cc

EDIT: http://gmc.yoyogames.com/index.php?showtopic=455787 <= une DLL qui retourne la couleur d'un pixel aussi hors de la fenêtre GM.

Pas dit que la DLL soit plus rapide bien au contraire, à tout les coups elle fait un screen de l'image avec BitBlt pour chopper le pixel, ce qui est très long...

EDIT : puis 16 bits par canal c'est quoi le délire ?

Bon et bien j'ai réussit à faire ce que je voulais. Je me base sur une image (chunk) de 32x32. Ensuite je créer mon level en me basant sur un grid. La room fait la taille du chunk, multiplier par 32, comme ça, une case de 1px sur mon chunk correspond à une case de 32x32 px dans ma room, qui me permet de positionner mes tiles, aux aussi de 32x32. Ensuite j'ai intégré mon petit système d'autotile, et hop, voila le résultat:





Et juste une instance dans la room.

Super

Ah ben c'est très bien comme ça ! Ça me rappelle le système qu'a planet centauri pour les donjons

merci à vous . je dois dire que je suis très enthousiaste depuis que ça marche, car je bosse dessus pour l'améliorer petit à petit, et j'avance bien sur mon petit projet.

Actuellement, j'ai un chunk uniquement conçu pour le spawn du player, et le reste du niveau sur une map de test de 4096 sur 4096 pixels. Le seul problème qu'il faudra que j'arrive à régler si possible, c'est de ralentir le temps de latence lors du chargement de la map. Car plus la map est vaste, et plus le loading est ........... crade !!

Je dirais même, le système de starbound ...

Après, c'est surtout un entrainement pour moi, afin de mieux comprendre comment fonctionne tel ou tel mécanique de jeu. je dois avouer que la génération aléatoire c'est assez difficile à faire correctement.

Charger tous les chunks en mémoire n'est de toute façon pas une solution viable dans un openworld. Ca finit par prendre trop de place si la map est trop grande.

La solution commune est de charger les chunks en live, de façon à ne garder que ceux actifs en mémoire. Le problème dans ton cas, c'est que ton chargement est très long, et GM ne supporte pas les threads.
Ce qui peut être faisable, c'est de charger un chunk "au long cours" : au lieu de faire une boucle qui charge tout d'un coup, tu fais X itérations par step. C'est plus long mais c'est transparent pour le joueur.
Par contre j'ai pas dit que c'était simple

Si les chunks sont assez petits même sous GM tu peux les charger en live sans trop de soucis.
Bon par contre le format 'image' est peut être pas le plus adapté.

Il y a bien longtemps j'avais fait un moteur de pokemon et j'utilisais des chaines de caractères (ça au moins GM les gère rapidement).
Et donc j'avais fais un programme qui convertissais mes maps en texte, pour ensuite utiliser ça tranquillement.

Mass a écrit:

GM ne supporte pas les threads.

Nativement non mais il y a un taré qui l'a rendu possible =)
http://gmc.yoyogames.com/index.php?showtopic=390517

Ahah j'aime comme les gens galèrent a rendre GM un minimum utilisable a coup de gros sparadrap.

onilink_ a écrit:

Si les chunks sont assez petits même sous GM tu peux les charger en live sans trop de soucis.
Bon par contre le format 'image' est peut être pas le plus adapté.

Il y a bien longtemps j'avais fait un moteur de pokemon et j'utilisais des chaines de caractères (ça au moins GM les gère rapidement).
Et donc j'avais fais un programme qui convertissais mes maps en texte, pour ensuite utiliser ça tranquillement.

C'est marrant que tu en parle car depuis ce matin justement je me suis dit qu'avec des strings se sera plus sympa, et rapide surtout. Et j'ai vu que dans le source code de speluky, le dev à aussi utilisé la méthode des strings Donc je bosse dessus. Mais j'ai un peu de mal à m'en sortir pour le moment.

Après pour répondre globalement à tous, j'ai d'abord choisit de générer par rapport à une image, pour voir un peu la lenteur du truc et c'est vrai que, dés que je dépasse une map de 8192x8192 le temps de chargement et de plus en plus long.

Chez moi, en 6 secondes j'ai une map de 8192x8192, mais ça passe à 20 ou 30 secondes sur du 16384x16384 donc forcement, dans l'hypothèse ou je voudrais faire un open world, ça serais trop crado.