Pygame pour les zesteurs

Salut ! ce que tu cherches est ici Le fichier n'est pas donné, mais il y a tout ce qu'il faut mettre dedans je crois

Salut,

je me suis mis à lire ton tutoriel ce matin et je remarque une imprecision qui me semble plutôt importante dans la partie "gestion des événements" :

pygame.event.poll, lui, nous retourne seulement un Eventtype instance, donc un seul événement depuis la queue

pygame.event.wait retourne aussi un Eventtype instance, donc toujours un événement depuis la queue

Pourquoi Pygame dispose de deux méthodes faisant exactement la même chose ?

Hé hé ! Ces méthodes ne font pas totalement la même chose, elle ne font que retourner le même type d'objet

Si on se penche sur pygame.event.poll (allez, penchez-vous encore plus bas !), on verra que celui-ci va occuper notre processeur, même si aucuns événements ne se sont produits !

[…]

Vous comprenez la différence maintenant ?

Si vous ne voulez pas utiliser tout le processeur de l'utilisateur, alors utilisez pygame.event.wait, sinon si vous vous en fichez, prenez pygame.event.poll !

On pourrait comprendre que la seule différence entre pygame.event.poll et pygame.event.wait est la consomation de ressources (dans ce cas à quoi sert pygame.event.poll ?). Or, ce n'est pas le cas. La vrai différence c'est que pygame.event.wait bloque l'éxecution du programme en attendant qu'un événement survienne alors que pygame.event.poll se contente de récupérer le premier événement dans la pile.

Jespar

PS: moi j'aime bien les smileys

Salut ! J'ai cliqué qu pif dans le sommaire du tuto (c'est de la relecture sélective ) et je suis tombé ici. C'est l'introduction de la deuxième partie. Je pense que le paragraphe sur minecraft aurait sa place dans la partie sur le module sprites, là ça fait un peu décousus.

Salut,

Pour ta partie concernant freetype, il va y avoir une erreur à l'exécution de l'exemple, car tu n'importes pas le module :

En même temps, concernant pygame.freetype.init, il est marqué :

Donc tu n'es pas obligé d'initialiser explicitement le module, puisque c'est fait avec ta première ligne :

1
2

pygame.init()
pygame.freetype.init()  #Peut être enlevé

Je t'en prie.

Ouais, mais c'est aussi dit que ça n'aura aucun effet si tu les initialises plusieurs fois (même après avoir fait un pygame.quit()), donc après si tu veux être sûr que le module a bien été initialisé, autant vérifier au lieu de l'initialiser deux fois voire plus. Tu peux le faire en vérifiant la seconde valeur (le nombre d'échecs) de la liste retournée par pygame.init() (qui initialise tous les modules importés) et tu peux aussi vérifier à l'aide des méthodes comme was_init() si le module a bien été initialisé. Ou bien, puisque tu les charges manuellement, tu peux savoir s'il y a un problème avec les exceptions que ça peut générer. Si ce n'est pas déjà fait, je pense que tu devrais d'ailleurs parler des façons de contrôler si le chargement s'est bien passé ou non.

Voilà, cela explique pourquoi je préfère opter pour initialiser manuellement ou bien initialiser globalement. Après, c'est vrai qu'il vaut mieux être le plus explicite possible dans ce genre de tutoriel.