Vitesse, saut, gravité, angle - Page 2

Quoi?
Comment le perso fait-il pour avancer si son accélération x est nulle? Et il doit freiner lorsqu'on relâche la touche...

Ben, tout simplement parce que x est incrémenté par la touche [->] et décrémenté par la touche [<-]

Kevin> euh non, sauf si le perso n'a que deux vitesses possibles (en valeur absolue, 0 et vitesse_max), l'accélération selon x n'est pas nulle dans les phase de transition de vitesse
(je conçois que dans backgammon l'accélération puisse être nulle)

Il me semble que non; d'ailleurs:

if (touche gauche)
  vitesse--;
else if (touche droite)
  vitesse++;
vitesse-=deceleration_plateforme_courante;
x+=vitesse;

Mais sinon pour le post 27, il y a du juste?

Ximoon :
(je conçoit que dans backgammon l'accélération puisse être nulle)

Heu à propos de:

5. Si tout cela est juste, peut-on dire que dans le cas d'un angle de 60°, on transpose sin(60°) (proportion) de la vitesse x sur la vitesse y et on conserve cos(60°) (ou sin(30°)) de la vitesse x sur son axe (x donc)?

ne m'a dit si c'était juste) j'ai une limitation du moteur de jeu; je ne gère que la vitesse horizontale. En clair si j'ai: / / /(personne Et que le perso est sur le / du bas et avance vers la droite, il va se retrouver "dans" le / une ligne plus haut et va être replacé de manière à tenir dessus la plate-forme (malgré cela il s'agit bien d'une plate-forme passe-bas) alors il est impossible de gérer soi-même la vitesse verticale puisqu'elle peut être considérée comme infinie (pointant vers le haut) à cause du moteur Lorsque sonic est à la verticale et qu'il y a une collision à sa droite, il peut "monter" sur le mur grâce à sa vitesse x. Donc ici tout ce que je peux faire pour des plate-formes inclinées très fortement c'est de diminuer manuellement la vitesse x, puisque c'est la seule chose que je puisse modifier étant donné que même dans ce cas le perso est considéré comme "à plat".

bah ce que tu mets dans le premier cadre me semble juste, mais si ton moteur ne gère pas la vitesse verticale tu ne vas pas aller bien loi...

Il gère la vitesse verticale pour le cas où le personnage n'est pas à plat. Mais sinon il peut gérer la vitesse y pour la gravité et le saut. Sinon je ne vois absolument pas comment faire pour les plate-formes inclinées. Il y a des collisions à respecter pour que ce soit réaliste...

Bon, voilà, j'ai essayé pour les angles mais ça ne fonctionne (bien entendu) pas.
Si on prend une plate-forme à 60° par exemple, elle est dessinée de manière que pour un pixel en x on a deux pixels en y (en diagonale 45° c'est un pixel en x pour un pixel en y) donc là ça veut forcément dire que la vitesse y est deux fois plus grande que la vitesse x. Et c'est là que ça embête...
Si je prends sin(60°) je vois que je serais censé avoir 86.6% de la vitesse x reportée en y (lorsqu'on est sur un mur vertical, 100% de la vitesse x est reportée sur l'axe y, et à plat 0. Donc si j'ai 86.6% en y, j'aurais forcément 43.3% en x (/2). Dans ce cas-là ça fonctionne, mais pour une plate-forme à 30° j'ai sin(30°)=50% (pour vitesse y), et là vitesse x = 2 * vitesse y donc vitesse x = 100%, alors que 100% ce n'est qu'au plat! Bizarre, je fais forcément une faute mais je ne vois pas où...

Brunni :
Si on prend une plate-forme à 60° par exemple, elle est dessinée de manière que pour un pixel en x on a deux pixels en y (en diagonale 45° c'est un pixel en x pour un pixel en y) donc là ça veut forcément dire que la vitesse y est deux fois plus grande que la vitesse x. Et c'est là que ça embête...

Euh je n'ai pas du bien suivre ta démonstration...
Déjà, c'est plutôt un angle de 63° qui donne un corefficient directeur de 2.
Ensuite, comment en se basant sur le fait que le coeff directeur est 2 tu en conclues que la vitesse verticale est forcément 2 fois plus grande que la vitesse horizontale ?
Je ne dis pas que c'est faux, mais je ne vois pas de démonstration.
(À mon avis, c'est plutôt l'accélération verticale qui sera le double de l'accélération horizontale d'ailleurs)

Si je prends sin(60°) je vois que je serais censé avoir 86.6% de la vitesse x reportée en y (lorsqu'on est sur un mur vertical, 100% de la vitesse x est reportée sur l'axe y, et à plat 0. Donc si j'ai 86.6% en y, j'aurais forcément 43.3% en x (/2). Dans ce cas-là ça fonctionne, mais pour une plate-forme à 30° j'ai sin(30°)=50% (pour vitesse y), et là vitesse x = 2 * vitesse y donc vitesse x = 100%, alors que 100% ce n'est qu'au plat! Bizarre, je fais forcément une faute mais je ne vois pas où...

D'où vient le sin(60°) ?

D'où vient le sin(60°) ?

Des 60° d'inclinaison de la plate-forme. Je viens de faire un essai en TI-BASIC et j'en conclus qu'avec une virgule fixe (* et / 10000) l'angle doit être de 63.43° pour un vecteur ayant un coefficient directeur de 2. Mea culpa.

À mon avis, c'est plutôt l'accélération verticale qui sera le double de l'accélération horizontale d'ailleurs

C'est bien possible. Mais pour ce qu'il s'agit de l'accélération du personnage, elle est constante non? Parce que j'ai essayé pour Sonic et là j'en conclus que de faire un truc du genre:

if (touche_droite)
 perso->vitesse+=INCREMENT_VITESSE;
[...]
perso->vitesse-=coeff_ralentissement[perso->angle];

ça ne marche pas du tout . En fait lorsque que le vrai Sonic peut s'arrêter sur une plate-forme d'un angle de moins de 45°, "mon" Sonic, lui, continue de réduire sa vitesse (qui passe dans les négatifs) lorsqu'il se trouve là. Ce raisonnement est vrai pour Sonic mais uniquement pour un angle supérieur à 45°...
Donc en fait on devrait appliquer un coefficient de réduction sur l'accélération du personnage, et pourtant il me semblait vraiment que l'accélération du perso était censée être constante?

1. Non, je te demandais d'où venait le sin, pas le 60

2. L'accéléraion n'est pas constante, elle dépend de l'inclinaison de la plate-forme.
Et je pense que les frottements doivent être ôtés de l'accélération, pas de la vitesse, mais je n'en suis pas sûr du tout.

vx=cos(angle)*vitesse;
vy=sin(alpha)*vitesse;
Voilà d'où vient le sin, c'est pour calculer le nombre de pixels à avancer cette fois en y. Et si les angles étaient corrects, avec les collisions, je n'aurais besoin que d'appliquer la vitesse en x et la correction en y serait automatiquement faite puisque le personnage devra toujours rester dessus la plate-forme (d'où vitesse y forcée)

2. L'accéléraion n'est pas constante, elle dépend de l'inclinaison de la plate-forme.

=coeff_ralentissement[angle];

OK. Mais bon si j'utilise ça:if (touche_droite)
 vitesse+=ACCELERATION_BASE;
[...]
vitesse-

j'ai de toutes façons une accélération qui est adaptée puisque j'y ajoute par exemple 2 pour ACCELERATION_BASE et y enlève 1.4 pour coeff_ralentissement[angle] j'ai au final une accélération de 0.6 adaptée donc. Et ça c'est faux, mais je ne sais pas pourquoi.
Nan mais maintenant j'ai un doute... pour calculer la vitesse, c'est faux ce que je fais non? Je ne dois pas partir d'une vitesse zéro et y additionner l'accélération? Là je l'accélère normalement et le freine par le frottement...

1. Mais d'où il vient ton sin ?

2. Je ne sais pas, je suis nul en physique
J'ai un bouquin là-dessus, je regarderai dedans si je peux trouver un tuyau, parce que ça m'intéresse ce genre de trucs.

Bon en fait j'ai vraiment bossé en regardant toujours si l'effet était le même dans le jeu original. En clair les formules sont finalement beaucoup plus simples qu'on pourrait le penser et les constantes dignes d'un examen de math sans calculette (et encore ).
Finalement les valeurs de mon accélération et mon freinage sont constantes.
1. Je ne comprends pas

D'où tires-tu cette équation comportant un sin ?

Ben c'est pour calculer la modification de la vitesse d'une balle en fonction de son angle (d'ailleurs si ça se trouve on verra peut-être même cela tel quel en physique; c'est une formule comme une autre)... G*sin(angle)