Recherche un algo... - Page 1

Mon problème est relatif à Kururin68k que j'ai repris récemment. Pour ceux qui connaissent l'original, vous avez certainement remarqué qu'après collision contre un mur, il ya un léger rebond du rotor contre celui-ci. Dans mon programme, la rotation du bâton est simulée par une succession de sprites, donc pour faire comme si le rotor rebondissait contre le mur, je reviens de quelques sprites en arrière. Seulement je suis confronté à un gros problème: selon son angle d'attaque (et son sens de rotation) par rapport au mur, le rotor est en fait censé revenir en arrière de qqes sprites, ou au contraire avancer de qqs sprites. En effet, si celui-ci revient systématiquement en arrière, alors il se retrouvera dans certains cas encore plus "dans" le mur. Et je n'ai strictement aucune idée de comment savoir si le rotor doit avancer ou reculer de quelques sprites, selon le mur qu'il touche... j'espre que vous m'avez compris, c'est un peu cho à expliquer
Donc si quelqu'un trouve un algo, je suis preneur, parce que là je ne voit vraiment pas (en plus c'est le dernier truc à régler avant la bêta ). merci !

Ben je ne sais pas, j'ai bien quelques idées, mais je ne sais pas si on peut leur faire confiance.
Par exemple, quand le rotor tourne dans un sens, il est impossible qu'il entre en collision avec un mur situé "derrière" le rotor, sauf si on le pousse dans le mur en appuyant sur une touche de déplacement.

Bon, j'ai une petite idée, mais un peu compliquée, je reviendrai après, là, je dois partir.

Par exemple, quand le rotor tourne dans un sens, il est impossible qu'il entre en collision avec un mur situé "derrière" le rotor, sauf si on le pousse dans le mur en appuyant sur une touche de déplacement.

Bonne suggestion

derriere comment? y a deux pales au rotor, et c'est des sprites...dc a moins qu'il aie une sprite par pale, qd un mur est "derriere" une pale, il est devant l'autre...

justement

Tu devras probablement utiliser les routines de collisions au pixel près de ExtGraph.

LOL
Ma routine EST au pixel pres, sans utiliser Extgraph evidemment...
tu nas pas compris le pb, ce nest pas la collision en elle meme aui pose pb, mais langle entre le mur et le rotor au moment de la collision.

c la reponse a la collision son pbl
et la kevin va nous sortir une belle formule mathematique lente a chier oueee

Comme d'hab

En associant à chaque sprite l'angle d'attaque correspondant, tu peux facilement trouver quelque sprite afficher quand il y a une collision !?

L'angle d'attaque, tu l'as indirectement par le delta x et le delta y de la trajectoire de la balle. En divisant les deux, tu as un nombre unique représentatif de l'angle.

Nerick a écrit :
LOL Ma routine EST au pixel pres, sans utiliser Extgraph evidemment...

Tu as quoi contre ExtGraph?

tu nas pas compris le pb, ce nest pas la collision en elle meme aui pose pb, mais langle entre le mur et le rotor au moment de la collision.

C'est de la trigonométrie ça... Trace ta figure et tu verras quelle fonction trigonométrique c'est. Si tu ne le vois pas, poste la figure.

> Tu as quoi contre ExtGraph ?
Je ne pense pas que quelqu'un ici ait une dent contre ExtGraph.
Ceux qui préfèrent utiliser GX, Xlib, GenLib, ou mieux, leurs propres fonctions, ont le droit.
Maintenant on ne peut plus choisir sa bibliothèque graphique sans que le roi auto-proclamé Kevin nous pose cette question ?

C'est le "évidemment" qui me gène dans ce qu'il a dit.

C'est vrai. Pardon !

nan je disais "évidemment", parskeu je suppose que le format de sprite d'ExtGraph est différent de celui de genlib.
Thibaut> le pb c que sur un meme tile, il peut y avoir plusieurs murs orientés différements. et puis c pas une balle c un rotor

Nerick
a écrit : nan je disais "évidemment", parskeu je suppose que le format de sprite d'ExtGraph est différent de celui de genlib.

Tu pourrais rajouter le masque pour la détection de collision ou le calculer avant d'appeler la routine.

D'ailleurs, tiens PpHd, voilà une routine utile qui manque dans genlib et qui est dans ExtGraph.

Moi j'ai une idée, mais je t'en prie, sois patient avec moi, car c'est très difficile à expliqué:
**Il faut d'abord que tu conaisses ton sens de rotation, mais ca je pense que tu y as pensé
**Ensuite,c'est une question de trigonométrie :
------------Regarde la position des tes sprites "extrémités" du baton
------------Regarde ton baton
------------Imagine toi le cercle dont le diamètre est le baton (et qui donc se déplace en même temps que le baton)
------------ Quelque soit l'orientation de ton baton,tu t'imagine la ligne verticale médiane, donc qui partage ton cercle en deux
------------ Regarde le point haut: tu imagines que c'est le départ de tout angle
------------ En plus, en trigo: tout angle négatif se transforme en angle positif
*** tu peux te baser sur ca pour savoir lors de la collision , selon l'extrémité, commment se situent et ton baton et tes deux extrémités


J'espère que quelqu'un a compris et saura mieux expliquer que moi
J'ai fait une image sous PAINT sinon, si quelqu'un voudrait bien l'héberger pour moi.

Si ça à toujours un intéret, envois la moi à aymericdelbreil@club-internet.fr.

Sinon, Boo, c un bots, un programme, koi. Et c yAro, pas Yaro