OK, je viens de relire ton post, et je vois que tu as 3 étapes d'animation. Fondamentalement, c'est pas dans le choix de l'étape d'animation que tu vas gratter énormément, puisque ça ne représente qu'une part infime du travail d'affichage. Le plus rapide sera évidement une routine de branchement de type dichotomique :
/* unsigned char */ l_nAnim = l_nAnim + 1;
/* unsigned char */ l_nMask = 0x02;
if((l_nAnim & l_nMask) == 0)
{ /* Etape 0 *ET* 1 */
l_nMask = l_nMask >> 1; /* On décale le masque pour tester les étapes 0 *OU* 1 */
if((l_nAnim & l_nMask) == 0)
{ /* Etape 0 */
...
}
else
{ /* Etape 1 */
...
}
}
else
{ /* Etape 2 *ET* 3 */
l_nMask = l_nMask >> 1; /* On décale le masque pour tester les étapes 2 *OU* 3 */
if((l_nAnim & l_nMask) == 0)
{ /* Etape 2 */
...
}
else
{ /* Etape 3 */
l_nAnim = 0; /* On ré initialise le compteur d'animation */
}
}
Bon, évidement, quand tu n'as QUE 3 étapes, le gain n'est pas bien important, mais on passe quand même de 3 tests max (quand tu as l_nAnim == 2) à maximum 2 tests (et encore tu économise le test de départ pour savoir si l_nAnim == 3). Si tu avais 256 étapes, plutôt que d'avoir 256 tests maximum, tu n'en aurais que 8 tout au plus. Par contre il faut 'dérouler' les tests de façon dichotomique (0-127/128-255, puis 0-63/64-127 et 128-191/192-255, ...) et non plus linéairement (0, 1, 2, 3, ...) !
Autre avantage ducoup, la vitesse de traitement est linéaire et prédictive, puisque tu sais qu'il y auras TOUJOURS 8 tests pour déterminer l'étape d'animation, contre 1 lorsque tu est à la première étape, et 256 quand tu est à la dernière.
Kochise, grand amateur d'algorithmes épicés
:
