Jeu de plateforme - Page 4

Toi tu reviendras le jour où t'auras quelque chose d'intéressant à dire.

GC & sasume> je crayonne, et il faut aussi rajouter que si tu as des zones qui sont censées ralentir (par exemple de l'eau), tu vas galérer si tu utilises des tables, surtout pour les conditions initiales du changement : si j'ai

jump_y[] = {0,9,16,21,24,25,24,21,16,9,0}

et

jump_y_water[] = {0,4,6,7,6,4,0}

comment je recolle les morceaux si je change de milieu alors que je suis en train de sauter ? En plus ici les maximums de position sont à des indices différents, donc c encore plus galère...


Je ne parle pas non plus du cas où on veut un truc encore plus réaliste, par exemple si on veut faire des frottements dépendant aussi de la vitesse en x du personnnage...(toujours pour modéliser l'eau)

Faut ce mettre d'accord, car là vous me parlez d'un jeu de plateforme avec gestion des masses, frottements.... moi je parle pas du tout de ça, mais bon. Bien sûr que les tables sont meilleurs dans tel ou tel cas et les formules dans d'autres cas. Mais franchement pour un simple mario ou un Kirby, voir un FlashBack, les tables précalculées sont vraiment la meilleur solution.

mais je vois pas en quoi c'est meilleur ! le seul avantage qu'il y a, c'est si on ne sait pas comment faire sans table précalculée, alors on peut faire un petit bricolage à base de tables, même si ça sera moins beau; mais si on connaît la technique pour faire des paraboles (qui est tout sauf difficile à mettre en oeuvre), je ne vois pas pkoi utiliser des tables...

Comprend pas, y a autre chose que les paraboles.
Je crois qu'on parle pas de la même chose là.

sans table :

int x=123,y=32;
int yd=0;

while (!exit_game) {
  if (key.jump && can_jump()) yd=8;
  y+=yd--;
  while (under_ground(y))
    y++,yd=0;

  ... afficher, modifier la position en x ...

 }

l'équivalent avec des tables, c'est

int jump_table[8]={1,3,4,3,1,-4,-10,-20};

int x=123,y0=32;
int jump_idx=-1;

while (!exit_game) {
  if (key.jump && can_jump()) jump_idx=0;
  y=jump_idx<0 ? y0 : y0+jump_table[jump_idx];
  while (under_ground(y))
    y++,jump_idx=-1;
  if (jump_idx<0)
    y0=y;
  else if (++jump_idx>=8)
    jump_idx--;

  ... afficher, modifier la position en x ...

 }

qui est loin d'être plus simple

je vois pas comment tu peux dire que c'est "vraiment la meilleure solution"

J'étais sur le point de poster que l'algo sans table était plus facile et rapide à implémenter, et aussi plus souple et modulable. Merci Pollux pour la démo

geogeo
: Faut ce mettre d'accord, car là vous me parlez d'un jeu de plateforme avec gestion des masses

Heu... la vitesse de chute ne dépend pas de la masse hein....

, frottements....

Pas tellement, on s'en fout un peu des frottements, ça peut s'implémenter d'une manière relativement triviale (limiter les vitesses verticales et horizontales

moi je parle pas du tout de ça, mais bon. Bien sûr que les tables sont meilleurs dans tel ou tel cas et les formules dans d'autres cas.

Ben non, même sans prendre en considération les frottements, les tables s'avèrent fausses comme on te l'a expliqué plus haut (l'accélération ay=g, quelle que soit la valeur de g, et déformer les valeurs de la table modifie la valeur de g utilisée, de façon qu'un saut haut prendra le même temps qu'un petit saut, ce qui ne colle pas du tout et est loin d'être précis, surtout considérant les calculs beaucoup plus compliqués à mettre en oeuvre)

Mais franchement pour un simple mario ou un Kirby, voir un FlashBack, les tables précalculées sont vraiment la meilleur solution.

Heu... Mario, je sais pas, peut-être le premier (et encore je doute) parce qu'il est très ancien, Flashback peut-être, mais là encore je doute, et Kirby, même pas la peinde d'y penser. Pense aux sauts pour lesquels tu pars du bas pour atterrir sur une platteforme plus haute ou l'inverse, les tables se révèlent inutilisables. Et les chutes, ça fonctionne pareil que les sauts (en réalité c'est l'inverse, mais bon... ), alors comment peux tu les gérer?

oui, avec l'algo sans table ça gère sauts et chutes d'un coup

ah oui merci de me faire penser que j'avais pas géré les chutes dans l'algo avec table je vais modifier ça tout de suite ^^

hop j'ai rajouté deux lignes pour gérer ça :

sans table :

int x=123,y=32;
int yd=0;

while (!exit_game) {
  if (key.jump && can_jump()) yd=8;
  y+=yd--;
  while (under_ground(y))
    y++,yd=0;

  ... afficher, modifier la position en x ...
 }

avec table :

int jump_table[8]={1,3,4,3,1,-4,-10,-20};

int x=123,y0=32;
int jump_idx=-1;

while (!exit_game) {
  if (key.jump && can_jump()) jump_idx=0;
  if (jump_idx<0 && !under_ground(y0-1))
    jump_idx=2, y0-=jump_table[jump_idx];
  int y=jump_idx<0 ? y0 : y0+jump_table[jump_idx];
  while (under_ground(y))
    y++,jump_idx=-1;
  if (jump_idx<0)
    y0=y;
  else if (++jump_idx>=8)
    jump_idx--;

  ... afficher, modifier la position en x ...
 }

10 lignes au lieu de 4, sans commentaire...

Au fait, voilà un exemple de l'algo sans table que j'avais codé l'autre jour (just for fun), si ça vous intéresse: http://goldencrystal.free.fr/JumpDemo.zip

Sasume
: (c'est impossible physiquement[...])

On va finir par le savoir

GoldenCrystal :
Au fait, voilà un exemple de l'algo sans table que j'avais codé l'autre jour (just for fun), si ça vous intéresse: http://goldencrystal.free.fr/JumpDemo.zip

.NET...

Moumou>

Moumou
:

Sasume
: (c'est impossible physiquement[...])

On va finir par le savoir

Je ne comprends pas
[edit] : Rapport à la vrille ?

je pense oui

ou alors Moumou et toi avez fait des trucs impossible physiquement

Euh c'est bien beau de me faire de belles sources...
Je te rassure pour mon jeu, j'utilise deux lignes pour faire mes sauts.
Euh quand à la précision des table et j'en passe, je doute que vous voyez ça à l'oeil. D'ailleurs les tables on permit une grande évolution technique dans les jeux., suffit de savoir les maitriser.

Comment ?
geogeo, arrête de nous prendre pour de imbéciles, arrête de te sentir agressé parce qu'on pense qu'une autre technique que celle que tu utilises est meilleure.

Donc peux-tu nous expliquer comment maîtriser les tables de elle sorte qu'elles soient vraiment intéressantes ?
Je ne pose pas cette question pour te piéger, mais honnêtement, depuis le début (sauf le post ./84), tes posts n'ont aucun contenu, tout ce que tu fais c'est dire "n'importe quoi, ma technique est meilleure si on sait l'utiliser" (je parle des posts ./27, ./29, ./31, ./62, ./93, ./95 et ./109).

geogeo :
Je te rassure pour mon jeu, j'utilise deux lignes pour faire mes sauts.

Fais voir ?

Euh quand à la précision des table et j'en passe, je doute que vous voyez ça à l'oeil.

La première chose qu'on ma reproché dans punkoe était que les sauts ne sont pas naturels, c'est aussi une des premières chose que l'on a fait remarquer à mastergb pour kirby.

D'ailleurs les tables on permit une grande évolution technique dans les jeux.

Lesquelles ?

suffit de savoir les maitriser.

Comment ?

Voilà, je me répète un peu, mais ton post fait vraiment preuve de manque de contenu...

Personnelement je prefère pas utiliser de tables précalculée pour des sauts, mais je sais qu'il y a des avantages:
On peu "trafiquer" un peu les valeurs de façons à que les coordonnées du joueur qui retombe concordent avec celle du sol:
Imaginez un joueur qui tombe de tout en haut de l'écran; quand il arrive en bas, il aura une vitesse verticale de 3 pixels seconde. Résultat, il peut avoir les pied dans le sol, et donc utiliser des tables peut etre une solution pour corriger ce pb.

./103 : lol, t fier ?

Il ne faut pas confondre calcul de position et gestion des collisions! En effet, il convient de faire les tests de collisions non pas à chaque nouvelle position, mais de façon transparente depuis l'ancienne position jusqu'à la nouvelle avec un pas correspondant à la finnesse du masque de collision. Sinon on risque effectivement de rater une plateforme ou de rentrer dans le sol ... Et ça n'a rien à voir avec le fait d'utiliser des tables ou pas

Ben le fait d'utiliser des tables peut simplifier la gestion des collisions tout de même...

geogeo
: D'ailleurs les tables on permit une grande évolution technique dans les jeux., suffit de savoir les maitriser.

Ouais trop bien... les tables c'est tout sauf une évolution, c'est un substitut qui comble le manque de puissance de calcul, en échange de place mémoire. La première chose qu'on fait quand on gagne un peu de puissance c'est se passer des tables (cf. Mode 7 sur GBA, où on peut se permettre de calculer un tas de choses en fonction de l'angle de vision, alors qu'on les stockait dans des tables avant, et du coup on a des rendus beaucoup plus précis et dynamiques).

La "maîtrise" t'en as pas besoin pour utiliser des tables... là où t'en as besoin c'est pour t'en passer, parce que à ce moment là tu dois savoir manipuler les équations qui vont bien, et donc savoir faire un peu de physique quand c'est une simulation.
Là où les tables sont encore nécessaires c'est pour des fonctions qu'on ne peut pas calculer (ex: S-boîtes de DES), ou qui coûtent trop cher à calculer (ex: fonctions trigo sur un CPU de base).

Sasume
: Ben le fait d'utiliser des tables peut simplifier la gestion des collisions tout de même...

comment ?

enfin, de quelle manière qui soit plus simple que sans lesdites tables ?

En utilisant ce qu'a dit jfg : en se débrouillant pour que les déplacements successifs du personnage le fassent tomber pile sur une plate-forme (en supposant que toutes les plate-formes sont commencent toujours à la même hauteur des tiles).

Oui, mais tu obtiendras un saut non naturel, et le problème ne se résoud pas.
En effet, en chute libre, il y aura sûrement un moment où la vitesse max sera supérieure à la finnesse du masque de collision.
Enfin, tu peux faire de même en ajustant l'accélération et la vitesse d'origine d'un saut, c'est pas dur.

Ben ouais en fait, on retombe sur le défaut principal des tables : c'est qu'elles ne permettent pas de gérer facilement les cas particuliers. Mais bon, si dans le jeu, la vitesse de chute ne dépasse jamais un certain seuil qui permet alors d'utiliser des tables, pourquoi pas ?
Enfin, il reste le problème que la trajectoire ne sera pas naturelle...

Et puis, ce n'est pas tellement compliqué de gérer les collisions indépendamment du saut, finalement, et ça permet bien plus de libertés, donc vaut mieux ne pas utiliser de tables