Bah, uploade déjà la routine par décalages de bits. C'est pour voir si c'est plus beau (en sachant que ça risque de rester assez moche dans le sens 240->160, mais il n'y a pas grand chose à y faire).
Donc, il ne doit pas y avoir grande différence, vu qu'elles utilisent le même algo...
Je vais la regarder. Mes routines, d'après le compteur de clocks de VTI modifiée par JM, qui est raisonnablement fiable dans ce cas précis (il y a peu de shifts), seraient vers 70 FPS en B/W.
La qualité est intéressante, il faut que je fasse la comparaison avec la mienne.
En revanche, pour le code, tu as carrément exagéré sur le déroulage de boucles !
Il y a un bug dans la mienne: pas assez de recopies de ligne. J'ai vérifié que la tienne est correcte de ce point de vue-là.
Quand tout sera au point, il faudra faire un programme tout fait comme base d'un vote d'utilisateurs (affichage du dessin original, puis dans une boucle, le dessin scalé avec l'une puis l'autre routine, changement avec n'importe quelle touche sauf ESC, jusqu'à ce que l'utilisateur en ait marre - ESC). Je trouve que la qualité de la tienne est plutôt meilleure, quel que soit le tableau de conversion de 2 pixels en 3 pixels que j'utilise (l'un marche très bien pour les strings, l'autre moins bien). Je n'ai pas fait de bench pour la vitesse.
Tu devrais changer la calling convention de ta routine: les planes dans a3 et a4 ne sont vraiment pas ce qui se fait de mieux (ce sont les deux seuls registres d'adresse utilisables presque en permanence !).
Pour des performances maximales dans la demo, tu devrais utiliser d'une part un _keytest_optimized, d'autre part une fonction optimisée pour le sprite (GraySprite8_XOR_R dans le cas d'ExtGraph).
> Evidemment ça ne doît pas être sans rapport avec la vitesse, mais faire des tests à chaque boucle pour savoir si il faut dupliquer la ligne j'ai préféré éviter.
Hmm, ça prend un temps négligeable par rapport au reste.
Sans être méchant, une routine faite de la sorte rentre dans la catégorie "optimisation vitesse extrémiste". L'optimisation extrémiste dans un sens ou dans l'autre gagne très peu dans un sens, mais perd énormément dans l'autre.
Exemples: optimisation vitesse extrémiste du ClearScreen avec movem, complètement déroulé, avec transfert de 60 octets à la fois (je l'ai fait il y a longtemps pour m'amuser: ça gagne environ 1%, mais la taille de la routine explose); optimisation taille extrémiste du ClearScreen de PedroM (la copie byte par byte avec boucle étroite, rend le ClearScreen de PedroM plusieurs fois, je crois que c'est plus de 5 fois, plus lent que celui d'AMS).
Dsl, j'ai pas eu le temps de traduire le lisez-moi en anglais.
Peut-être une petite release sans, mais bon, y a rien d'autre de bien nouveau...
Comme qui dirait, "il ne faut jamais vendre la peau de l'ours avant de l'avoir tué" ^^
> Je ne donne qu'une version compatible oncalc, c'est plus simple que d'avoir plein de versions différentes
Alors j'aurais tendance à penser que le source est mal fait... Je ne sais pas si c'est le cas pour grav, mais plusieurs fichiers séparés dont chacun ne s'occupe que d'un modèle est une perte de temps et une source de bugs (oubli de report de correction dans l'un des fichiers, etc.).
Un source qui contient ce qu'il faut (qui n'est vraiment pas compliqué) et quelques TIGCC projects (ou batches) suffisent pour faire de l'incompatibilité on-calc vraie (pas OPTIMIZE_CALC_CONSTS !) - c'est à dire des programmes plus efficaces. Voir les programmes de TICT.
) 
Pas mal celle là 
