les sauts - Page 1

Salut tout le monde,
Voilà, en ce moment, je suis en train d'implémenter les sauts dans mon ch'ti jeu.
J'ai 3 types de sauts:
- les sauts à petite hauteur quand le poussin marche: TILE_HEIGHT/2 pixels
- les sauts de falaise: TILE_HEIGHT/2 pixels suivit d'une chutte
- les sauts à grande hauteur quand le poussin est à l'arrêt (standby), possibilité de bouger dans la direction dans laquelle il se trouve (gauche ou droite) et d'une hauteur de TILE_HEIGHT+TILE_HEIGHT/4.

les sauts passent par 4 états:
- gap (s'accroupit pour préparer le saut)
- jump (le saut lui-même)
- fall (la chutte)
- land (l'attérissage)

Pour l'encodage des sauts, le passage dans les différents états se fait bien et ça semble correcte, mais pas très réaliste par rapport à la version originale sur gameboy color. Un algo de physique (que je ne connais pas) doit sûrement être utilisé. Pour le moment, le poussin lorsqu'il saute, il monte de 1 pixel à la fois (un peut lent), et tombe de 2 pixels. Je peux biensûr compter le nombre de pixels que le poussin saute dans les différents sauts, et ainsi faire la table et là ça sera vraiment identique à la gameboy, mais je ne pense pas que ça soit une solution réutilisable.

Quelqu'un a-t-il une suggestion ou un algorithme à me proposer?

D'avance merci.

Fred.

x = 1/2 t²

vitesse_verticale[t+1] = vitesse_verticale[t] - 1

Vi c'est plus simple exprimé comme ça quand on cherche à l'implémenter.

C'est clair que c'est mieux de le faire en incrémental (frame par frame, en rapport avec la position précédente) plutôt que d'utiliser une formule temporelle qui nécessite une position initiale, vitesse initiale, etc

surtout que de toute façon dès qu'il y a une interaction avec d'autres objets il n'y a que l'incrémental qui marche... (sauf si on s'amuse à recalculer la position/vitesse finale pour s'en servir en tant que position/vitesse initiale de la prochaine formule, mais ça revient à faire de l'incrémental )

j'oubliais, le poussin ne saute pas plus qu'une largeur de tile...
.4/ tu penses que vaut mieux carrément que je regarde frame par frame sur la gb et que je fasse la table à la mimine?

euh, surtout pas, au contraire : il voulait dire utiliser une formule qui permet de passer du couple (position,vitesse) d'un frame au couple (position,vitesse) du frame suivant, plutôt que d'utiliser une équation qui donne la position en fonction du temps écoulé...

ah, et ça donne quel genre de code en C sachant que ça tourne dans une boucle?

vitesse_y -= 10, position_y += vitesse_y>>6;

(ma bonté me perdra )

le 10 et le 6 tu le sors d'où???

./12 je sais, tu peux le dire :P

10 et 6 sont pris au hasard, c'est juste que ça va te donner une gravité de 10/2^6 (en pixels/frame^2)

Une autre façon de le dire est que la vitesse est en virgule fixe (avec 6 bits après la virgule ici).
Soit dit en passant, t'aurais pu mettre la position en virgule fixe aussi #chieur#

oui d'ailleurs perso ça me semble plus logique de passer tout en virgule fixe (que toutes les frames aient une conséquence sur la position plutot que certaines oui certaines non, selon les calculs à effectuer par la suite, ça peut être mieux)

ok, c'est bon pour les sauts.
j'ai compris ce qui n'allait pas dans l'algo:
lorsque j'arrive à la moitié du mouvement, je ne redescendais pas comme il fallait: le perso tombait comme une pierre. Maintenant le movement est bon
En fait le movement sur gb se fait comme suit:
- le poussin saute 8 pixels en largeur (1 tile)
- Les petits sauts font 4 pixels de haut (1/2 tile)
- les grands sauts font 8 pixels de haut (1 tile)

lors des petits sauts, le poussin monte de 1 pixel à la fois, et lors des grands sauts le poussin monte de 2 pixels à la fois.

Arrivé à la moitié du mouvement (quand le poussin a parcouru 4 pixels en largeur), il retombe.
Ce qui done l'algo suivant pour les petits sauts:

if (toki->jumping > 0)
{
	if (toki->jumping < (toki->jumpCount/2))
	{
		// after half of the way, toki falls
		toki->sprite.location.y+=toki->speed;
	}
	else
	{
		// before half of the way, toki jumps
		toki->sprite.location.y-=toki->speed;
	}
			
	if (toki->sprite.direction == DIRECTION_RIGHT)
	{
		toki->sprite.location.x+=2*toki->speed;

		if (toki->sprite.location.x-toki->startJump.x > TILE_WIDTH)
			toki->sprite.location.x-=2*toki->speed;
	}
	else
	{
		toki->sprite.location.x-=2*toki->speed;

		if (toki->startJump.x-toki->sprite.location.x > TILE_WIDTH)
			toki->sprite.location.x+=2*toki->speed;
	}

	toki->jumping-=toki->speed;
}
else
	// if toki not jumping, he falls
	toki->sprite.location.y+=2*toki->speed;

biensur, il reste encore les collisions à droite et à gauche, (en bas, c'est fait) et ajouter un test si c'est un petit ou un grand saut.



fred.

avec ce type de code, tu vas avoir un saut en "triangle", tandis que si tu utilises une formule du type de celle proposée par Pollux (post #9), ton saut sera plus rond et donc plus réaliste (comme dans quasiment tous les jeux de plate-forme); à toi de voir ce qui correspond le plus à ce que tu recherches

après avoir observé le comportement du jeu original sur gb frame par frame, il semble que ça soit plutôt ce type d'algo. mais j'ai peut-être mal interprété les images...

ah ok, je sais pas quel jeu t'essaies de reproduire, je me base sur les classiques genre mario, sonic et cie ^^

Je suis pas sûr que les sauts de Mario (du moins les premiers) respectent les lois de la physique en fait

Dans les Mario Land en tout cas, de mémoire, c'est triangulaire.
Par contre je crois que les version NES sont paraboliques (de mémoire toujours).

je viens d'aller vérifier, les sauts dans mario land, même le 1er, sont paraboliques

Brunni :
Je suis pas sûr que les sauts de Mario (du moins les premiers) respectent les lois de la physique en fait

En tout cas, même dans le tout premier épisode, Mario a une sacrée inertie. C'est un peu la marque de fabrique de la série, aussi.

Mouais, my bad
'fin bon un saut parabolique c'est pas dur à gérer, y'a même pas besoin de faire de cas particulier pour faire redescendre le bonhomme

De toute façon les sauts ultimes c'est ceux de bombjack

Ximoon :

Mouais, my bad
'fin bon un saut parabolique c'est pas dur à gérer, y'a même pas besoin de faire de cas particulier pour faire redescendre le bonhomme

A noter qu'ils ne sont pas vraiment paraboliques parceque la hauteur dépend du temps d'appuie de la touche pour sauter</chieur>
En plus la vitesse de chute a une valeur maximum </chieur bis>

La partie descendente est elle au moins parabolique et la valeur max est là pour simuler les frottements de l'air (et arrête de faire ton Sally/Spectras/Moumou/Hippo/assimilé )

Ximoon :
et la valeur max est là pour simuler les frottements de l'air

mais dans ce cas-là il faudrait aussi que ça réduise la vitesse horizontale

Vu que dans la majorité des cas la vitesse y maximale est considérablement supérieure à la vitesse x (sauf si ton personnage s'appelle sonic), tu risques de toucher le bas du niveau ou bien de rencontrer un obstacle (donc fin du saut ou bien vitesse x devient 0) avant d'avoir modifié sensiblement ta vitesse x