« Pygame/Guide du débutant » : différence entre les versions
Contenu supprimé Contenu ajouté
m Formatage, ajout de code |
|||
Ligne 29 :
* apprenez comment convertir les nombres en chaînes et inversement.
* Venez-en au point où la syntaxe d'utilisation des listes et des dictionnaires est une seconde nature : vous ne devez pas avoir besoin de lire la documentation à chaque fois que vous avez besoin de découper une liste ou de trier une série de clés de dictionnaire.
* Résistez à la tentation d'utiliser une mailing liste, <
* Au lieu de ça, saignez votre interpréteur et jouez avec le problème quelques heures.
* Imprimez le [http://rgruet.free.fr//#QuickRef guide de référence rapide] de Python et gardez-le près de votre ordinateur.
Ligne 41 :
== Règle 3 : comprenez ce qu'est une Surface ==
La partie la plus importante de Pygame concerne la manipulation de surfaces. Imaginez-vous qu'une surface n'est qu'un morceau de papier blanc : vous pouvez dessiner des lignes dessus, remplir certaines parties avec de la couleur, et y copier ou en extraire chaque valeur des pixels qui la constituent. Une surface peut être de n'importe quelle taille (dans la limite du raisonnable) et vous pouvez en manipuler autant que vous voulez (toujours dans la limite du raisonnable). Une seule surface est particulière : celle que vous créez avec la fonction <
Donc, comment créer des surfaces ? Comme mentionné ci-dessus, vous créez la surface spéciale ''surface d'affichage'' avec <
La plupart des fonctions de manipulation de surface ne sont pas d'une utilité critique. Apprenez seulement <
== Règle 4 : utilisez ''surface.convert()'' ==
Quand j'ai commencé à lire la documentation de <
Le ''format'' auquel <
Comment devez-vous utiliser <
<source lang="python">
Ligne 65 :
</source>
C'est simple, vous avez besoin de ne l'appeler qu'une seule fois par surface, lorsque vous chargez votre image depuis le disque et vous serez enchanté des résultats. J'ai remarqué un gain de performance sur les blits de l'ordre de 6x en utilisant la fonction <
Les seules fois où vous ne voudrez pas utiliser la fonction <
== Règle 5 : l'animation par ''dirty_rect'' ==
La cause principale d'un taux d'images inadéquate dans un programme Pygame résulte d'un malentendu sur la fonction <
;pygame.display.update()
Ligne 80 :
: Cette dernière actualise uniquement les zones rectangulaires de l'écran que vous avez spécifiées.
La plupart des personnes débutantes en programmation graphique utilisent la première : ils mettent à jour la totalité de l'écran à chaque image. Le problème est que c'est inacceptablement lent pour la plupart des personnes. Appeler <
La solution est appelée ''dirty rect animation''. Au lieu d'actualiser l'écran entier à chaque image, seule la partie qui a changé depuis la dernière image est actualisée. J'obtiens ceci en suivant ces rectangles dans une liste, ensuite j'appelle <
# Blit une partie de l'arrière-plan sur l'emplacement actuel du sprite, ce qui l'efface.
# Ajoute le rectangle de l'emplacement actuel du sprite dans une liste appelée <
# Déplace le sprite.
# Dessine le sprite sur son nouvel emplacement.
# Ajoute le nouvel emplacement du sprite sur ma liste de <
# Appelle la fonction <
La différence de vitesse est stupéfiante. En considérant que [http://www.pygame.org/shredwheat/solarwolf/ Solarwolf] possède des douzaines de sprites en mouvement mis à jour de façon fluide et qu'il lui reste encore assez de temps pour afficher un champ d'étoiles en ''parallax'' en arrière-plan et l'actualiser lui aussi.
Ligne 99 :
== Règle 6 : les surfaces matérielles engendrent plus de problèmes que d'avantages ==
Si vous avez étudié les différents drapeaux utilisables dans la fonction <
Malheureusement, l'accélération matérielle engendre une longue liste d'inconvénients :
Ligne 121 :
== Règle 8 : les Rects sont vos amis ==
L'enveloppe de Pete Shinner (Pygame) peut fournir de beaux effets de transparence et de bonnes vitesse de blit mais je dois admettre que ma partie préférée de Pygame est la modeste classe <
<source lang="python">
Ligne 131 :
</source>
Si vous utilisez une des trois premières versions, quelle qu'elle soit, vous aurez accès aux fonctions utilitaires des <
Par exemple, je suppose que j'aimerais obtenir une liste de tous les sprites qui contiennent le point <
<source lang="python">
Ligne 139 :
</source>
Les <
== Règle 9 : ne vous tracassez pas avec une détection de collision au pixel près ==
Ligne 148 :
# Pour chaque pixel qui se chevauche avec un autre, voir si les pixels correspondant des deux sprites sont opaques. Si oui, il y a collision.
Il existe d'autres solutions, en ajoutant des masques de sprites, mais comme vous devez le faire dans Pygame, ce sera probablement trop lent. Pour la plupart des jeux, il sera préférable de tester une collision de ''sous-rect'' : en créant un <
== Règle 10 : gestion du sous-système d'évènements ==
Ligne 154 :
Le système d'évènements de Pygame est quelque peu complexe. Il existe en fait deux manières différentes de savoir ce que fait un périphérique d'entrée (clavier, souris, joystick).
Le premier est de contrôler directement l'état du périphérique. Vous réalisez ceci en appelant <
La seconde méthode utilise la file d'évènement de la SDL. Cette file est une liste d'évènements : les évènements sont ajoutés à la suite de la file lorsqu'ils sont détectés et ils sont effacés de la file lorsqu'ils ont été consultés.
Il existe des avantages et des inconvénients pour chaque système. Le contrôle d'état (système 1) vous donne la précision : vous savez exactement quelle entrée a été effectuée ; si <
<source lang="python">
Ligne 167 :
Toutefois, dans le système de file, chaque pression de touche entre dans la file comme un évènement complètement séparé ; ainsi, vous devez vous rappeler que la touche {{Touche|T}} est enfoncée et n'a pas encore été relâchée lorsque vous contrôlez l'état de la touche {{Touche|F}}. Un peu plus complexe.
Le système d'état possède toutefois une grande faiblesse. Il rapporte seulement quel est l'état d'un périphérique au moment où il est appelé. Si l'utilisateur enfonce le bouton de la souris et qu'il le relâche juste avant que l'appel à <
La leçon à retenir est : choisissez le système qui convient à vos besoins. Si vous n'avez pas beaucoup de continuité dans votre boucle, c'est-à-dire que vous attendez une entrée, dans une boucle <
Un mot à propos de la différence entre les fonctions <
* <
* <
Toutefois, <
== Règle 11 : ''Couleur Clé'' contre ''Transparence Alpha'' ==
Ligne 180 :
Il y existe de nombreuses confusions autour de ces deux techniques et beaucoup proviennent de la terminologie utilisée.
Le blit par ''Couleur Clé'' implique de dire à Pygame que, dans une certaine image, tous les pixels d'une certaine couleur (la ''Couleur Clé'' en question) apparaîtront comme transparents au lieu de s'afficher dans leur vraie couleur. C'est de cette façon que l'on crée un sprite qui n'apparait pas dans un rectangle. Il suffit d'appeler la fonction <
La ''Transparence Alpha'' est différente et implique deux gestions différentes. ''Image Alpha'' s'applique à toute l'image et correspond probablement à ce que vous désirez. Connu aussi sous le nom de ''translucidité'', le canal alpha applique à chaque pixel de l'image source une opacité partielle. Par exemple, si vous définissez le canal alpha d'une surface à 192, et que vous le blitez sur un arrière-plan, 3/4 de la couleur de chaque pixel proviendra de l'image source et 1/4 de l'arrière-plan. Le canal alpha se mesure de 255 à 0, où 0 est complètement transparent et 255 est complètement opaque. A noter que la ''Couleur Clé'' et le blit ''Transparence Alpha'' peuvent être combinés : cela produit une image complètement transparente sur certains pixels et semi-transparente sur d'autres.
|