Vitesse, saut, gravité, angle - Page 1

Salut à tous!
Voilà mon problème: Je suis une M*RDE en physique, je connais juste trois formules de base MRU et MRUA. Prenons un moteur comme celui de Sonic (sur mégadrive donc) on voit clairement que la décélération du personnage est proportionnelle à sa vitesse (en clair si Sonic va vite, il en faudra beaucoup plus pour le ralentir que s'il va un peu plus lentement, ce n'est pas linéaire quoi) et s'il marche sur une plate-forme inclinée avec une vitesse suffisante il pourra continuer son chemin à l'infini malgré le ralentissement, alors que s'il y était arrivé en marchant plus lentement, il se serait arrêté très peu après. Bizarre...
Prenons maintenant mon cas, j'utilise un système linéaire où je divise la vitesse par 5 pour savoir le nombre de pixels à avancer (ça me permet d'être plus précis), mais ce n'est certainement pas bon, il faudrait sûrement utiliser une autre formule pour calculer le nombre de pixels à avancer sachant que la vitesse max. serait 25, et donnerait finalement 5 pixels.
Cette formule a-t-elle un nom, où puis-je la trouver?
e formule (de mon cours donc):x=x0+v0*t+1/2a*t^2 où à=-g et g=9.81Idem pour le saut, si je prends cettCa pourrait donner quelque chose de valable? (apparemment non, mais peut-être que juste une toute petite modification s'impose)

ce n'est pas la peine de calculer la trajectoire a l'avance (comme tu l'aurais fait avec ta formule)
le truc c'est d'integrer a chaque frame le PFD par exemple (masse*acceleration = somme(forces_exterieures))
(et pareil pour la vitesse)
c'est a dire qu'a chaque frame tu calcule de combien tu dois avancer

dans ton cas, tu ajoutes 1/5eme de la vitesse aux coordonnées
en gros tu fais x+= vx/5 et y += vy/5
c'est bien, ca qu'il fait faire (a toi de trouver la constabte de proportionnalité qui convient en fonction de ton framerate)

pour le saut c'est la meme chose, sauf que la vitesse n'est plus constante, tu dois donc la modifier comme tu as fait pour les coordonnées
vy += accelerationy*cte

et au final ca donne la meme chose que si tu avais utilisé la formule de ton cours, mais c'ets bien plus simple a implémenter

y'a pas de raison que ça ne marche pas, mais a priori comme tu travailles frame par frame tu vas plutôt utiliser des deltas de position (la vitesse quoi) au lieu de recalculer x à partir de x0 à chaque fois.

v(t) = a*t+v0 pour la t-ième frame.
donc en fait tu ajoutes a à chaque frame

pour une accélération de type course horizontale, tu as donc une accélération nulle à l'arret, et à la vitesse max. on peut considérer v0 comme toujours nulle, et l'accélération est négative en cas de freinage et positive en cas d'accélération ()

donc tu fixes a, et tu n'as qu'à ajouter v à x pour modifier la position

en fait ta formule marche très bien pour les mouvement verticaux (soumis à la pesanteur), c'est exactement la même chose sauf que l'accélération est négative (vers le bas) et constante: quoique tu fasses tu tombera toujours de la même façon. Tu peux la reprendre donc pour le saut en fixant v0 au moment du saut et en faisant pareil qu'au dessus.

vala je ne sais pas si j'ai été clair et j'ai pu me tromper mais l'idée est là ...

pendant qu'on y est, ou peut on trouver un bon moteur physique(source) ?

ds ta tête
sinon, regarde tout ce qui est jeu de plateforme sur atari, pc etc.

Je sais, je voulais refaire le moteur de liero.
Si tu connais pas, telecharge le et tu comprenderas pourquoi j'ai du mal a le refaire.
Le probleme etant qu'on a pas la source et que d'ailleurs sur de bons moteurs physiques, on n'a jamais de source. C'est pour ca que je demandais.

g vu sur http://www.calc.org un projet de jeu de plateformes du nom de Fury qui utilisait plein de formules de physique, et il était open-source. J'ai joué au jeu et il est assez marant... Je c pas si c ça ke vs cherchez ms allez voir...

Je ne vois pas la source, mais de toute façon, il n'y a qu'à appliquer sa formule du MRUV.

oué, ben faire un simple pfd

Et le principal intéressé (enfin l'auteur du topic quoi) il en pense quoi ?

Merci à tous! (voilà ce que j'en pense )

y'a pas de raison que ça ne marche pas, mais a priori comme tu travailles frame par frame tu vas plutôt utiliser des deltas de position (la vitesse quoi) au lieu de recalculer x à partir de x0 à chaque fois.

Va falloir que je me mette aux float (ou plutôt à la floatte! )

Non, surtout pas! float == lent!

(et en plus ça fait augmenter la taille du code de plus de 500 octets )
Mais par contre je ne vois pas de solution en frame par frame sans float...

Suffit de travailler sur des nombres plus *grands* puis de repositionner apres

virgule fixe

Ah ben oui forcément! Merci!

mm, utiliser les décalages aux maximum ... ca permet d'accélérer considérablement le tout

>> et << donc?
Mais ça ne permet pas de faire des multiplications et divisions qui soient des puissances de 10 il me semble...

adapte ton algo pour passer en puissances de 2

Puis, si tu peux utilise des décalages de 16 bits, ce sera bien plus rapide.

kler ...

c'est bien, ca qu'il fait faire (a toi de trouver la constabte de proportionnalité qui convient en fonction de ton framerate)

Compris. En gros un algo simple serait:

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

Donc ça c'est dans un cas où l'accélération est constante et vaut 1.
Maintenant ce que je disais au premier post est-il vrai pour Sonic? Cela implique-t-il que l'accélération ne soit pas constante?
Bon en réfléchissant je verrais un coefficient de décélération sur les plate-formes inclinées. En gros, si une plate-forme a un coef. de 1, et que la vitesse de la boule (ou de Sonic) en arrivant dessus est de 1.2, celui-ci continuera d'accélérer à 0.2 (enfin pour autant qu'il appuie la touche pour avancer ), donc ne s'arrêtera jamais, alors que s'il arrive dessus avec une vitesse de 0.8, son accélération sera -0.2 et sa vitesse s'épuisera progressivement (et de plus en plus rapidement comme constaté). Heu... je suis juste ou bien à côté de la plaque là?

n'oublie pas que l'accélération doit être une valeur vectorielle, avec une composante selon x et une selon y.
Je ne sais pas comment c'est dans sonic, mais rien ne t'empêche de faire un moteur physique réaliste (en calculant les valeurs réelles des composantes de l'accélération selon l'inclinaison du bloc)
sinon ça me semble pas mal ce que tu as écrit, reste à trouver les bons dosages pour tes coeffs

n'oublie pas que l'accélération doit être une valeur vectorielle, avec une composante selon x et une selon y.

Tu peux juste préciser un peu s'il te plaît?
Un autre problème s'impose dans sonic... Son angle, et c'est là que je bloque un peu. Je ne peux pas appliquer la même vitesse s'il a un angle de 60° que s'il est au plat (0°) sinon ce n'est pas très réaliste. Qu'est-ce qu'on applique dans ce cas là? (je pense que c'est justement de quoi tu voulais parler non?)

sinon ça me semble pas mal ce que tu as écrit, reste à trouver les bons dosages pour tes coeffs

Merci (je débute vraiment). En fait je vais tester pour les coeffs...

L'histoire d'angle correspond à ce que tu fais pour les coeffs: ça n'influe pas directement sur la vitesse mais sur l'accélération. Ce que je veux dire en parlant de valeur vectorielle c'est qu'il y a une valeur de l'accélération verticale et une autre horizontale. En fait elle sont liées (tu n'as vraiment pas de cours de physique? pourtant tout est dit dans la formule que tu as donné au début). Par exemple une pente de 60° va modifier différemment l'accélération horizontale et la verticale.

J'ai eu un *petit* cours de physique et on en est encore aux bases.

En fait elle sont liées

Effectivement. Et c'est là mon problème apparemment. La valeur verticale est la gravité (augmente au fur et à mesure que Sonic tombe mais est constante au plat! Et la valeur horizontale est linéaire).
Et justement à la verticale (90°) la valeur de l'accélération verticale qui jusque-là était positive (9.81, donc vers le bas) doit tout à coup passer vers le haut! Mais justement comment ça se fait? Apparemment je dois transposer sa vitesse x sur sa vitesse y. Je ne sais pas si tu pourrais m'expliquer ça? Ca me débloquerait certainement.

alors déjà tu as l'air d'avir mal compris un truc important: la "gravité" est une force constante. Elle n'augmente pas du tout quoi qu'il arrive! Elle agit comme une accélération supplémentaire qui peut être annulée quand le perso est sur un plat (mais ce n'est qu'une représentation algorithmique dans ce cas).

Désolé. Je me suis trompé de terme.
1. En fait la vitesse y de la boule augmente au fur et à mesure que le personnage tombe. L'accélération y du personnage est constante et est égale à g, c'est bon ça?
2. L'accélération x est constante elle-aussi, sauf qu'on y applique une force de décélération plus tard suivant la plate-forme, est-ce juste?
3. Donc pas de décélération y? Si oui dans quels cas par exemple?
4. Maintenant si Sonic monte sur un mur (90°) alors là la vitesse x est transposée sur la vitesse y? Et la décélération verticale (g) est appliquée sur le personnage?
5. Si tout cela est juste, peut-on dire que dans le cas d'un angle de 60°, on transpose 2/3 de la vitesse x sur la vitesse y et on conserve 1/3 de la vitesse x sur son axe (x donc)?

Heu mince c'est faux
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)?

L'accélération x vaut en général 0 dans un jeu (on néglige les frottements).