[Pygame] detection collision en utilisant surface.get_at

Bonjour tout le monde,
j'ai débuté avec pygame il y a deux semaines et je me suis retrouvé de faire recours en fin au gens du meilleur forum de développeurs

le premier problème est le suivant : lorsque l'utilisateur final clique pour fermer la fenètre du jeu, on obtient un message d'erreur dans l'envorinnement de pygame , qui dis que la fonction exit() n'existe pas ou quelque chose comme ça , et mème si j'utilise sys.exit() , il dis que sys ,'est pas défini , malgrès que j'ai importé exit comme suit : from sys import * !!! je ne me souviens pas exactement des syntaxes des messages d'erreur, excusez moi ...

le deuxième problème c'est que je n'arrive pas à utiliser la fonction de pygame screen.get_at((x, y)) pour savoir s'il y a une collision au point (x,y) avec un objet qui a la couleur my_solid_color par example ,

le code ressemble à ça :

Code:

---

1 2 3

position_color = screen.get_at((my_player_x, my_player_y)) if position_color == my_solid_color: dont_move_player()

---

je vous prie de bien voulior m'aider à surmonter ces problème , et je vous promet qu'il y aura d'autres problèmes à venir :D

Salut !

Je viens d'effectuer un test rapide et je n'ai aucun problème pour récupérer la couleur avec get_at. Es-tu certain de my_solid_color est identique à la couleur de ta surface (y compris l'apha) ? Tu devrais peut-être imprimer la valeur de ces deux couleurs pour voir si ce sont les mêmes.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

import pygame   pygame.init() # Surface pour l'affichage ecran = pygame.display.set_mode( (int(200), int(200)), pygame.HWSURFACE )   # Créer une surface (un carré rouge) surface = pygame.Surface((50, 50)) surface.fill(0xff0000) # On dessine la surface sur l'écran ecran.blit(surface, (0, 0))   # Test de la couleur du pixel res = ecran.get_at((10, 10)) print "Valeur du pixel testé: " + str(res) if res == (255, 0, 0, 255) :   print "Pixel rouge pur"

---

Je ne sais pas exactement ce que tu cherches à réaliser mais je te rends attentif au fait que la méthode de surface get_at n'est pas forcement idéale pour tester des collisions dans un jeu...

D'autant plus que généralement, la détection des collisions peut-être beaucoup plus frustre sans que l'on s'en rende vraiment compte dans le jeu. Je te propose de regarder la documentation sur les sprites qui permettent de tester des collisions entre objets selon une forme de détection carrée.

Si ça ne suffit pas pour ton projet, il existe des tas d'algorithmes de détection de collisions, de la forme simple d'un carré en passant par le cercle jusqu'aux polygones. Même si cela demande parfois un peu de boulot pour les implémenter ça me semble plus simple et plus rapide que de faire de la détection par pixels.

Cependant, suivant tes besoins, la collision au pixel près peut être importante. Je connais moins ce domaine mais je crois que cela se résume à créer un masque de ton image représentant le détourage de ton image. Pour chaque pixel tu écris un 0 si il est transparent et un 1 sinon. Pour tester la collision il suffit ensuite de faire un ET logique avec un autre masque et hop ^^

Au passage, sur le wiki de pygame, tu trouveras un exemple de collision au pixel près (et une utilisation de get_at en prime ;) ) : http://www.pygame.org/wiki/FastPixel...arent=CookBook

je te remercie infiniment d'avoir pris le temps d'y assister

en effet, j'ai remarqué moi aussi que le défaut est la non-satisfactoin de la condition ( position_color == my_solid_color )

je ne suis pas sùr si c'est à cause de l'abscence du paramètre alpha ( lequel je n'avais jamais pris en compte, et j'aimerai bien apprendre comment déclarer une certaine couleur , c'est à dire translucide, je sais que c'est ce que tu vien de m'écrire , mais si tu veu m'expliquer encore ... )

mais je croix que c'est à cause du fait que les deux variables ne sont pas du mème format, la première, position_color étant quelque chose en relation avec les couleurs , qui ressemble à (127,127,63) , et la deuxième, my_solid_color déclaré sous la forme d'un autre format, le Tuple , quelque chose qui ressemble à (127,127,63) !!!! :D

j'ai trouvé plus loins qu'un certain module appelé gameobjects , par Will Mc Gugan (http://www.willmcgugan.com/game-objects ) implémente une fonction color.as_tuple() qui convertit une couleur en un tuple , mais j'ai pas réussi à l'utiliser car après installation de ce module , je n'arrive pas à l'employer correctement et je reçoit des messages d'erreur , peut ètre j'ai pas su l'installer correctement , je ne suis pas sùr ...

mais ce que je vai faire plus tard ? je vai tricher , je ne déclarerai pas la couleur de l'obstacle solide comme étant un Tuple , mais plutot je vais le récupérer avec surface.get_at() à une position que je soit sùr d'ètre à la couleur réservée pour les objets solides , de la mème façon que pour la couelur de la position où le joueur est debout :D , j'éspère que ça va marcher , je vous informerai du resultat ce soir ...

sinon , si je serai obligé de faire une détection vectorielle , j'aurai affaire avec ... 8-)

je te remercie encore ami. @ plaisir ...

OK, l'idée a réussi, il suffit de récupérer my_solid_color depuis une surface temporaire qui ne sera pas affichée , et de recupérer la couleur de la position où le joueur est debout , puis faire la comparaison entre les deux variables récupérées ...

mais il faut prendre en copmpte que la méthode ( ma_surface.get_at ) risque de rendre trop lent et trop lourd le fonctionnement du jeu , surtout lorsque m_asurafce est une HWSURFACE ,

j'aimerai donc savoir si il est nécessaire que la surface principale ( screen ou ecran ) doit obligatoirement ètre une HWSURFACE , et est ce qu'elle l'est par defaut , et comment déclarer pour qu'elle ne le soit pas ....

merci d'avance !!

Bon ben si ça marche tant mieux ^^. Je reste sceptique sur la méthode mais l'essentiel c'est qu'elle remplisse tes attentes.

Par défaut, une surface créée avec pygame.set_mode( ... ) n'est pas une HWSURFACE, il faut lui spécifier un flag pour ça. Note cependant que HWSURFACE ne fonctionne qu'en plein écran.

Mais ce qui m'a décidé de ne pas inclure ce flag dans mes jeux c'est la lecture du point 7 de cet article : http://www.pygame.org/docs/tut/newbieguide.html. Il faut faire attention à plein de choses pour, au final, ne même pas être certain de voir un gain de vitesse...

Et pense aussi à utiliser .convert() ou .convert_alpha() quand tu charges tes images, cela permet de les convertir toutes dans le même "format de pixel" sinon tu risques de voir des ralentissements. Je ne le faisais pas à mes débuts et dans certains cas c'était catastrophique en matière de vitesse :mouarf:

Je tiens à te remercier infiniment Clic4 ainsi que tous ceux qui ont eu la bonté de prèter attention ou à tenter d'ètre utiles , merci , @ la prochaine ...;)