gravite.y += vitesseperso.y*;

"Il y a la théorie, et la pratique....
9.81 m.s-2, dans un jeu en 2D? ca rime à quoi? "

Bah c'est l'accélération due à la gravité. Même pour un jeu 2D j'ai tendance à préférer que les calculs soient effectués en mètres avant que la partie affichage du jeu se charge de convertir les coordonnées en mètres en coordonnées écran (en pixels). Ça évite d'avoir à se dire ça : "Quand j'écrit vy += 0.4, c'est au pif. Il faudra que tu choississent une valeur de facon empirique (une grande valeur le fera retomber plus vite).".

Bon à part ça ton code devrait fonctionner correctement, y a juste les while(0) qui risquent de perturber un peu le truc

Merci à vous

Sinon je me souviens ne pas avoir réussi à faire une animation, j'avais fait un while(o) avec mes images dedans qui s'activait si une variable était à 1 ( elle se mettait à 1 lorsque j'appuyais sur la flèche de droite) mais ça ne marchait pas.

En faisant un while(0) je pense que ce que tu as passé du temps à écrire dans ta boucle n'a pas du s'exécuter souvent dans ton code

Ah bon? Il me semble que le while est la seule boucle qui n'a pas besoin de stopper le jeu pour s'activer.
Mais alors comment faire une boucle infinie avec un while?

while(1)

Mais c'est un mauvaise idée, utilise plutot une variable exit que tu met à 1 à la fin du jeu/programme, donc

while(!exit){}

Ah oui pas bête
Mais comment dire
Si la souris est ici ,fait ça.

C'est if( event.button.x = position.x) ?

Ou sinon une fonction pour dire tant que la touche est appuyée, faire ça?

Je parle en SDL.

oula oui while(0) ... lol

"Si la souris est ici ,fait ça.
C'est if( event.button.x = position.x) ?"

c'est event.button.x == position.x (si tu met = tu va faire une affectation). Le compilateur devrait te mettre un warning de toute facon pour ca.

"j'ai tendance à préférer que les calculs soient effectués en mètres avant que la partie affichage du jeu se charge de convertir les coordonnées en mètres en coordonnées écran (en pixels)."
Oui mais ca ca marche que si ton jeu utilise une échelle particulière. Exemple dans Mario, qu'est-ce qu'un mètre? ou dans Sonic? utilisé une constante empirique c'est pour tweaker, ca te permet de changer le feeling du jeu. (et aussi de faire des niveau ou la gravité est plus ou moins forte par exemple, etc).

Ah ouiii.
C'est pas la première fois que je fais cette faute... ni la dernière.

Mais j'ai du mal à comprendre comment un variable peut stocker la vitesse du personnage Il faut qu'elle se mette à jour en fonction de combien de pixel parcours l'objet en un certains temps?

Oui exactement.
En fait c'est cette vitesse qui va te permetre de controller ton personnage.

à chaque tour de boucle, tu va mettre à jour la position de ton personnage en faisant un truc du genre:
position.x += vitesse.x;
position.y += vitesse.y;

ensuite vitesse.x et vitesse.y vont etre conditionner.
Par exemple si tu appuis sur la touche droite, vitesse.x = 2.0 (encore une fois c'est une valeur au pif), touche gauche vitesse.x = -2.0, et sinon 0.0.
Si tu saute, tu fait vitesse.y = 10.0 (mais qu'une fois, au moment ou la touche est pressé). Et si a ca tu ajoute ce que l'on t'as dis (c'est dire si perso ne touche pas le sol, alors vitesse.y -= 0.4), vitesse.y va diminuer de 10.0 à 0.0, puis passer négatif, et faire redescendre ton perso sur le sol (et une fois sur le sol, tu remet vitesse.y = 0.0).

en gros dans ta main loop tu va avoir un code comme ca :

while(!exit) {

// update de la vitesse
if(isPressed(keyRight))
vitesse.x = 2.0;
else if(isPressed(keyLeft))
vitesse.x = -2.0;
else
vitesse.x = 0.0;

// update de al position
position.x += vitesse.x;
position.y += vitesse.y;

// affichage

}

si tu utilise SDL, tu peux tester directement je crois pour savoir si une touche est pressé.

Après attention, les valeurs des vitesses sont relatives à un temps (ici le temps entre l'affichage de 2 frame). Si ton framerate n'est pas constant, il faut calculé le temps écouté entre 2 images, et multiplié la vitesse par ce lapse de temps quand tu met à jour la position. (j'ai le code pour calculer ca avec SDL si tu veux, mais commence déja par ne pas en tenir compte, pour éviter de trop compliqué tout ca).

Mais si la position en y passe de 10 à -0.4 on va pas voir le personnage tomber, si? Il va se téléporter?

justement non, la vitesse vaut 10.0 à la frame ou tu saute.
10.0 c'est un peu grand peut etre, prenons 4

Ensuite quand ton perso ne touche pas le sol, tu enleve 0.4 (on va dire 0.5 pour simplifier les calcul

donc supposons il est a y = 0

la frame suivante il sera à y = 4, et la vitesse sera 4 - 0.5 = 3.5
à la frame t + 1, y = 4 + 3.5 = 7.5 et v.y = 3
t + 2, y = 7.5 + 3 = 10.5, v.y = 2.5
t + 3, y = 13, v.y = 2
t + 4, y = 15, v.y = 1.5
t + 5, y = 16.5, v.y = 1.0
t + 6, y = 17.5, v.y = 0.5
t + 7, y = 18.0 v.y = 0.0 <-- a ce moment la ton perso est a la hauteur max du saut, et il va redescendre ensuite

t + 8, y = 18.0, v.y = -0.5
t + 9, y = 17.5, v.y = -1.0
t + 10, y = 16.5, v.y = -1.5
t + 11, y = 15, v.y = -2.0
etc

jusqu'a
t + n y = 0 (ou < 0, il faut gérer la collision), et la tu remet v.y = 0.

et avec ca tu as une jolie trajectoire de saut

Et ce calcul je dois pas le marquer dans mon code... c'est ce que l'ordi calcule.

ce calcul est juste le déroulement de ce que j'ai écris avant

En fait, a quoi ressemble ton code actuelement? ca sera plus facile pour te guider je pense, avec mes explications j'ai l'impression de plus embrouiller qu'autre chose ;)
(tu peux le mettre en ligne la : http://pastebin.com/, comme ca il sera correctement identé et plus facile à lire).

"Oui mais ca ca marche que si ton jeu utilise une échelle particulière. Exemple dans Mario, qu'est-ce qu'un mètre? ou dans Sonic? utilisé une constante empirique c'est pour tweaker, ca te permet de changer le feeling du jeu. (et aussi de faire des niveau ou la gravité est plus ou moins forte par exemple, etc)."

Avec la méthode que je présente tu peux aussi changer le feeling du jeu en changeant la valeur de la constante g. Par ailleurs, je pense que ta solution risque de poser des difficultés si jamais tu veux faire un zoom ou un dézoom sur la scène comme on en voit dans les jeux 2D récents. Quand tu dézoom, si tu gardes ton "vy += 0.4; y += vy" ça risque de poser problème car les mouvements de chute vont sembler accélérer.
Après j'avoue que c'est des considérations techniques qui n'ont peut-être pas lieu d'être dans le contexte ici, puisque le code marchera quand même avec le vy += 0.4.

J'ai rien dans mon code pour l'instant vu que je code qu'en semaine et j'ai pas eu le temps cette semaine.

"J'ai rien dans mon code pour l'instant vu que je code qu'en semaine et j'ai pas eu le temps cette semaine. "
Ok! je te conseil de commencer par un truc simple (genre juste un sprite), et a partir de la rajouter la main loop, puis les control. Tu verra mieux je pense en ayant du code pour tester.

"Quand tu dézoom, si tu gardes ton "vy += 0.4; y += vy" ça risque de poser problème car les mouvements de chute vont sembler accélérer."
Ca n'a rien a voir avec mon 0.4. Ca dépends si tu utilise la (mauvaise) solution de déplacer ton perso dans le meme espace que l'affichage ou non. Position, vitesse, etc sont exprimé dans l'espace global du jeu. Si après tu zoom ou dézoom, c'est de l'affichage uniquement?

Pour faire jeux mon frère commence par un while(!exit)
et met tout le jeu dedans, c'est une bonne technique?

Yep!

enfin avant le while tu aura toute l'initialisation (chargement des images, initialisation des position etc).

Oui, donc pour faire les animations je devrais refaire un while(!exit) dans le while(!exit) ?