5Fermer7
OrwellLe 16/08/2004 à 17:41
GoldenCrystal
: Pour ça on dit pas jeu de plateau, mais jeu de platte-forme ^^

Lol oui c'est pas la première fois que je fais l'erreur en plus fesses fouet
Brunni
: Je ne sais pas comment tu gères tes pentes, mais je peux te dire que Sonic, c'est plutôt une mauvaise idée pour débuter. :]
Ca je suis bien d'accord, mais je n'ai pas dit que je débutais tongue
Brunni :
Pour tes plate-formes, tu peux utiliser des tableaux, définissant l'offset en Y correspondant à l'offset X de ta plate-forme (tableau(x)=offset_y) de la collision sur le pixel en cours. Par exemple pour une plate-forme inclinée à 26.5651° vers le bas:
{0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7};
En fait, en traçant cette fonction, tu verras apparaître ta pente. Ainsi, avec un position_x modulo 16 (car dans mon exemple chaque tile fait 16 pixels) tu peux déterminer sur lequel pixel de la tile à tester les pieds de ton personnage se trouvent. Et si la position des pieds à cet endroit (modulo 16, forcément) est supérieure à celle qui est définie dans le tableau, alors Sonic se trouve sur la plate-forme. Maintenant tu me diras probablement qu'il se trouve sur plusieurs tiles en même temps; oui mais chaque chose en son temps. Tu devras bien sûr faire plusieurs tests et ce à intervalles de 16 pixels. Par exemple, si ton personnage fait 39 pixels, tu testeras à:
x+0, x+16, x+32, x+39
Comme ça tu es sûr de ne manquer aucune tile.
C'est exactement ce que j'ai fait... oui si ce n'est que je n'utilise pas de table de collisions mais plutot un bout de code asm pour determiner ou se trouve le pixel par rapport a la pente sur le tile (facile pour les pentes mais moins flexible evidemment)
Brunni
: Pour Sonic, je te conseille vivement de ne le faire bouger que d'un pixel par passe, sinon ce sera très dur d'implémenter un moteur de collisions qui soit stable. Prenons le cas où tu veux le faire avancer de 8 pixels, alors tu le feras avancer 8 fois d'un pixel, et ne pas oublier de lancer à chaque fois le moteur de collisions entre deux
On est bien d'accord... C'est malheureusement tres lourd, c'est en partie ce qui me pousse a envisager d'autres solutions sad

Ca ressemble effectivement au principe que j'ai adopté dès le départ, mais ca ne me semblait qu'à moitié satisfaisant, et si je voulais améliorer ca devenait vraiment du bidouillage roll

Le plus difficile je trouve c surtout de faire "coller" Sonic a cette pente en ajustant sa position lorsqu'on a rencontré un obstacle... Et puis par exemple si on fait un saut, on doit tester quelques points du bas du sprite pour vérifier qu'on ne rencontre pas le sol, et si jamais le point le plus a gauche rencontre un sol en pente incliné vers la droite par exemple, il faut veiller a ce que Sonic descende encore suffisamment pour ne pas qu'il s'arrete en l'air avec seulement son point inférieur gauche en contact avec le sol... Le choix de ces points est délicat, il depend de l'obstacle lui-meme en fait :/

Actuellement, je fais comme ça (on sent venir le bidouillage sick):


Pour un perso de 16*24 et des tiles 8*8 (on va faire simple):
# Determination du deplacement à effectuer (sur base du clavier, du temps écoulé etc) : disons 3 pix vers la gauche et 1 vers le bas
# boucle tant qu'il reste un deplacement a faire horiz ou vertic:
> si on doit se deplacer horizontalement:
>> s'il y a un mur sur le bon coté du sprite (ici le gauche), alors arret du perso et plus de dep horiz a faire (il reste un dep de 1 pix vers le bas)
>> sinon si le perso n'était pas en train de sauter, on teste certains points dans un coin inférieur du sprite pour voir si on va aborder une pente ou pas (ici les points (x,y+22),(x,y+23) et (x,y+24). Si un des points est sur une pente, et selon ce point, on sait que le perso devra faire un deplacement de vertical de 1 pix vers le haut ou le bas pour suivre la montee
>> on effectue le deplacement de 1 pix

> si on n'a pas encore rencontré de pente dans le déplacement, et que le perso se dirige vers le bas, on regarde s'il y a un sol plat ou en pente sous le sprite et donc si le perso a les pieds sur le sol

> si on doit se deplacer verticalement
>> si un sol autre qu'une pente avait été repéré précédemment, ou si le perso veut monter et qu'il y a un obstacle au dessus de lui, on arrete le mouvement vertical
>> sinon on effectue le deplacement de 1 pix
# fin de la boucle

# selon les pentes qu'on a rencontrées, on donne au perso une vitesse verticale correspondant a l'élan qu'il aurait pris (faut pas oublier ca non plus...)



C'est vraiment à la limite du bidouillage... En gros ca marche bien, il y a qq imperfections a gauche a droite mais pour les corriger ca encombre vraiment le code... De plus si on veut gerer les collisions avec les objets etc ca se corse encore pas mal sad
Je me demandais donc si qqn a une idée pour tourner ca d'une autre maniere qui le rendrait le principe plus clair en evitant les bidouillages, ou bien si au contraire c la bonne méthode a suivre et si je ferais mieux alors d'implémenter tout ca proprement...


Il y a aussi effectivement le probleme de la gravité qui agit sur le perso et qui peut le ralentir ou l'accélerer... Actuellement je pensais plutot jouer sur les accélérations en fonction de la pente sur laquelle se trouve le perso, mais ca reste difficile pour des cas extremes comme lorsque Sonic grimpe sur un sol à 90° par exemple . Encore un truc à voir roll

Sinon bah si vous avez des idées plus efficaces mais plus lourdes dites-le aussi, le jeu tourne entre 30 et 50 fps tout compris actuellement, donc j'ai encore de la marge wink