Moteur 2D - Page 2

jackiechan
: À mon avis, l'idée d'une détection de collision par pixel est à éviter...

À mon avis, c'est la seule chose qui a un sens avec une plateforme inclinée, surtout si elle n'est pas triangulaire, mais arrondie.

Je ne sais pas, c'est une source facile de bugs à mon avis.

La source de bogues, c'est ce qu'il fait. Chez lui, d'après son explication du problème, si on saute au plein milieu de la plateforme, on se retrouve magiquement sur la plateforme. (Ça ne serait pas le seul Mario avec ce bogue, même certains officiels l'ont si je me rappelle bien, mais quand-même...)

mmh peut-être qu'il suffit simplement qu'il prenne comme cas particulier lorsqu'il est en train de sauter.

Ce n'est pas si simple! J'ai retourné le problème dans tous les sens... Je ne peux pas "détecter" lorsque un cas est bon ou non.
>si on saute au plein milieu de la plateforme, on se retrouve magiquement sur la plateforme
Ben oui, mais on devrait se retrouver sur la plate-forme seulement si la position de mario+sa hauteur est supérieure à la position de la plate-forme elle même plus la valeur de son fil de fer à l'endroit horizontal où mario se trouve. Ca fait beaucoup de conditions. C'est pas facile.
mmh peut-être qu'il suffit simplement qu'il prenne comme cas particulier lorsqu'il est en train de sauter.
Peut-être. Mais ça devient un type de programmation que je n'aime pas du tout. Le genre de trucs où tu prévois tous les cas particuliers. Il faut UNE routine qui fonctionne pour tous les cas sinon t'es perdu, car il y'aura TOUJOURS des cas imprévus (qu'on appelle des bugs je crois) et là avec ce genre de programmation... on va pas loin du tout!

La source de bogues, c'est ce qu'il fait. Chez lui, d'après son explication du problème, si on saute au plein milieu de la plateforme, on se retrouve magiquement sur la plateforme. (Ça ne serait pas le seul Mario avec ce bogue, même certains officiels l'ont si je me rappelle bien, mais quand-même...)
C'est très difficile... Tout est source de bugs. Tiens par exemple j'avais essayé de faire la détection de pixel. Mais lorsqu'il y'avait un mur à droite, bien que mon dispositif DEVAIT les détecter, le mur était toujours détecté comme "en bas" du personnage... Bizarre. Et je ne sais pas comment faire. De plus, je ne comprends pas comment c'est possible de faire une détection efficace avec TestCollide...
Ca me déprime. J'espère que le ton de mes posts va parce que sinon je change hein?

Tu pourrais utiliser les balises [cite] quand tu cites du texte. Ou au moins le mettre en italique... Parce que là il faut bien se souvenir de ce que tout le monde a posté pour ne pas se perdre.

C'est vrai, désolé!

J'ai regardé. Lorsque je suis dans le bord d'une plate-forme inclinée, la valeur de répulsion vers le haut pour mario est de -16 (!). Alors qu'en plein milieu j'ai une valeur normale de entre zéro et -2. Bizarre... Et si j'enlève une protection, j'ai le personnage qui saute affreusement dans les bords...

Ca marche. J'ai réussi à rendre le support des plate-formes inclinées SANS UTILISER DE DETECTION DE COLLISION PIXEL PAR PIXEL, c'est ça qui est super.
En fait j'avais oublié une partie du code (oups). Parce que le problème qu'il y'a c'est que le perso peut avancer jusqu'à 5 (ou même plus) pixels d'un coup. Donc le moteur doit gérer ça. En général TOUS les moteurs (même commerciaux) font du pixel par pixel sinon ils ont les boules que ça ne marchera pas. Voici une image illustrant mon problème:

Donc si mario se trouve à l'emplacement en noir, en faisant un pas (si j'éxagère) il pourra se retrouver à l'endroit en rouge (j'exagère mais c'est arrivé). Dans ce cas-là, comment voulez-vous faire quelque chose de STABLE? C'est compliqué. Si je concevais ce moteur aujourd'hui je me serais immédiatement dit que c'est impossible et aurais abandonné, cependant je n'en étais pas conscient à l'époque où j'ai commencé mon (Sonic à l'époque) jeu. Et comme ce que je disais plus haut, je ne voulais pas commencer à me dire "s'il y a une plate-forme inclinée à ma gauche et une plate-forme inclinée en dessus de moi et rien en haut à gauche et rien non-plus là ou je me trouve alors je dois monter de seize pixels de manière à me retrouver sur la plate-forme inclinée du dessus". On commencerait à prévoir chaque éventualité et comme ça n'est pas possible de les répertorier toutes, ce genre de trucs devient donc la première source de bug pour un programme. (Maintenant je vois comment Micro$oft l'ont programmé leur OS, à moins que ce soit volontaire dans leur cas). Enfin bon, pour finir, le moteur gère ces cas naturellement et c'est grâce à ça qu'il n'y a pas de trop gros bugs.
Voici un autre cas désespérant:

Comment faire pour que la plate-forme ici ne soit pas détectée comme "à droite" ou "à gauche" ou même en haut (c'est mon cas) du personnage? Eh ben voilà. Je ne peux l'expliquer ici car je ne m'en souviens pas moi-même.
Sinon pour le problème sur la détection de collision, c'était un truc du type:

J'ai exagéré un peu pour bien montrer. On remarque que lorsque le perso se trouve dans un mur, celui-ci doit être repoussé. Mais dans le cas de la détection par collision je vois toujours qu'il y'a quelque chose en dessous de moi mais jamais à ma droite (et si j'inverse les conditions, il ne détecte jamais les plate-formes en dessous de moi, donc je passe pitoyablement à travers). Tu ne saurais pas d'où ça vient?

moi j'utiliserai une matrice de valeurs en parallèle au décord pour détécter les collisions (ça se fait facilement pour les murs et les sols), et les sols inclinés ne seraient qu'un cas particulier de terrain spécial qui ajouterait un modificateur aux coordonées du personnage s'ils se trouvent dans ladite zone. j'ai pas essayé mais je ne vois pas pourquoi ça ne marcherait pas ceci dit, entre la théorie et la pratique...

Effectivement. Au départ ça me semblait tellement simple! Mais en pratique.. C'est loin d'être le cas. Cependant ta théorie a du vrai. Mais brute elle ne fonctionnera pas comme il faut. Tu vois bien le nombre de cas spéciaux... Enfin faut voir. On peut pas s'ymaginer ce que c'est tant qu'on ne l'a pas essayé soi-même. Ceci dit, pour te simplifier la tâche je te conseille largement de faire du pixel par pixel et éventuellement faire un frameskip par la suite.

Moi j'ai mon moteur qui bien qu'il ne gère pas les plans inclinés marche très bien et je ne ferai jamais du pixel par pixel quoi qui'il arrive! Pas fou...

Ah bon? Pourquoi "pas fou"? A mon avis, même si c'est plus lent c'est le seul moyen d'avoir un truc valable (ou bien tu t'embêteras vraiment, surtout pour les pans inclinés)

Je n'en suis pas si sûr
M'enfin tant que je ne t'ai pas prouvé le contraire par l'exemple tu pourras dire ce que tu veux bien sûr
ceci dit je me demande comment PpHd se débrouille...

Ximoon :
Je n'en suis pas si sûr
M'enfin tant que je ne t'ai pas prouvé le contraire par l'exemple tu pourras dire ce que tu veux bien sûr
ceci dit je me demande comment PpHd se débrouille...

Moi je peux te prouver le contraire. Mais ça a été un calvaire à programmer! De toutes façons il reste un ou deux cas où il est absolument impossible de s'en sortir si on a pas un moteur pixel par pixel. Mais ces cas sont assez rares alors ça va. Et on peut s'en sortir en bidouillant (if (saut && !descend) ...).

Je ne vois pas pourquoi la méthode de Ximoon, qui doit sûrement aussi être celle qu'utilise PpHd pour sma ne marcherait pas, à savoir attribuer une valeur d'incrémentation à chacune des coordonnées du personnage. Il suffit juste d'en attribuer à chaque tile au moment de créer le niveau.

J'aime pas bidouiller (enfin j'aime pas ça, disons, en théorie ), et si tu veux quelque chose de vraiment plus optimisé fait-le en assembleur
Mais je reste sur ma position, d'autant plus que le pixel par pixel impose que tes objets on effectivement le contact qu'ils présentent à moins de crééer un masque de contact... Enfin bon pourquoi pas... mais bon....

Ca pourrait aussi marcher pour des tiles qui ont une inclinaison courbe en associant à chaque tile non plus une simple valeur d'incrémentation, mais une fonction pour modifier les coordonnées de ton perso.

Ué vala.. en C on pourrait faire ça (par exemple) très simplement en attribuant à chaque tile un numéro, et en faisant une liste de pointeurs sur fonctions indexées par ce numéro, ça peut gérer n'importe quel évenement intervenant sur chaque type de tile (pente, téléportation, tapis roulant, pics etc)
Avec aussi par exemple le cas du type 0 qui ne saute nulle part pour gagner du temps si on sait que y'a rien à modifier... enfin je dis ça comme ça en y pensant juste, mais d'instinct c'est ce que je ferais

On me demande quoi exactement ?
Decrire SMA ?

SMA ne fait pas du pixel par pixel, d'ou l'horreur que j'ai eu a coder ce *ù*ù^$ de moteur de Sonic (Dites vous qu'un Mario a cote, meme avec les plans inclines c'est du gateau !): Je rappelle que Sonic court, bondit, vole, et fait des loopings...
Galere quand tu me tiens...
Je me rappelle plus trop des details mais je sais que j'ai pense a toutes les possibilites grace a une etude locale des tiles.

Mais si je devais tout refaire aujourd'hui je ferais cela a base de graphes de collisions. Bien plus performants, et moins gourmands en memoire. Bien plus difficile a debugguer.

Brunni :
Ce n'est pas si simple! J'ai retourné le problème dans tous les sens... Je ne peux pas "détecter" lorsque un cas est bon ou non.
>si on saute au plein milieu de la plateforme, on se retrouve magiquement sur la plateforme Ben oui, mais on devrait se retrouver sur la plate-forme seulement si la position de mario+sa hauteur est supérieure à la position de la plate-forme elle même plus la valeur de son fil de fer à l'endroit horizontal où mario se trouve. Ca fait beaucoup de conditions. C'est pas facile.

C'est pour ça que je te conseille une détection de collision au pixel près.

mmh peut-être qu'il suffit simplement qu'il prenne comme cas particulier lorsqu'il est en train de sauter. Peut-être. Mais ça devient un type de programmation que je n'aime pas du tout. Le genre de trucs où tu prévois tous les cas particuliers. Il faut UNE routine qui fonctionne pour tous les cas sinon t'es perdu, car il y'aura TOUJOURS des cas imprévus (qu'on appelle des bugs je crois) et là avec ce genre de programmation... on va pas loin du tout!

Il faut distinguer les cas:
1. saut et
2. déplacement!
Si tu te marches vers l'intérieur d'une pente (comme dans tes images), il faut déplacer Mario vers le haut. Pas si tu sautes vers l'intérieur d'une pente! Si tu sautes, il faut repousser Mario en arrière (c'est-à-dire dans la direction opposée au déplacement).

Brunni
: C'est très difficile... Tout est source de bugs. Tiens par exemple j'avais essayé de faire la détection de pixel. Mais lorsqu'il y'avait un mur à droite, bien que mon dispositif DEVAIT les détecter, le mur était toujours détecté comme "en bas" du personnage... Bizarre. Et je ne sais pas comment faire. De plus, je ne comprends pas comment c'est possible de faire une détection efficace avec TestCollide...

Il faut tenir présent le sens du déplacement. Si tu te déplaces vers la droite et que d'un coup il y a collision, c'est qu'il y a un obstacle à droite. Ensuite, tu peux tester s'il s'étale sur toute la hauteur (mur à droite) ou si ce sont juste quelques pixels en bas (pente ascendante) et agir en conséquence.

Brunni
: Parce que le problème qu'il y'a c'est que le perso peut avancer jusqu'à 5 (ou même plus) pixels d'un coup. Donc le moteur doit gérer ça. En général TOUS les moteurs (même commerciaux) font du pixel par pixel sinon ils ont les boules que ça ne marchera pas. Voici une image illustrant mon problème: [...]

Il y a une solution très simple à ton problème. Tu déplaces d'un premier pixel (sans afficher! Et sans toucher aux autres personnages!), tu testes, tu déplaces vers le haut si nécessaire, tu déplaces d'un deuxième pixel (encore sans afficher ni toucher aux autres personnages!), tu testes, tu déplaces vers le haut si nécessaire, tu refais ça encore 3 fois et ce n'est qu'après avoir fait ça 5 fois que le déplacement de Mario est complété et que tu peux toucher aux autres personnages et à l'affichage.

Kevin> ou alors coder le niveau en dur dans le programme
Ceci dit il est important de simuler le déplacement par plus petite unité de contact envisageable (on parle ici de pixels par exemple) sinon l'exemple type est le passage au travers d'une platte-forme lors d'une retombée de saut parabolique (à vitesse variable)

PpHd> ça fonctionne comment un graphe de collision ?
Il me semble (mais c'est vieux, donc je me trompe peut-être), que tu avais dit dans un ancien topic que les niveaux de SMA étaient organisés selon des tableaux de tiles, mais qu'avec le recul, finalement, tu pensais que ça aurait été mieux sous forme d'arbre, mais perso, je ne vois pas du tout comment faire avec des arbres, est-ce que tu pourrais m'éclairer (mais je répète que je peux avoir totalement déformé ce que tu avais dit) ?

Plus souple, plus flexible (On peut vraiment faire ce qu'on veut).
En gros, tu code tes collisions comme en 3D : au lieu d'utiliser tes plans tu utilises des lignes et un BPP pour gere le tout.

Bon, déjà MERCI à tous ceux qui m'ont répondu, c'est vraiment sympa!

Il y a une solution très simple à ton problème. Tu déplaces d'un premier pixel (sans afficher! Et sans toucher aux autres personnages!), tu testes, tu déplaces vers le haut si nécessaire, tu déplaces d'un deuxième pixel (encore sans afficher ni toucher aux autres personnages!), tu testes, tu déplaces vers le haut si nécessaire, tu refais ça encore 3 fois et ce n'est qu'après avoir fait ça 5 fois que le déplacement de Mario est complété et que tu peux toucher aux autres personnages et à l'affichage.

Ben justement ce n'est pas ce que je fais... C'est ce que j'entendais par "pixel par pixel". Mais de faire 5 fois le déplacement c'est terriblement lent. Mais ce que je disais c'est que c'est bien la seule manière d'avoir VRAIMENT quelque chose de stable. C'est ce que tu fais PpHd?

Kevin> ou alors coder le niveau en dur dans le programme Ceci dit il est important de simuler le déplacement par plus petite unité de contact envisageable (on parle ici de pixels par exemple) sinon l'exemple type est le passage au travers d'une platte-forme lors d'une retombée de saut parabolique (à vitesse variable)

Ben voilà! Tu as compris mon problème. Mais mon moteur est la preuve que c'est possible d'envisager des déplacements de plus (ici 5 pixels) et ! J'ai aussi la définition de chaque "tile", et le tout est géré de cette manière (16x16 pour chaque "tile"). Pixel par pixel pour moi ça signifie que le perso avancera d'environ un pixel par frame, et plus seulement dans des cas exceptionnels. Mais ça ne veut pas dire que si ma map fait 1600 par 800 pixels j'aurai une matrice de 1600*800 octets (pas fou!) Dans ce cas-là, mes map font 100x50x3 (3 plans) (mais c'est possible de paramétrer cela dans l'en-tête du niveau)
Cependant mon perso avance jusqu'à 7 pixels par frame (aïaïaïaïaïaïïïïïïïïï, après je m'étonne que j'ai des problèmes)

>>SMA ne fait pas du pixel par pixel, d'ou l'horreur que j'ai eu a coder ce *ù*ù^$ de moteur de Sonic (Dites vous qu'un Mario a cote, meme avec les plans inclines c'est du gateau !):

Je signale quand-même que mon Mario était un Sonic à la base. Mais j'ai été découragé à l'époque où je faisais les pans inclinés qui marchaient pas très bien. Mais il ne restait plus qu'à "faire coller sonic au plafond" dans les cas où cela s'appliquait.
J'ai même du supprimer (!) des trucs qui fonctionnaient niquel pour que ça aille avec mario. Heureusement Sonic traine toujours dans un coin. Lorsque je lui aurai mis à jour son moteur des pans inclinés (maintenant il est bon). Sinon je serai curieux de savoir comment du simules les "décollages" de Sonic lorsqu'il court sur certaines plates-formes...
Type: (Sonic est justement au pied d'une de ces plate-formes...

>>Je rappelle que Sonic court, bondit, vole, et fait des loopings...
Mario ne court pas? Mais pour le bondissement je vois de quoi tu parles (saut lorsqu'on quitte des pans inclinés avec beaucoup de vitesse). La technique est implémentée mais inactive dans le cas de Mario. Mais elle n'est pas parfaite quand-même dans mon Sonic. Pour les loopings... C'est ce qu'il reste.

De toutes façons Sonic sera toujours mieux que Mario mais pour un débutant, Mario c'est sympa à programmer (ça faisait pas une année que je connaissait le mot programmation lorsque j'ai commencé Sonic, et j'ai bossé 2 mois sur un moteur abstrait duquel je n'ai pas vu de résultat satisfaisant, alors c'est normal que j'ai abandonné)
Mais ne vous inquiétez pas, Sonic c'est mon rêve et il VA VENIR, c'est sûr ça!

En tous cas encore merci à tous et @+!

Brunni :
Bon, déjà MERCI à tous ceux qui m'ont répondu, c'est vraiment sympa!

de rien

Kevin> ou alors coder le niveau en dur dans le programme Ceci dit il est important de simuler le déplacement par plus petite unité de contact envisageable (on parle ici de pixels par exemple) sinon l'exemple type est le passage au travers d'une platte-forme lors d'une retombée de saut parabolique (à vitesse variable)

Ben voilà! Tu as compris mon problème. Mais mon moteur est la preuve que c'est possible d'envisager des déplacements de plus (ici 5 pixels) et ! J'ai aussi la définition de chaque "tile", et le tout est géré de cette manière (16x16 pour chaque "tile"). Pixel par pixel pour moi ça signifie que le perso avancera d'environ un pixel par frame, et plus seulement dans des cas exceptionnels. Mais ça ne veut pas dire que si ma map fait 1600 par 800 pixels j'aurai une matrice de 1600*800 octets (pas fou!) Dans ce cas-là, mes map font 100x50x3 (3 plans) (mais c'est possible de paramétrer cela dans l'en-tête du niveau)
Cependant mon perso avance jusqu'à 7 pixels par frame (aïaïaïaïaïaïïïïïïïïï, après je m'étonne que j'ai des problèmes)

On était au courant que c'était possible quand même
Pour mon moteur les tiles font 16px, les collisions sont géré à 4px près en horizontal (ce qui correspond à la vitesse de déplacement horizontale du perso) et au pixel près en vertical, car là la vitesse est variable et peut dépasser 16px/frame ce qui le ferait passer à travers les pallte formes. Donc lors d'un saut, les coordonnées sont testées par intervalle de 4pixels entre le départ et l'arrivée pour s'nterrompre au premier obstacle et dessiner le sprite au bon endroit, mettant à jour les coordonnées en conséquence

On était au courant que c'était possible quand même Pour mon moteur les tiles font 26px, les collisions sont géré à 4px près en horizontal (ce qui correspond à la vitesse de déplacement horizontale du perso) et au pixel près en vertical, car là la vitesse est variable et peut dépasser 16px/frame ce qui le ferait passer à travers les pallte formes. Donc lors d'un saut, les coordonnées sont testées par intervalle de 4pixels entre le départ et l'arrivée pour s'nterrompre au premier obstacle et dessiner le sprite au bon endroit, mettant à jour les coordonnées en conséquence

QUOI? Seize pixels de vitesse alors là tu es recordman!
Sinon pour les tiles de 26px ça doit être assez du gaspillage non? Pourquoi tu n'as pas fait du trente-deux ou du vingt-quatre pixels par bloc (ou "tile")?
Et... euh... je sais pas comment dire mais... Il fonctionne ton jeu avec un tel saut?
J'ai fini mon Mario. Reste encore à corriger un bug (que j'ai oublié... mince .)

faute de frappe... les tiles font bien 16x16
sinon oui ça fonctionne...
le perso faisant 24px de hauteur, au retour d'un saut il n' a rien de choquant si sa vitesse dépasse les 16px/frame.. j'ai quand même fixé une valeur de vitesse de chute maximale mais je ne me rappelle plus de combien ici et maintenant

Moi j'ai mis 7 pour la GRAVITE, 5 pour la vitesse, 4 pour la poussée gravitationnelle vers le haut durant la montée d'un SAUT_OBLIGATOIRE. Les ennemis font généralement du 1 par 1 pixel car leur moteur de détection est un peu pourri. Les plates-formes téléguidées... du 1.5 pixel/frame.. et. c'est un peu tout.

faute de frappe... les tiles font bien 16x16

Je t'avoue que ça me rassure!