[VG5000] Lode Runner

[Guillaume]

Hervé (Markerror),
Avec un SCROLL Basic, normalement, ça efface l'écran que tu as paramétré ? (ligne par ligne)

Edit:
Et j'ai Ga-Gné !
… Et j'ai Ga-Gné !
… Et j'ai Ga-Gné !

test3.jpg

Si les 10 premiers niveaux t'ont plus, Il y a 20 niveaux de plus à venir!

[Xavier_]

Oui, Guillaume.

Si les 10 premiers niveaux t'ont plus, Il y a 20 niveaux de plus à venir!

C'est une superbe nouvelle.

Les premiers sont variés, et se prêtent bien à un jeu intuitif.
J'ai rejoué à la première version, et le gameplay est plus rigide… trop planifié et moins spontané.
Ce qui était bien, mais il se base plus sur une planification d'apprentissage de niveau… alors qu'avec la version alternative, on peut se rattraper sans avoir à refaire des tours et des détours.
Vu que le décomptage du bonus a été modifié, et qu'il baisse lors des déplacements, les pénalités de déplacement accélère le jeu… et la possibilité de faire des erreurs, aussi.

Si le code de Markerror peut être implanté sur cette version, avec un BLOAD ce serai cool pour la version finale.

Je vais modifier l'offset mémoire des rems, pour les placer en tête de programme.
Relire le programme pour voir si on peut encore améliorer la vitesse…

[Edit MàJ : viewtopic.php?f=25&t=10880&p=164541#p164541]

Version K7 ( CLOAD et RUN) :

lode-runner_Alt.zip

(5.02 Kio) Téléchargé 100 fois

[Markerror]

Xavier, BLOAD, ca n'existe pas sur vG5000 . On fait un beau CLOAD a la place et le système se débrouille.

Pour la problématique d'encombrement mémoire, la routine peut être "remontée" en la recompilant sous Winape par exemple (maximum &7EA0 pour un VG5000 16ko en priant pour que le système ne mette rien en haut de la ram mis à part la pile), mais il faut que le programme protège cette zone avec un CLEAR 200,&"7E9F" avant de charger en mémoire la routine).

Pour les niveaux, vous pouvez toujours faire une version qui les charge en mémoire au lieu de les intégrer dans des REM ( ce qui est entre parenthèses plutôt bien trouvé même si à l'époque, taper un listing de ce genre aurait été un cauchemar sans nom ).

patch_lode runner_v5.zip

(5.2 Kio) Téléchargé 105 fois

Pour gratter de la mémoire, il y a quelques techniques de base à appliquer : supprimer les blancs inutiles, pré-charger les redéfinitions graphiques dans un autre fichier, etc... Mises bout à bout, ces méthodes permettent de faire des gains parfois non négligeables.
Une à laquelle je n'avais pas pensé jusqu'à maintenant... Remplacer au maximum les <= et >= par des conditions simples < ou >. A chaque fois, un octet de gagné ! Reste à savoir si à l'exécution c'est plus lent ou rapide...

Dans le listing, il y a quelques commandes CURSORY et CURSORX qu'on peut dégager. C'est de la place et du temps gagné !

[Xavier_]

Ok, merci Hervé.

Mais pour notre problème mémoire, ne peut-on pas placer ton code dans des REMs?

Comme ça le Basic fait ce qu'il veut… et Guillaume pourra ajouter ses REMs sans se soucier des débordements mémoire.

Oui, je sais ça va être chaud de couper ton code en morceaux de 123 octets…
Et de faire les réservations des herders lignes.
Et de calibrer tes JP et JR sur les routines externes…

Surtout qu'a la compilation, tu ne saura pas forcement la taille des blocs… je regarde ça sur mon émulateur ZX81 avec des REMs fixes.
Par contre, y a-t-il des caractères interdits dans les REMs, qui peuvent désorganiser le Basic?
Tag de fin de ligne, caractère spéciaux…

Je regarde ta mise à jour...

[hlide]

Le code de Markerror n'a pas de source assembleur !? parce qu'autrement un ORG à la bonne adresse, des EQUs sur les adresses externes, le binaire sera plus rapide à mettre jour et il suffira de coder rapidement un outil pour lire ce binaire et le transformer en ligne de REM de 127 octets. A moins que je n'ai manqué quelques subtilités, bien sûr.

[Xavier_]

Si Si hlide, tout est là.
Mais je travail sur mon émulateur, car sur Zx81, la technique est courante… car l'assembleur ne pouvait pas faire de gros fichiers binaire… des blocs de 4K maxi…
Donc il faut couper le binaire avec 2 ORG, un a "4A01" et un en "4A83" avec 6 NOP entre les deux.

RAM1.JPG (29.02 Kio) Consulté 3584 fois

RAM2.JPG (29.02 Kio) Consulté 3584 fois

Et, oui,
Pas simple à mettre a jour…
Il faut couper le binaire en deux, et les insérer dans la fenêtre "mise au point"
… le binaire fait 346 octets, donc…
Usine à gaz…

Hervé, tu relèves le défi ?

[Oui, pas simple, Des DJNZ... ne pourront pas être coupés… et il faut mettre des JR en fin de ligne… et redéplacer la lecture des REMs tableaux.
C'est peut-être bien pour les petites routines, mais si on ajoute des JP,JR et tout et tout, Hervé va pas être contant de perdre des cycles.]

[Markerror]

Euh, c'est vraiment se compliquer la vie que de mettre du code en REM, mais en théorie, je ne vois pas pourquoi ça ne fonctionnerait pas.
Je regarde ce que je peux faire pour réduire la taille de la routine et la séparer en deux blocs. Evidemment, ça fera perdre quelques cycles, mais bon, ça ne changera pas grand chose au final.

[Edit] Bon, la routine a fondu, elle fait maintenant moins de 256 octets. Ca tiendra normalement en deux lignes REM avec un minimum de paramétrage.
Il me faudrait par contre les adresses d'implantation du code pour les deux lignes. C'est &4A01 et &4A83, c'est çà ?

[Markerror]

J'ai laborieusement réussi à faire ce que Xavier demande, mais bon, c'est tout crado au niveau affichage... Apparemment, même en REM, le VG5000 semble vouloir interpréter des codes de commandes. Bref, pas forcément terrible je trouve.

Pour intégrer en ram la routine sans que tout plante, j'ai usé d'une technique primitive mais qui fonctionne : réserver l'espace au préalable avec un listing Basic occupant le même espace mémoire. Il faut le charger en mémoire, puis avec la commande magique <F9>, charger en &49FC le fichier binaire EF9345. Après, un petit LIST vous donne un aperçu du carnage, mais... Un CALL &4A01 montre bien que le programme est opérationnel.

Je reste partisan d'un chargement "propre" de la routine en haut de la mémoire disponible. Ce test aura eu au moins le mérite de m'obliger à remettre un peu le nez dans la routine et voir qu'on pouvait la dégraisser gentiment.

[hlide]

Ok, je vois le topo. Et du coup je comprends mieux la raison de la formule "magique" suivante : V=PEEK(A+OS+(INT(OS/123)*6)). Cette formule semble indiquer que tous les 123 octets il faut faire un saut de 6 octets - ça ressemblerait à un saut par REM présent.

[Xavier_]

Merci Hervé,
Je vais reconstruire les REMs…

Oui hlide, c'est exactement ça.
A est l'adresse de début des REM, et le saut se fait de REM en REM en sautant le Header (n°de ligne/taille) et le tocken &8E qui correspond à la commande REM.

[Guillaume]

Ok, je vois le topo. Et du coup je comprends mieux la raison de la formule "magique" suivante : V=PEEK(A+OS+(INT(OS/123)*6)). Cette formule semble indiquer que tous les 123 octets il faut faire un saut de 6 octets - ça ressemblerait à un saut par REM présent.

C'est cela. On lit à partir du caractère juste après le mot REM de la première ligne. Et tous les 123 caractères il faut rajouter 6 qui correspondent au saut mémoire jusqu'au début des données de la ligne REM suivante.
C'est expliqué dans le listing commenté que j'ai posté plus tot.

[Xavier_]

Pour info.

; &75 = longueur de la ligne de code
; &4A = ?
; &01 = numéro de ligne
; &01 = numéro de ligne ?
; &8E = code REM

&75-&4A : Adresse le la ligne suivante pour le saut de ligne en ligne.
&01-&00 : Numéro de ligne en hexa 0001=1. (A8:02)=02A8= ligne 680.
[…] début de ligne.
&00 : Fin de ligne basic.
Donc, 4 octets de header, le REM ( 1 octet) et le zéro de fin de ligne = 6 octets.

(Adresse de saut de ligne Nxt_Line à zéro 00:00 en fin de fichier, avec le tableau de variables qui suis cette valeur)

[Xavier_]

Salut,

Le Basic est plutôt capricieux.
En insertion direct, les REMs sont ok, et le patch fonctionnel avec le CALL &"4A01".

Mais, avec la réservation des Rems, le programme est désorganisé et donne une erreur.
Pourtant, les offsets de saut de ligne sont bons.

Code : Tout sélectionner

1 REMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
2 REMXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
3 CALL &"4A01"

ASM.JPG (90.17 Kio) Consulté 3490 fois

Avec une réservation de 116 et 104 caractères.
Donc, l'insertion de la routine n'est pas concluante pour moi.


Hervé Merci pour ton travail et le test effectué.
Mais, effectivement, une méthode de chargement plus "propre" serai plus adaptée.

[Xavier_]

Code : Tout sélectionner

536 E=T(X,Y):F=T(X,Y+1)
537 IF(E=0 OR E=3 OR (E=6 AND G<>0)) AND (F=0 OR F=3 OR F=4 OR (F=6 AND G<>0) OR F=7 OR F=8) THEN

à réduire.
Plus il y a de conditions, plus la machine est ralentie.

Code : Tout sélectionner

536 E=T(X,Y):F=T(X,Y+1):IFNOT(E=0ORE=3OR(E=6ANDG<>0)) GOTO538
537 IF (F=0ORF=3ORF=4OR(F=6ANDG<>0)ORF=7ORF=8)THEN

[Markerror]

Hop, dernière version du source, sans l'insertion de code pour les lignes Basic. J'en ai profité pour remonter l'adresse d'implantation en mémoire (&7E80 en lieu et place de &7C00). Au final, je suis quand même un déçu par le gain de vitesse, qui dans le jeu, est presque imperceptible je trouve. Ce principe de bidouillage est probablement plus intéressant à utiliser avec de l'assembleur si on ne veut pas programmer directement la puce vidéo.

patch_lode runner_v8.zip

(4.43 Kio) Téléchargé 99 fois

Xavier : Une petite amélioration possible sur tes deux lignes : remplacer les <>0 par rien . Je ne sais pas si c'est plus rapide, mais tu gagnes quelques octets.

536 E=T(X,Y):F=T(X,Y+1):IFNOT(E=0ORE=3OR(E=6ANDG)) GOTO538
537 IF (F=0ORF=3ORF=4OR(F=6ANDG)ORF=7ORF=8)THEN