Zerosquare (./16) :
- négligeable

Oui, je pense. Un jeu de plateforme 2D de 50*30 tiles (32*32 chacun) ne doit pas avoir de mal à se rafraichir 60 fois par secondes amha, sinon c'est que j'ai raté quelque chose façon grandiose...

Zerosquare (./16) :
Tes animations/phénomènes physiques peuvent-ils être recalculés en temps réel pour s'adapter au framerate, ou pas ?

Non. Et tu soulèves un truc pas con (enfin, moi j'y avais pas pensé...) : si tu te cales sur le framerate, et non sur le temps absolu, faut que la vitesse de tout ce que tu fais soit à géométrie variable pour s'adapter à toutes les fréquences.

Zerosquare (./16) :
As-tu des contraintes de précision à court terme (telle animation doit prendre x millisecondes) et/ou à long terme (le niveau doit durer 5 minutes) ?

Aucunement.

Zerosquare (./16) :
Y a-t-il d'autres sources de synchronisation qui entre en jeu ? (bande son, jeu en réseau...)

Non.

Zerosquare (./16) :
Veux-tu un jeu parfait en 60 Hz mais dégradé aux autres fréquences, ou privilégies-tu l'indépendance par rapport à la fréquence de refresh ?

L'indépendance. J'imagine qu'en synchronisant la fréquence des entrées sur un temps absolu (ie "60 Hz quelque soit la plateforme"), il est facile d'adapter le framerate, non ?

Zerosquare (./16) :
Le tearing est-il considéré comme un problème ou pas ?

Tu parles des effets induits par la suppression de la synchro verticale ? Non.


J'ai commencé à coder comme ça :
-> un thread qui appelle tous les 1s/60 le gestionnaire d'évènements. Suite à quoi il y a le rendering, qui met un flag ready_to_draw à vrai.
-> un thread qui regarde le flag, et qui fait un SDL_Flip quand c'est prêt, puis remet le flag à false

Ca fait une seule variable partagée entre les deux threads, donc rien de compliqué question locks.

C'est correct comme méthode ? En tout cas, la vitesse du jeu est réglée sur un timer, vu que c'est la fréquence des évènements qui régule la vitesse de la physique et des animations.