[VG5000] Lode Runner

[Xavier_]

Merci Hervé.

[__sam__]

Je crois qu'on peut encore gagner:

Code : Tout sélectionner

IFNOT(E=0ORE=3OR(E=6ANDG<>0)) GOTO538

peut être ré-écrit en

Code : Tout sélectionner

IF E<>0 AND E<>3 AND (E<>6 OR G=0) GOTO538

(not en moins). Ensuite

Code : Tout sélectionner

IF (F=0ORF=3ORF=4OR(F=6ANDG<>0)ORF=7ORF=8)THEN

peut être optimisé avec une look-up table sur F,G (en les supposant aller de 0 à 8 ):

Code : Tout sélectionner

REM a ne fait qu'une fois en début de programme:
DIM LUT1(8,8):FOR F=0 TO 8:FOR G=0 TO 8:LUT1(F,G)=F=0ORF=3ORF=4OR(F=6ANDG<>0)ORF=7ORF=8:NEXTG:NEXTF
....
REM plus loin dans le code
....
IF LUT1(F,G) THEN

(ca marcherait aussi avec une autre LUT pour E et G oeuf corse.)

[Xavier_]

Salut Samuel,
Bravo pour l'astuce du tableau !

[joaopa]

@sam > Tu peux développer l'hitoire de table look-up?

Sinon, je pense qu'en temps de chargement d'un tableau, ça doit aller ça
Qu'en penses-tu, Guillaume?

runtab.zip

(1.54 Kio) Téléchargé 133 fois

[Xavier_]

Joaopa, tu te proposes donc pour un écran de présentation !

Oui, ce serait bien, mais ça prend de la place mémoire…
Mais l'idée, est loin d'être bête, car même en chargement, l'affichage serai plus rapide.


Guillaume, ma dernière version avec la touche 'T' pour passer au tableau suivant!
Format K7:

RunnerTest.zip

(5.01 Kio) Téléchargé 98 fois

Note:j'ai encore un petit bogue au niveau de la dépose de la bombe à droite.

[__sam__]

@Joaopa ben tu vois, je mets dans un tableau LUT(F,E) toutes les valeurs de l'expression en fonction de F et de E. Ainsi l'expression "lourdingue" est pré-calculée. Au lieu de l'évaluer à chaque cycle du programme (ce qui est coûteux), ici je n'ai qu'à lire une case d'un tableau 2D. C'est nettement plus rapide en temps CPU, au prix d'un peu de perte mémoire (ici 9*9=81 entiers, soit 162 octets de ram). Tu peux appliquer cette stratégie pour toutes les expression un peu complexes et dont les paramètres (variables) sont à la fois peu nombreux et avec peu de valeurs possibles.

[joaopa]

Merci Sam. C'est très clair et malin...

@Guillaume. Dans les lignes 500 et 501, C=0. Mais pas dans les lignes 502 et 503. C'est voulu?
A quoi sert cette variable C? Juste un compteur de temps pour la ligne 506?
Si oui, je ne vois pourquoi ce compteur ne serait pas initialisé si on fait sauter sur place le héros?

[Xavier_]

Alors, c'est la variable que j'ai ajusté sur ma version.

Code : Tout sélectionner

MOUVEMENT DU HEROS
500 REM == HERO MOVES ==
500 IF STICKX(2)=1 THEN NX=X+1:C=0:D=0:GOTO 509
501 IF STICKX(2)=255 THEN NX=X-1:C=0:D=0:GOTO 510
502 IF STICKY(2)=1 THEN NY=Y+1:D=0:GOTO 510
503 IF STICKY(2)=255 THEN NY=Y-1:D=0:GOTO 510
Touche Espace, pour creuser
504 IF ACTION(2)=1 THEN GOTO 585
Touche S pour Suicide
505 IF KEY(0)=115 THEN GOTO 560
Au bout d’une certaine attente, 30 cycles sans mouvement du héros, le héros est affiché en position d’attente et le Bonus Score commence à
diminuer
506 C=C+1:IF C>30 THEN BS=BS-20:SOUND 180,1:C=0:D=1:E=T(X,Y):IF E=0 THEN CURSORX X+SX:CURSORY Y+SY:ET CO(9):PRINT CHR$(109)
Bonus score ne peut pas descendre en dessous de 0.
507 IF BS<0 THEN BS=0
508 GOSUB 418:RETURN

C est la variable de comptage de décrémentation du bonus.
Par tranches de 30 points, le bonus se décrémente de 20.
Le problème dans la version originale, c'est qu'en accélérant la boucle principale, le bonus tombait toutes les 2 secondes !
En déplacement, le compteur était remis à zéro à chaque bond… donc en sautant tout le temps, le bonus ne tombait pas.
Donc, j'ai adapté le temps de décrémentation en mouvement (saut+déplacement) et la décrémentation statique pour homogénéiser le décompte.
… sur la version test.

Modifs:

Code : Tout sélectionner

500 C=C+1:IFC>30THENC=0:GOTO 450
501 IFSTICKX(2)=1THENNX=X+1:D=0:GOTO 509
502 IFSTICKX(2)=255THENNX=X-1:D=0:GOTO 510
503 IFSTICKY(2)=1THENNY=Y+1:D=1:E=0:GOSUB920:GOTO 510
504 IFSTICKY(2)=255THENNY=Y-1:D=0:GOTO 510
505 IFACTION(2)=1THENGOTO 585
506 IFKEY(0)=115 GOTO 560
507 IFKEY(0)=116 THEN G=0:GOTO 590
508 C=C-.5:RETURN

Donc, comme à chaque mouvement on avait un GOTO, la décrémentation ne se faisait qu'en statique… ligne 506 sur l'original.
Ici, le décompte se fait en tête, et la position en roue libre, est modérée par un demi point pour éviter une chute trop rapide.

KEY(0)=116 = "T" pour passer au tableau suivant pour le débogage.

[Xavier_]

Je parlais d'un bogue de placement, voici le correctif:

Code : Tout sélectionner

500 C=C+1:IFC>30THENC=0:GOTO 450
501 IFSTICKX(2)=1THENNX=X+1:D=2:GOTO 509
502 IFSTICKX(2)=255THENNX=X-1:D=0:GOTO 510
503 IFSTICKY(2)=1THENNY=Y+1::E=0:GOSUB920:GOTO 510
504 IFSTICKY(2)=255THENNY=Y-1:D=0:GOTO 510
505 IFACTION(2)=1THENGOTO 585
506 IFKEY(0)=115 GOTO 560
507 IFKEY(0)=116 THEN G=0:GOTO 590
508 C=C-.5:RETURN

D=0 ou 1 > vue vers la droite.
D=2 ou 3 > vue vers la gauche.

CF. UDG:

UdgRunner.JPG (155.58 Kio) Consulté 3683 fois

[Guillaume]

Bonjour à tous,

C'est la fete ici! Beaucoup de bonnes idées pour améliorer les performances du jeu.
Etant bien occupé par ailleurs, j'ai du mal à suivre tous les développements en cours.
Je ne sais pas si le sujet a déjà été abordé par l'un d'entre vous, mais on constate que les améliorations dans le code, nécéssaires et utiles, n'apportent pas toujours des gains importants sur les performances. Ma perception c'est que les nombreux tests pour les déplacements du héros et des ennemis sont la partie la plus gourmande du code (je dirais 2/3 grosses mailles) et les aspects graphiques un tiers.
En ce qui concerne les nombreux tests pour les déplacements, c'est une méthode employée souvent, c'est de remplir un deuxième tableau avec les configurations des déplacement possible en fonctions de l'environnement. Qui reprendrait en sorte les tests mais en les figeant dans ce deuxième tableau qui donnerait pour chaque case les déplacements possibles sans avoir à les recalculer. Gain de temp, mais perte de mémoire de 500 octet environ, soit 4 levels du jeu stockés en moins. Mais le gains dans le code pourrait venir compenser cela.

[Guillaume]

@sam > Tu peux développer l'hitoire de table look-up?

Sinon, je pense qu'en temps de chargement d'un tableau, ça doit aller ça
Qu'en penses-tu, Guillaume?
runtab.zip

Oh mince, je viens de tester, c'est magique, c'est instantané!! Bravo bravo!
Mais tu fais la lecture des données et l'affichage dans un temps aussi faible?

[Papy.G]

Dans mon Mastermind sur Casio, je faisais appel à une astuce de précalcul, pour obtenir un gain de vitesse conséquent. Le précalcul était effectué pendant la phase préliminaire, avant même que le joueur fasse une remière hypothèse. le gain de vitesse était obtenu à la fois par la simplification des calculs, et par conséquent, par la réduction du programme, qui donne des résultats spectaculaires quand elle a lieu dans les boucles.

[joaopa]

Oh mince, je viens de tester, c'est magique, c'est instantané!! Bravo bravo!
Mais tu fais la lecture des données et l'affichage dans un temps aussi faible?

C'est l'avantage de l'assembleur. Et encore, j'adapte à l'arrache ton programme. Si les performances de jeu ne sont pas au rendz-vous, j'apporterai des modications dans la structures du programme. La plus importante que je vois est dans la taille du tableau:29x16. Ce n'est pas habituel. Il faut prendre en compte que l'on travaille sur une machine 8 bits pour pouvoir utiliser les instructions de l'assembleur pour atteindre les cases du tableau. En général, on prend un tableau 32x16 (multiples de 8 ) et on le place à une adresse UV00h. C'est alors très facile d'aller à la case (X,Y) en assembleur. Avec un tableau 29x16 l'idée serait de placer les lignes en les adresses :UV00h, U(V+1)00h, U(V+2)00h, etc. Alors evidemment, on perd 256-29=227 octets par lignes. On pourrait compléter l'espace disponible par la definition des tableaux (environ 60 octets par tableau), les chaînes caractères, des caractères setet et des variables et aussi les petites sous-routines. Au final, je pense que l'on ne perdra pas beaucoup de place mémoire. Il serait chouette que tu programmes la routine CHASE pour avoir le jeu complet. C'est plus facile à agencer en asembleur quand on a tout plutôt que des parties ajoutées an allant.

J'ai oublié de préciser. Pouvez-vous tester le fichier runtab.wav sur un VRAI VG5000? Je n'ai pas le mien sous le coude. Et on cannaît tous les joies de l'EF9345 et ses subtilités d'affichages. Merci d'avance.

runtab.zip

(6.32 Kio) Téléchargé 104 fois

[Xavier_]

Salut,

J'ai intégré la routine de Markerror à ma version… et personnellement, il m'est difficile de vous dire s'il y a une différence, tellement j'ai joué et débogué le jeu!

Donc,

Ma version sans patch et la version patchée par MarkError (format texte et K7):

LodeRunner_test.zip

(20.46 Kio) Téléchargé 104 fois

Mais, le patch est peut-être plus utile dans la version moins optimisée du jeu, dans sa partie Basic.

Pour synthétiser la méthode de la modification du code original, et sans donner de leçons en la matière…
(Car la programme était bon, et même bien conçu…)

Mais avec une méthode plus simple, avec des copiers/collers, une vue globale du programme, sans retaper toutes les lignes… et sans avoir à imprimer le programme et de le modifier sur papier… comme à l'époque.

Les modifications portent sur une simplification et le regroupement des lignes.
Car moins il y a de lignes, moins il y a d'instructions… plus le programme est rapide.

Donc un petit nettoyage et quelques petites astuces pour éviter des conditions inutiles il est possible d'améliorer un code en Basic.

Petite surprise au niveau de ce Basic qui est plutôt sympa et rapide, mais le manque de fonctions graphiques notamment le test d'un caractère à l'écran, plombent les possibilité de ce Basic.

Donc, au final, le Basic est paresseux, n'aime pas les instructions trop compliquées et les sauts de lignes le ralentissent.

Comme tous les Basics d'ailleurs.

[Guillaume]

Oh mince, je viens de tester, c'est magique, c'est instantané!! Bravo bravo!
Mais tu fais la lecture des données et l'affichage dans un temps aussi faible?

C'est l'avantage de l'assembleur. Et encore, j'adapte à l'arrache ton programme. Si les performances de jeu ne sont pas au rendz-vous, j'apporterai des modications dans la structures du programme. La plus importante que je vois est dans la taille du tableau:29x16. Ce n'est pas habituel. Il faut prendre en compte que l'on travaille sur une machine 8 bits pour pouvoir utiliser les instructions de l'assembleur pour atteindre les cases du tableau. En général, on prend un tableau 32x16 (multiples de 8 ) et on le place à une adresse UV00h. C'est alors très facile d'aller à la case (X,Y) en assembleur. Avec un tableau 29x16 l'idée serait de placer les lignes en les adresses :UV00h, U(V+1)00h, U(V+2)00h, etc. Alors evidemment, on perd 256-29=227 octets par lignes. On pourrait compléter l'espace disponible par la definition des tableaux (environ 60 octets par tableau), les chaînes caractères, des caractères setet et des variables et aussi les petites sous-routines. Au final, je pense que l'on ne perdra pas beaucoup de place mémoire. Il serait chouette que tu programmes la routine CHASE pour avoir le jeu complet. C'est plus facile à agencer en asembleur quand on a tout plutôt que des parties ajoutées an allant.

J'ai oublié de préciser. Pouvez-vous tester le fichier runtab.wav sur un VRAI VG5000? Je n'ai pas le mien sous le coude. Et on cannaît tous les joies de l'EF9345 et ses subtilités d'affichages. Merci d'avance.
runtab.zip

C'est vraiment super. Grace à l'ensemble des contributeurs, et en particulier toi et Xavier, markerror, Papy.G,... j'ai maintenant bon espoir que l'on peut en faire un jeu bien rapide!
Je vais ne pas laisser tomber l'energie et faire mon possible pour finir le code pour le CHASING mode (je suis très occupé par mon boulot). Mais je sais ce qu'il faut écrire et ca peut ne pas être long. Je vais essayer ce week-end!