les sauts - Page 2

ahhh ça dépend, un petit saut en longueur dans mario, ça doit avoir une vitesse x équivalente à la y initiale/finale, mais bon y'a vraiment des joueurs que ça interesse la gestion des frottements dans un jeu de plate-forme 2D ?

[cross]
je crois que tu peux qd même faire des grosses chutes dans certains niveaux, non ? dans ce cas-là ça affecterait significativement le gameplay parce que tu aurais nettement moins de marge de manoeuvre en x quand tu tombes...

(j'ai édité pour préciser vitesse maximale... )
Et sinon, à moins que le jeu soit basé spécifiquement sur les frottements (ça me donne une idée ça...) non je pense que le joueur en a rien a fouttre ^^ (La vitesse maximal ça imite les frottements mais c'est surtout pour éviter que lors d'une grand chute, le personnage descende plus vite que ce que l'écran peut afficher (comme en 3D une rotation de 2 * PI entre chaque frame on verra rien))

hmm je suis même pas sûr que tous les jeux à la mario limitent la vitesse de chute; géneralement comme y'a toujours un sol, qu'il est pas très loin, et que les durées de chute sont relativement courtes, ça se verrait très peu (j'ai pas vérifié, d'ailleurs ça doit être bien chiant à vérifier sans émulateur et fonction de debug ^^)

oui enfin dans mario les durées de chutes peuvent être longues, justement, d'où l'intérêt de limiter au bout d'un moment pour pas que ça soit injouable ^^

(je viens de réaliser en lisant ton post qu'au moins dans mario bros 2 ça doit être limité, ne serait-ce que pour le début du 1er niveau ^^)

dans sonic c'est pas limité (il y a un endroit dans la spring yard zone où le scrolling arrive tout juste à rattraper sonic, je pense qu'ils ont calculé la longueur de descente exprès en fonction des limites de la machine d'ailleurs, ça cesse de descendre juste au moment où sonic allait quitter l'écran, d'ailleurs c'est un des trucs les plus de sonic, surtout à l'époque où c'est sorti)
je pense que dans la version MS c'est pas limité non plus mais il n'y a pas de très grande chute possible ^^ (ceci dit dans les premiers niveaux on peut effectivement quitter l'écran, mais c'est pas une chute, c'est une espèce de tremplin bizarre dont il semble complètement impossible physiquement que ça accélère sonic à ce point-là )

En fait sur SMS c'est nul, parce que Sonic n'est même pas géré hors écran en fait, donc tant que tu laisses appuyé sur droite, la caméra va accélérer. Si c'était vraiment géré, on tomberait dans les piques situées un peu plus loin

Par contre sur MD c'est un vrai moteur physique (j'en sais qqch ), quoi qu'en ait dit Pphd . Il n'y a pas de limite pour la sortie de l'écran car la méthode compression permet d'accéder à tout le niveau compressé très rapidement, le seul problème est qu'il n'y aura peut-être pas d'objet géré si loin.
La vitesse dépend des limites de leur moteur de collisions, mais ça doit être dans les 24/32 px/frame, tandis que le scroll est limité à 16: impressionnant pour un si petit CPU

pour le cas de TokiTori, je pense que les sauts sont triangulaires.
Par exemple pour tous les sauts, le poussin saute 1 tile de large (soit 8 pixels)
les sauts courts font 4 pixels de haut (1/2 tile en hauteur), donc pour avoir le mouvement complet, ils multiplient par 2 le déplacement en largeur et augmente de 1 pixel quand il monte et descend. si on fait les calculs, on a bien 8 de chaque côté.
pour les sauts hauts (8 pixels) ils multiplient la vitesse en hauteur par 2.
j'ai pu reproduire le movement après une paire d'heures d'observation.

voici l'algo pour les petits sauts:

if (toki->jumping > 0)
{
	if (toki->startJump.y-toki->sprite.location.y <= (toki->jumpHeight/2))
		toki->sprite.location.y-=toki->speed;
	else
		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
{
	toki->sprite.location.y+=2*toki->speed;
}

si le poussin saute, lorsqu'il n'est pas encore à la moitié de la montée, il monte, sinon, il descend, tout en allant à droite si la direction est DIRECTION_RIGHT, à gauche sinon.

C'est un peu du bidouillage ce saut, mais si ça te va y'a pas de pb
Voici un exemple pour illustrer ce dont on parlait (pseudo code bien sûr, et pas testé):

PERSO *p;
const float G = 0.5f;                 //Gravité

p->vy = 0;                            //vy => vitesse y, y => position y
while (1)
{
   //1) Gestion du saut
   if (keys->pressed.button1)         //Début de saut
     p->vy = -10;                     //Il va monter (vitesse de -10)

   //2) Collisions
   if (MoteurCollisions(p) & TC_BAS)  //On touche en bas?
      p->vy = 0;                      //Retour à une vitesse nulle sur le sol

   //3) Physique
   p->vy += G;                        //Ajoute la gravité
   p->y += p->vy;                     //Ajoute la vitesse à la position

   [...]
}

Et c'est là que la gestion physique est intéressante:
p->vy += G;
p->y += p->vy;
Lorsqu'on saute, on va prendre une vitesse de -10, qui sera additionnée à 'y', c'est-à-dire que ton perso va monter de 10 pixels à chaque fois. Mais à cause de la gravité, on ajoute 0.5 à ces -10, qui vont devenir -9.5, -9, -8.5 ... -0.5, 0, 0.5, 1, 1.5, ..., ainsi son saut va être de plus en plus atténué jusqu'à ce qu'il ne monte plus du tout, et même après il redescendra lorsque sa vitesse y ('vy') sera positive
Résultat tu as un vrai et beau saut qui marche dans tous les cas et le code est assez compact. Maintenant si tu veux gérer les cas spéciaux, c'est simplement une atténuation du saut (poussée vers le bas) si tu lâches la touche pendant la montée du saut. Ainsi:

   //Premier coup, au sol
   if (keys->pressed.button1 && p->auSol)
     p->vy = -10, debutSaut = 1;

   //Si on laisse appuyé
   if (keys->held.button1 && debutSaut == 1)       {
      //Le saut continue en de bonnes conditions
   }
   else if (debutSaut >= 0)    {
      //Atténuation => gravité suppl, et plus possible d'appuyer par la suite
      p->vy += G;
      debutSaut = 0;
   }
   //Dès qu'on a dépassé le sommet du saut, la touche n'a plus d'effet sur la descente
   if (p->vy >= 0)
     debutSaut = -1;

Ok, je vois à peu près.

j'ai ajouté la gestion des sauts hauts et ça donne ceci maintenant:

if (toki->jumping > 0)
{
	if (toki->startJump.y-toki->sprite.location.y <= (toki->jumpHeight/2))
		toki->sprite.location.y-=(toki->jumpHeight == LOW_JUMP ? 1 : 2)*toki->speed;
	else
		toki->sprite.location.y+=(toki->jumpHeight == LOW_JUMP ? 1 : 2)*toki->speed;
			
	switch (toki->sprite.direction)
	{
	case 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;
				
		break;

	case DIRECTION_LEFT:
		toki->sprite.location.x-=2*toki->speed;

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

		break;

	default:
		break;
	}
			
	toki->jumping-=toki->speed;
}
else
{
	toki->sprite.location.y+=2*toki->speed;
}

l'histoire du *2 pour la position x, c'est du au fait que le poussin saut 1 tile, comme pendant la 1ère moitié du saut (logiquement, le poussin arrive à la moitié de la tile), je diminue les y pour monter, et augmante pour descendre, c'est pour respecter une pseudo-echelle. Comme ça au final, le poussin saute toujours 1 tile de large.
et juste après, je fais comme toi, je teste les collisions vers le bas.
dans le jeu original, les collisions vers le haut ne sont pas testées lorsque le poussin saute. elles sont toute fois testées avant me saut. ce que j'ai fais dans ma version. Et, durant le saut (ou tout autre movement de transition), les touches ne répondent pas (comme dans le jeu original).

> Par contre sur MD c'est un vrai moteur physique (j'en sais qqch ), quoi qu'en ait dit Pphd
J'ai juste dit qu'il était totalement irréaliste ce moteur Et j'en sais quelque chose.
[Et il vaut mieux limiter les vitesses max, autrement les collisions deviennent vite n'importe quoi.]

ben oui mais est-ce que la vitesse n'est pas de fait limitée par la distance maximale de chute possible ? je suppose que tu vois de quel endroit je parle dans la spring yard zone si tu connais bien le jeu : la vitesse ne donne pas l'impression d'être limitée autrement que par le fait qu'au bout d'un moment tu touches le sol, et je ne vois pas d'autre endroit où tu peux atteindre une telle vitesse...

PpHd :
[Et il vaut mieux limiter les vitesses max, autrement les collisions deviennent vite n'importe quoi.]

Bof...

PpHd :
J'ai juste dit qu'il était totalement irréaliste ce moteur Et j'en sais quelque chose.

C'est dommage, le jeu était par ailleurs tellement réaliste

>je suppose que tu vois de quel endroit je parle dans la spring yard zone si tu connais bien le jeu : la vitesse ne donne pas l'impression d'être limitée autrement que par le fait qu'au bout d'un moment tu touches le sol
Oui. Elle est au moins limitee a 128 pixels / frame (ce qui est enorme).
Et a cause de cette vitesse trop grande, il arrive que l'on est des bugs de collision qui conduisent a perdre la vie courante.


>Bof...
Pourquoi Bob ?

salut,

Le cas des sauts est quasiment résolu. Il y a juste les grands sauts qui ne sont pas encore terribles. comme j'ai pu lire sur le post, il est question que la vitesse y augmente plus vite que les x. je comprends miantenant de quoi il s'agit.
Effectivement, dans le cas de tokitori, le x bouge moins vite que le y puisque le x maxi est d'une tile. Ou plutôt, x et y doivent être proportionnels, et c'est là que c'est dur.
N'arrivant pas à joindre l'éditeur pour avoir l'info, pour le cas de ce jeu, je pense qu'on a affaire à des sauts triangulaires car les déplacements sont réguliers, je veux dire par là que si on a affaire à un calcul parabolique, si mes souvenirs son bons, les y augmentent vite puis arrivé vers le points où le x s'annulle (je ne me souviens plus) les y ralentissent. Hors, dans le jeu, arrivé au point supérieur, le y va toujours à la même vitesse, en monté comme en déscente. Mais je dis peut-être des bêtises... Pour le moment, le code (un peut beaucoup merdique) donne ceci:

switch (toki->sprite.direction)
{
case DIRECTION_RIGHT:
	switch (toki->jumpHeight)
	{
	case LOW_JUMP:
		if (toki->sprite.location.x-toki->startJump.x < TILE_WIDTH/2)
			toki->sprite.location.y-=toki->speed;
		else
			toki->sprite.location.y+=toki->speed;
				
		toki->sprite.location.x+=2*toki->speed;
			
		if (toki->sprite.location.x-toki->startJump.x > TILE_WIDTH)
			toki->sprite.location.x-=2*toki->speed;
					
		toki->jumping-=toki->speed;
		break;

	case MEDIUM_JUMP:
		// toki do not move left or right during medium jump
		if (toki->startJump.y-toki->sprite.location.y < (toki->jumpHeight)/2)
			toki->sprite.location.y-=2*toki->speed;
		else
			toki->sprite.location.y+=2*toki->speed;
					
		toki->jumping-=4*toki->speed;
		break;

	case HIGH_JUMP:
		if (toki->startJump.y-toki->sprite.location.y < (toki->jumpHeight)/2)
			toki->sprite.location.y-=2*toki->speed;
		else
			toki->sprite.location.y+=2*toki->speed;
				
		toki->sprite.location.x+=2*toki->speed;
			
		if (toki->sprite.location.x-toki->startJump.x > TILE_WIDTH)
			toki->sprite.location.x-=2*toki->speed;
					
		toki->jumping-=4*toki->speed;
		break;
	}

break;

puis code similaire pour la gauche et les sauts frontaux/arrières.
le code est merdique, j'en conviens, mais il reproduit quasiment à l'identique ce qui se passe sur gb.

à mon avis tu dupliques bcp trop ton code, ça va être plus dur à lire et à maintenir... (et accessoirement ton programme va prendre plus de place une fois compilé)
et c'est toujours un bon exercice pour voir si tu as réellement compris ton code dans sa globalité de voir si tu peux le réécrire de façon plus concise


PpHd> ben on peut pas vraiment dire que ça soit difficile de faire une boucle qui examine O(vitesse/taille_tile) tiles, non ?

./48:Non, tu as raison pour les éléments statiques de la carte. Ca se gère facilement. Par contre, il faut aussi gérer les éléments dynamiques, et ca se complique pas mal.

./48 c'est sur que le code est cracra... Comme tout code expérimental, il demande à être optimisé Et je pense qu'il peut se réduire à quelques lignes.

PpHd :
./48:Non, tu as raison pour les éléments statiques de la carte. Ca se gère facilement. Par contre, il faut aussi gérer les éléments dynamiques, et ca se complique pas mal.

Ben c'est pareil, même tu veux être parfaitement précis, i.e. tester l'intersection de f(n+dt) et g(n+dt) et pas l'intersection de f(n+dt) et g(n) ; alors tu peux déterminer une liste de tiles dont l'intersection avec l'objet mobile est non-vide à un moment donné (O(vitesse) tiles), et en cas d'intersection non vide faire une dichotomie en recommençant l'opération pour des sous-intervalles de temps pour trouver le temps t à la précision voulue...


boulifb> Oui, c'était pas un reproche, c'était juste pour te signaler que ça serait intéressant de chercher à le réécrire ^^ (et si c'était évident pour toi, tant mieux )

>Ben c'est pareil, même tu veux être parfaitement précis, i.e. tester l'intersection de f(n+dt) et g(n+dt) et pas l'intersection de f(n+dt) et g(n) ; alors tu peux déterminer une liste de tiles dont l'intersection avec l'objet mobile est non-vide à un moment donné (O(vitesse) tiles), et en cas d'intersection non vide faire une dichotomie en recommençant l'opération pour des sous-intervalles de temps pour trouver le temps t à la précision voulue...
Mais oui, ca m'a l'air trivial a implanter, et tres rapide

./46> 128 px/frame
J'ai l'air bien con avec mes 32 px/frame (8 px/passe sur la map, tout d'un coup pour les objets) à côté
D'ailleurs justement à plus que 32 px/frame de tte façon on passe à travers certains objets
Et pour le moteur de collisions, je ne recalcule pas la physique entre chaque passe, ça "fixe" juste le perso, donc passé 32 on a quelques petits trucs pas forcément naturels/réalistes
Donc je me demande comment ils gèrent ça eux?

PpHd
: Pourquoi Bob ?

Heu pourquoi quoi ? C'était un peu ironique ^^

> Donc je me demande comment ils gèrent ça eux?
Mal Tu arrives facilement à traverser les objets

> Heu pourquoi quoi ? C'était un peu ironique
Un peu

bon, j'ai intégré la physique comme vous me l'avez suggéré... c'est beaucoup mieux ainsi

Pour faire encore plus réaliste, y en a-t-il parmi vous qui connaissent la physique des poussins???