non non

ton while(!exit), c'est ta main loop, tout ce que ca va contenir, c'est le travail à faire pour une image! Tu as un seul while.

je connais pas en détail les principe d'affichage de SDL, mais essais de trouver un tutorial ou autre sur lequel se baser pour commencer.

Les dégâts du site du zéro en direct.

Sincèrement pourquoi personne ne se rend à l'évidence ici que quand le concept d'une boucle while n'est même pas assimilé et compris cela ne sert à rien d'aller plus loin et cela présage rien de bon sur les autres notions qui passent avant d'atteindre celui du sdz. Mon conseil, arrête tout de suite de te faire du mal, reprends tout à zéro calmement sur un autre site comme celui de la méthode NGCK de Lapintade.

Parce que bon là, simuler de la physique dans une boucle graphique événementielle... c'est un peu hors-portée quand on sait pas comment fonctionne des booléens ou des boucles primaires.

Mouais, c'est pour ça que j'ai dit qu'au pire je pouvais attendre l'année prochaine. Rien ne vaut un vrai prof

Faux. La programmation ça reste une discipline assez solitaire pour le coup.

Va sur le site que je t'ai recommandé c'est bien mieux que le sdz.

Ah ok
J'irai voir alors

"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?"

Au temps pour moi on s'était plutôt mal compris. Pour moi il n'y a que deux types de coordonnées dans un jeu, les coordonnées espace et les coordonnées écran. Et j'ai tendance à considérer les premières en mètre et les secondes en pixels. En disant que la notion de mètre n'avait pas de sens pour toi, j'ai cru que tu opérais tes déplacements en pixels donc dans les coordonnées écran.
Mais visiblement tu penses bien à faire le changement de base entre les coordonnées espace du jeu et les coordonnées écran de l'affichage. A partir de ce moment là il n'y a aucun problème à considérer que les coordonnées utilisées pour le jeu sont implicitement en mètre, ça permet de normaliser les calculs en utilisant que des unités SI. Et si on pose que Mario mesure 1m et que la constante de gravitation est de 9.81m.s-2 on pourra prédire ou ajuster intuitivement les mouvements de Mario dans le jeu avant même de l'exécuter. Sinon on pourrait tout aussi bien considérer que Mario mesure 200m et adapter la constante g en conséquence, le choix de l'échelle est libre et implicite (il dépend de la transformation opérée entre le passage des coordonnées espace aux coordonnées écran).

Aldebran:
En fait il peux meme y avoir plusieurs espaces (meme si dans un jeu en 2D c'est plus rare).
Mais ce que je voulais dire, c'est que dans Mario il n'y pas de correspondance avec les mètre. Et que donc la valeur de la gravité à utiliser n'a pas de lien avec g.
Même dans des jeux plus "simulation", les constantes physiques sont rarement utilisé tel quel (dans un jeu de voiture par exemple, on est obligé de tweaker les valeurs utilisées, les frottements générés par les roues, les constantes des amortisseurs, les couples utilisé par un moteurs, etc).