MulX (./7) :

Hoshi_ (./5) :
:If S>50 and ST:1->G:End (c'est pour augmenter la vitesse à laquelle augmente le score et la difficulté du jeu) : ... (Il y a plusieurs autres lignes comme celle du dessus alors je passe directement à celle après car seul les valeurs changes)

ça ça doit ralentir

surtout que pour des fonctions aussi simples (escalier –à pas et hauteur constant je suppose ?–) on fait la même chose bien plus efficacement: avec un simple compteur, des int( et divisions, du genre 15-int(S/50) -> T ici si je n'ai pas lu trop vite.
Sur Ti z80 on gagne réellement *beaucoup* de temps à faire de calculs plutôt que des tests...( c'est du à la foi à la bonne implémentation des calculs et la mauvaise du Ti-basic..)
Mais bon c'est pas très immédiat pour un codeur non confirmé.

par contre le minimum très simplement réalisable et compréhensible c'est de tester les valeurs (si =50, 100, 150 ..) et non les intervals.. (test plus simple et pas d'affectation à chaque fois..)
Enfin y'a pleins de bricolages intermédiaires plus efficaces réalisables. ( du genre faire un seul teste avec une variable 'borne' que l'on implémente de l'écart suivant lorsque le teste est vérifié et que l'on fait un truc du genre T-1->T, etc. )


Bon j'ai pas vraiment lu attentivement, (à ce que j'ai vu tout ou presque est très largement améliorable. Je trouve qu'il y a beaucoup de variables et de tests.. ), j'ai juste rebondi sur la remarque précédente... c'était quoi l'objectif de Hoshi_ ?

Bon ensuite les jeux à défilement, faut de préférence utiliser l'astuce du Disp qui fait défiler l'écran tout seul si on se permet le mode texte ( seul moyen pour être un peu rapide, en tous cas de ce que j'ai fait / j'ai vu.).
Dans un vieux jeux que j'avais codé comme ça en 1reS, Racspeed je crois, ça arrivait à avancer assez vite – je veux dire réellement une impression de vitesse–sur 82. (Un seul if dans le programme, celui pour quand on est mort ). Et encore j'étais pas à mon meilleurs à l'époque, suis sur que ça doit s'optimiser..