Quelle est la différence entre les collisions gérées par les objets et les collisions gérées par les sprites ?
J’ai bien compris que l’un utilise les masques de collision et que l’autre serait “au pixel près”.
Mais j’ai l’impression qu’il n’y a pas que ça …
Je viens de m’en apercevoir dans mon projet :
lorsque j’essaie de détecter la collision entre deux sprites, il ne se passe rien (mon sprite ne change pas de couleur)
lorsque j’essaie de détecter la collision entre deux objets (avec masques de collision définis manuellement), j’ai la réaction attendue (le sprite change de couleur).
Je n’ai rien changé d’autre dans mon code, en dehors de la condition de collision (sprite remplacé par objet).
Je me demande donc dans quels cas il faut privilégier l’un à l’autre ?
Si tu as deux objets de types différents ( qui ne sont pas tous les deux des Sprite )
ou
Si tu as deux Sprite mais que tu ne veux pas de précision extrême au niveau du test de collision
ou
Si tu as deux Sprite mais que tu souhaite utiliser leur masque de collisions.
Alors, la collision entre objets est pour toi.
( En fait, le principe de cette collision est qu’elle s’appuie sur les masques de collision, comme indiqué dans l’éditeur d’évènements quand elle est affichée. Les masques de collisions pouvant être définis par tout type d’objets, cela explique qu’elle fonctionne donc pour tous les objets ).
Si tu as deux sprite et que tu souhaite une précision au pixel près, utilise alors la collision entre Sprites.
Il y a un bug actuellement ( mais qui est corrigé pour la prochaine version ) qui fait que, pour toutes les actions de collisions, la collision entre deux mêmes objets n’est pas detectée ( Collision entre Rond et Rond ne renverra pour le moment jamais vrai même si deux Ronds se touchent, c’est donc un bug ).
Mais les conditions de collisions marchent sinon bien : Que tu fasse Collision entre MonObjet1 et MonObjet2 avec la condition relatives à tous les objets ou relative aux Sprites, il ne devrait pas y avoir de soucis.
Mes deux sprites sont différents. Et si j’utilise la collision entre sprites, il ne se passe rien. C’est pour ça que ça m’interpelle, comment se fait-il qu’une collision censée être plus précise ne se déclenche pas ?
Aucun souci avec les masques de collision, en revanche.
Au fait, quand tu dis “pixel près”, c’est l’ensemble des pixels de l’image ou seulement les pixels non transparents ?
Un pixel transparent n’est pas pris en compte lors de la collision entre Sprites. Par contre, dès que la transparence du pixel n’est plus égale à 0 ( ça peut se vérifier avec un logiciel d’édition d’image qui gère la transparence ), le pixel est pris en compte dans la collision.
Peut être peut tu mettre en ligne un petit jeu de test qui fait intervenir la collision entre deux objets Sprite qui ne marche pas.
Mais c’est vraiment étonnant, car je teste assez systématiquement le bon fonctionnement de cette condition, rien qu’en lançant un jeu pour tester diverses choses après avoir apporté une modif au logiciel.
C’est intéressant, ça.
Ca veut dire que GD construit un masque de collision correspondant au sprite, aussi complexe soit-il. Normal que ça bouffe des ressources si le sprite possède plusieurs zones transparentes.
Mes sprites sont censés avoir un canal alpha correctement renseigné. Les interactions avec les lumières ont bien lieu par exemple (et ne suivent malheureusement pas les masques de collisions, dommage).
Je t’enverrai mon projet dès que j’aurai pu en tirer une version stable.
Tu en profiteras pour jeter un oeil sur mes plantages à répétition, toujours entre 500 Mo et 1500 Mo de mémoire vive.
Ben oui, la dernière mise à jour n’a rien résolu de ce coté là …
En fait, la condition de collision des Sprite teste un par un tous les pixels, en sautant ceux qui sont transparents.
J’ai corrigé un (assez gros) problème de fuite de mémoire qui a lieu à chaque compilation en interne des évènements ( c’est à dire assez souvent ). Je sais pas si c’est lié, mais ce problème pouvait mener GD à occuper une place faramineuse en mémoire et à se faire donc violemment fermer ( =éclater la tronche ) par le système d’exploitation.
J’ai aussi vu que tu redimensionne souvent tes images en jeu : Attention à éviter d’utiliser des images trop grandes. Utiliser des images trop grandes va très vite encombrer la mémoire, notamment celle de la carte graphique, et donc diminuer les performances du jeu. Autrement dit, mieux vaut utiliser dès le départ des images d’une taille adaptée au jeu.
Mon projet tourne en 800x600, les images ne dépassent les 1000x1000 pour les plus grosses. 32 Mo dans le dossier images du jeu. A peu près pareil niveau bruitages.
Mes plantages surviennent dans 90% des cas lorsque je passe du mode apercu au mode edition. Ca plnate également lorsque je modifie un objet dans la liste des objets et que GD rafraichit la fenêtre. Pour esquiver ce problème, j’utilise une scène vide pour modifier mes objets, et je travaille sur une scène de test avant d’implémenter mes évènements externes dans une scène réellement utilisée ingame.
La conso de mémoire vive gonfle à chaque prévisualisation. Et elle ne se réduit pas lors du retour à l’édition.
Je remarque aussi que sous un i3 avec Intel Graphic card, le plantage occure systématiquement à 1500 Mo, mais avec un i3 + nVidia 250, le plantage survient à 450-500 Mo. Les deux tournent sous Win7 x64.
EDIT :
A noter aussi, l’augmentation de conso mémoire n’a lieu que lorsqu’il y a “compilation en cours”. La conso mémoire reste fixe tant que les évènements n’ont pas été modifiés.
Oui, c’est bien les symptômes de la fuite de mémoire importante dont je parlais dans mon précédent message et que j’ai donc enfin corrigé, non pas sans mal.
Je garantis pas que ça résoudra les problèmes, mais si tu as remarqué que les plantages arrivent pour une consommation mémoire assez systématique suivant le système, il y a des chances que ce soit lié.
J’essayerai de mettre une version corrective en ligne d’ici pas trop longtemps.
