(Note: je n'ai pas une grande expérience en programmation de jeux )

> > Le programme est un poil plus facile à écrire (franchement, pas beaucoup ), mais moins agréable pour l'utilisateur: même si certaines personnes y sont moins sensibles que d'autre, ne pas faire des affichages synchrones se voit habituellement assez facilement à l'oeil nu.
> Si je comprends bien même avec FastScreenCopy, ce problème n'est pas résolu.
Oui, ce problème n'est pas résolu, puisque FastCopyScreen(_R) ne prend pas plus en compte la synchro que memcpy. Je n'ai jamais écrit que FastCopyScreen(_R) prenait en compte la synchro

> ça pourrait se résumer ainsi :
> Tant que Temps_non_écoulé
> Executer_Traitements();
> Fin
> Affichage();
Dans mon esprit, pas exactement. En fait, ce que j'ai écrit plus haut est assez loin d'être complet...
Pour utiliser au max le processeur, je penserais à un truc du genre:
short state;


state = 0;
if (__switch_cnt<__w ) {
// bout 1 du traitement
state = 1; // Fini le premier bout

if (__switch_cnt<__w) {
// bout 2 du traitement
state = 2; // Fini le deuxième bout

if (__switch_cnt>=__w) {
// bout 3 du traitement
state = 3; // Fini le troisième bout

while (__switch_cnt<__w); // une attente active si par hasard, on finit le traitement avant que le plane switch soit fini;

}
}
}

if (state == 0) {
// faire bout 1 du traitement
state = 1;
}
if (state == 1) {
// faire bout 2 du traitement
state = 2;
}
if (state == 2) {
// faire bout 3 du traitement
}


> Mais, à moins que je ne me trompe, ce temps restant avant le prochain cycle ne sera pas toujours le même lorsqu'on atteindra la fonction Executer_Traitements().
Tu ne te trompes pas

> Ce qui signifie que de manière aléatoire, cette fonction pourra être executée 1 fois, 5 fois, 10 fois, x fois, en fonction du temps restant avant le prochain cycle.
Si on s'y prend mal ou si on désire faire du frameskip, oui.
L'attente active à la fin du traitement que j'ai mis plus haut resychronise avec l'affichage.

> On risque donc d'avoir un programme saccadé non ?
C'est possible que ce soit plus saccadé que la solution proposée par Martial, même si cette solution n'offre pas un framerate exactement constant non plus (de toute façon, il n'y en a pas, puisqu'il n'y a pas de timer synchrone avec le frame sync sur les TI-68k).