Handling of slopes.

Okay. It might be a little pathetic ... I've spent some time figuring out an algorithm for properly handling slopes in my platformer, but i didn't found the time to properly inject it into code, so I just speed-typed it in a draft post. One of the key ideas is that you won't try to adjust frame t's horizontal speed to the slope you have to cross, but instead defer the effect of climbing dy pixels to the next frame's horizontal speed. This allows a one-pass while all my previous attempt had to iterate until they find the position you'd actually take given the slope you have to climb.

• dx : horizontal speed for this step.
• tile(x) : returns the tile holding a given coord.
• end_of_tile(x, dir) : last pixel of tile containing x ends when you go towards dir.
• next_tile(x,dir) : first pixel of the tile after tile containing x when you go towards dir. next_tile(x, dir) == end_of_tile(x, dir) + (dir>0)?1:-1
• ground_height(x,y) : in the tile under (x,y), the height of the ground at specific location (x,y). 0 means "this is a sky tile", there is no ground to stand here. -1 is the lowest pixel of the tile, at -7, you should be on the highest pixel of the tile, and at -8, you should actually not be on this tile, but on the lowest pixel on the one just ahead.
  

Since we don't know how the slope "continues" to the next horizontal tile, we have to "pause" at the end of each tile in order to compute the Y coordinate we'd have then. When dx < TILE_SIZE

new_x = x + dx
while (tile(new_x) != tile(x)) {
  gh = ground_height(end_of_tile(x,dx),y);
   if (gh!=0) y = end_of_tile(y,1) +gh;
  x = next_tile(x,dx);
}

Now, we know what height we have when we enter tile(new_x). We just have to compute where we'll end in that tile and we've finally done.

if (ground_height(new_x, y) == 0) {
  new_y = end_of_tile( next_tile(y,1), 1) + ground_height(new_x, next_tile(y,1));
} else {
  new_y= end_of_tile( y, 1) + ground_height(new_x, y);
}

Quick Note : the 'x' and 'y' are copies of the object's hotspot position, and the result of the algorithm is the new_x, new_y position at which the GOB's hotspot should be moved. I still have to figure out where cando(new_x, new_y) should be applied to ensure walking slopes do not allow one to move through walls, etc. I also have to figure out how to integrate this properly with the OO model I have so far : what is under the responsibility of iWorld, iGobController and GameObject.

C'est par manque de temps que ce petit algorithme de gestion des pentes se retrouve sur ce blog plutôt que dans le code. Une des idées simplificatrices de base (par rapport aux essais précédents) est qu'il n'est pas nécessaire de traiter immédiatement l'effet de la pente sur la vitesse horizontale (je ne sais pas vous, mais moi, je vais généralement moins vite en montée qu'en descente). A la place, je peux utiliser l'élévation du sprite à l'instant t-1pour ajuster sa vitesse horizontale à l'instant t... Le résultat, c'est que le calcul de la position actuelle peut être effectué en une seule passe, se basant exclusivement sur la fonction ground_height() qui retourne pour chaque position horizontale dans un tile pentu la hauteur de la pente depuis la base du tile.

ancien post-scriptum: je ne vous ai pas oublié, mes lecteurs francophones (près de 50% d'entre-vous). Vous aurez peut-être compris que ce billet fait office de "pseudo-code retapé en vitesse et commenté". Le temps de loisir est distillé au compte-goutte ces temps-ci, entre les dents de *deline et les grands rangements de la maisonnette qui en a bien besoin.