[VG5000] Lode Runner
Modérateurs : Papy.G, fneck, Carl
[VG5000] Lode Runner
Bonjour, je suis le petit nouveau,
Tentative de re-écriture du célèbre Lode Runner (Douglas Smith 1983) sur VG5000.
Disponible sur le site de Daniel: http://dcvg5k.free.fr/programmes/_html/index.html
Le chantier: Vitesse d'execution à (nettement) améliorer. Optimisation du code, Routine assembleur pour la boucle principale?, affichage... et toutes les bonnes idées bienvenues. A ce propos, j'ai vu que Rendomizer sait faire faire de vrais beaux sprites au VG5000!
Feuille Excel dispo pour créer ses propres tableaux.
Guillaume
Tentative de re-écriture du célèbre Lode Runner (Douglas Smith 1983) sur VG5000.
Disponible sur le site de Daniel: http://dcvg5k.free.fr/programmes/_html/index.html
Le chantier: Vitesse d'execution à (nettement) améliorer. Optimisation du code, Routine assembleur pour la boucle principale?, affichage... et toutes les bonnes idées bienvenues. A ce propos, j'ai vu que Rendomizer sait faire faire de vrais beaux sprites au VG5000!
Feuille Excel dispo pour créer ses propres tableaux.
Guillaume
Dernière modification par Guillaume le 26 avr. 2020 23:49, modifié 1 fois.
- Mokona
- Messages : 1041
- Inscription : 17 déc. 2016 22:01
- Localisation : Nord Est des Yvelines
- Contact :
Re: [VG5000] Lode Runner
Hello et merci.
Le coup de double les lignes de commentaires pour les faire disparaître lors de l'injection dans l'émulateur, je n'y avais jamais pensé. C'est une bonne idée.
Le coup de double les lignes de commentaires pour les faire disparaître lors de l'injection dans l'émulateur, je n'y avais jamais pensé. C'est une bonne idée.
Re: [VG5000] Lode Runner
Bonjour,
Je viens de tester le jeu, c'est pas mal du tout et la bête a du potentiel je pense . C'est vrai que le jeu original se prête bien à une adaptation sur VG5000 (j'avoue ne même pas y avoir pensé... ) avec son aire de jeu assez grande et ses petits graphismes.
Dans les choses à améliorer, je vois déjà une chose qui saute aux yeux, la durée d'affichage des tableaux. Sans programmer l'EF9345, ça peut s'améliorer facilement avec une petite routine Z80 qui va poker dans le buffer le tableau. C'est un excellent exercice d'apprentissage à la programmation assembleur .
Après, je pense qu'il faudra gagner en vitesse d'animation car c'est quand même lent en l'état. Pour le coup, soit il faut programmer la logique du jeu et l'affichage des sprites en assembleur en attaquant directement l'EF9345 (ce qui oblige finalement à refaire le jeu), soit essayer d'utiliser la bidouille dont je me sers dans Sound Sheep : faire en sorte que le système n'envoie que les lignes ayant subies des modifications à l'EF9345. Ca risque de compliquer les choses, mais le Basic resterait la partie principale du code et avec le joueur et trois adversaires, ça ne ferait en l'état que huit lignes à envoyer en lieu et place de 25... (les anciennes et actuelles positions des "sprites").
Après, on pourrait améliorer la fluidité des animations en décomposant les étapes de déplacement du joueur et des ennemis. Ca complexifiera encore le code mais donnera un aspect plus "pro" au jeu.
En tout cas, bravo pour avoir repris ce projet !
Je viens de tester le jeu, c'est pas mal du tout et la bête a du potentiel je pense . C'est vrai que le jeu original se prête bien à une adaptation sur VG5000 (j'avoue ne même pas y avoir pensé... ) avec son aire de jeu assez grande et ses petits graphismes.
Dans les choses à améliorer, je vois déjà une chose qui saute aux yeux, la durée d'affichage des tableaux. Sans programmer l'EF9345, ça peut s'améliorer facilement avec une petite routine Z80 qui va poker dans le buffer le tableau. C'est un excellent exercice d'apprentissage à la programmation assembleur .
Après, je pense qu'il faudra gagner en vitesse d'animation car c'est quand même lent en l'état. Pour le coup, soit il faut programmer la logique du jeu et l'affichage des sprites en assembleur en attaquant directement l'EF9345 (ce qui oblige finalement à refaire le jeu), soit essayer d'utiliser la bidouille dont je me sers dans Sound Sheep : faire en sorte que le système n'envoie que les lignes ayant subies des modifications à l'EF9345. Ca risque de compliquer les choses, mais le Basic resterait la partie principale du code et avec le joueur et trois adversaires, ça ne ferait en l'état que huit lignes à envoyer en lieu et place de 25... (les anciennes et actuelles positions des "sprites").
Après, on pourrait améliorer la fluidité des animations en décomposant les étapes de déplacement du joueur et des ennemis. Ca complexifiera encore le code mais donnera un aspect plus "pro" au jeu.
En tout cas, bravo pour avoir repris ce projet !
- Carl
- Modérateur
- Messages : 13290
- Inscription : 08 avr. 2007 13:21
- Localisation : http://www.doledujura.fr
- Contact :
Re: [VG5000] Lode Runner
Bravo Guillaume pour cette version de Lone Runner, je vais la tester de ce pas...
Carl
Carl
Re: [VG5000] Lode Runner
Et un nouveau jeu de plus pour le VG5000.
Décidément c'est une bonne année.
Décidément c'est une bonne année.
Re: [VG5000] Lode Runner
[EDIT: Message effacé! … j'efface celui-ci pour éviter de spoiler ton projet?]J'étais actuellement en train de désassembler PANICO, un clone pour ZX81. La galère.
"Panique" de ERE Informatique…
Utilise VB81 XuR et son désassembleur analytique.
Re: [VG5000] Lode Runner
Merci pour ces pistes et tes encouragements. Il y a déjà dans le code des choses à faire pour accélerer à peu de frais. Mais je serais intérresser par faire une routine. Je connais le principe de l'assembleur, j'ai fait de l'Intel mais il y a très longtemps. Ce que je ne sais pas en revanche, c'est comment on insère du code machine?
Re: [VG5000] Lode Runner
Mélanger code machine et Basic est assez facile en fait.
La première chose à faire est de réserver de l'espace avec une commande CLEAR pour être sûr que ta routine ne va pas se retrouver écrasée par le système (pile ou variables).
Ensuite, il y a deux méthodes : stocker les octets correspondant à la routine dans le listing dans des lignes DATA et les POKER en mémoire.
C'est par exemple ce que j'ai fait pour le jeu "Machaon" (c'est toujours instructif de zieuter le travail des autres ).
Cette technique n'est utile que pour des petits bouts de code, car ça prend du temps.
Autre solution quand la taille du code devient conséquence, charger en mémoire un fichier binaire (voir la dernière version de Memory par exemple).
Pour créer le fichier binaire avec DcVk5k, rien de plus facile ! Il existe une option dans le mode "Mise au point" qui permet de charger un fichier binaire "PC" dans la mémoire du VG5000. Il suffit ensuite de la sauvegarder avec une commande CSAVEM sur cassette et roulez jeunesse .
La première chose à faire est de réserver de l'espace avec une commande CLEAR pour être sûr que ta routine ne va pas se retrouver écrasée par le système (pile ou variables).
Ensuite, il y a deux méthodes : stocker les octets correspondant à la routine dans le listing dans des lignes DATA et les POKER en mémoire.
C'est par exemple ce que j'ai fait pour le jeu "Machaon" (c'est toujours instructif de zieuter le travail des autres ).
Cette technique n'est utile que pour des petits bouts de code, car ça prend du temps.
Autre solution quand la taille du code devient conséquence, charger en mémoire un fichier binaire (voir la dernière version de Memory par exemple).
Pour créer le fichier binaire avec DcVk5k, rien de plus facile ! Il existe une option dans le mode "Mise au point" qui permet de charger un fichier binaire "PC" dans la mémoire du VG5000. Il suffit ensuite de la sauvegarder avec une commande CSAVEM sur cassette et roulez jeunesse .
- Carl
- Modérateur
- Messages : 13290
- Inscription : 08 avr. 2007 13:21
- Localisation : http://www.doledujura.fr
- Contact :
Re: [VG5000] Lode Runner
J'ai enfin pris de temps de lancer ce nouveau jeu...avec un peu de fluidité, ce serait parfait, cela reste cependant jouable...
Carl
Carl
Re: [VG5000] Lode Runner
Merci Carl!
Je pense que c'est possible d'améliorer la vitesse, quelques idées me sont venues de vos retours. La tache n'est pas simple car, idéalement, il faudrait augmenter cela d'un facteur 4, ce n'est pas juste 20% qui changeront l'expérience du joueur. Car il faut le dire, en vitesse normale, c'est pas terrifiant.
Ma fille de 7 ans y a joué, et cela lui a plu! Etonnant quand on voit la qualité du moindre jeu aujourd'hui.
Il faudrait que je profite du confinement pour travailler dessus, car après, dans nos vies trépidantes, j'aurais peut-être d'autres priorités (BBQ, tongues, rosé en atmosphère extérieure!!!
Je pense que c'est possible d'améliorer la vitesse, quelques idées me sont venues de vos retours. La tache n'est pas simple car, idéalement, il faudrait augmenter cela d'un facteur 4, ce n'est pas juste 20% qui changeront l'expérience du joueur. Car il faut le dire, en vitesse normale, c'est pas terrifiant.
Ma fille de 7 ans y a joué, et cela lui a plu! Etonnant quand on voit la qualité du moindre jeu aujourd'hui.
Il faudrait que je profite du confinement pour travailler dessus, car après, dans nos vies trépidantes, j'aurais peut-être d'autres priorités (BBQ, tongues, rosé en atmosphère extérieure!!!
Re: [VG5000] Lode Runner
Excellent. Plus qu'à traduire en assembleur et ce sera un hit sur VG5000.
Tout ce que j'aime: graphimes, musique et intêret du jeu.
Un détail: VG5000 est une machine française. Il serait bien de mettre le jeu en français
Un détail de programmation. A quoi sert les premières lignes rem (lignes 10 à 20)
Tout ce que j'aime: graphimes, musique et intêret du jeu.
Un détail: VG5000 est une machine française. Il serait bien de mettre le jeu en français
Un détail de programmation. A quoi sert les premières lignes rem (lignes 10 à 20)
Re: [VG5000] Lode Runner
Les lignes REM 10 à 20 sont le stockage des tableaux du jeu.
Les tableaux sont stockés sous forme de caractères et correspondent à la description des éléments de chaques tableau et à leur disposition. Chaque tableau forme une chaine de longueur variable (120 charactères en moyenne, c'est selon la complexité de chaque tableau). Les chaines sont mise à la suite les unes des autres et la séquence se termine par un point d'exclamation. La chaine est découpées en section de longueur fixe dans chaque ligne REM.
La génération de ses chaines de caractères est faite selon un petit algorithme qui a pour but de réduire la place en mémoire. C'est un compromis entre la réduction de la taille du stockage des tableaux et la taille du code pour les reconstituer. En gros, on lis un tableau du jeu ligne à ligne du haut vers le bas, et on regarde chaque apparition d'un élément (du vide, une echelle, une brique, ...) et sur quelle longueur. Tu peux générer les tableaux (y compris tes propres créations!) grace à la feuille Excel. On dispose les éléments graphiques du tableau dans la zone consacrée à l'aide des valeur numérique correspondant à chaque élément. La chaine correspondante est calculée dans la zone jaune dessous. Si tu veux faire un essai, créé un tableau, copie la chaine dans la ligne 10 et termine avec un point d'exclamation.
Je pense que l'on pourra stocker quelques dizaines de tableaux dans le code. Ensuite, quand on a terminé de jouer les tableaux, grace à un CLOADA on pourra charger la série de tableaux suivant depuis la cassette qui viendra juste remplacer ses lignes REM en début de programme. Ainsi le nombre de tableaux peut être illimité, avec un chargement casette de temps à autre.
Si tu veux plus de détails sur le format des tableaux, n'hésite pas.
Les tableaux sont stockés sous forme de caractères et correspondent à la description des éléments de chaques tableau et à leur disposition. Chaque tableau forme une chaine de longueur variable (120 charactères en moyenne, c'est selon la complexité de chaque tableau). Les chaines sont mise à la suite les unes des autres et la séquence se termine par un point d'exclamation. La chaine est découpées en section de longueur fixe dans chaque ligne REM.
La génération de ses chaines de caractères est faite selon un petit algorithme qui a pour but de réduire la place en mémoire. C'est un compromis entre la réduction de la taille du stockage des tableaux et la taille du code pour les reconstituer. En gros, on lis un tableau du jeu ligne à ligne du haut vers le bas, et on regarde chaque apparition d'un élément (du vide, une echelle, une brique, ...) et sur quelle longueur. Tu peux générer les tableaux (y compris tes propres créations!) grace à la feuille Excel. On dispose les éléments graphiques du tableau dans la zone consacrée à l'aide des valeur numérique correspondant à chaque élément. La chaine correspondante est calculée dans la zone jaune dessous. Si tu veux faire un essai, créé un tableau, copie la chaine dans la ligne 10 et termine avec un point d'exclamation.
Je pense que l'on pourra stocker quelques dizaines de tableaux dans le code. Ensuite, quand on a terminé de jouer les tableaux, grace à un CLOADA on pourra charger la série de tableaux suivant depuis la cassette qui viendra juste remplacer ses lignes REM en début de programme. Ainsi le nombre de tableaux peut être illimité, avec un chargement casette de temps à autre.
Si tu veux plus de détails sur le format des tableaux, n'hésite pas.
Re: [VG5000] Lode Runner
Oui ce serait bien mieux en effet.
Là non, je préfère l'anglais parce que c'est impossible de mettre le même nombre ou moins de mots français qu'en anglais (on peut lui reconnaître cette qualité au moins). Quand on est limité par la résolution, ça joue énormément. Et puis si on veut que le jeu puisse se jouer en dehors de la France, l'anglais le permet au moins. C'est mon opinion bien sûr.
Re: [VG5000] Lode Runner
Salut,
Oui, pas mal… même très jouable, mais les monstres ne sont pas très vaillants au début du jeu.
La seule chose perfectible est l'affichage du tableau, qui lui peut se faire en assembleur ou en modifiant la routine basic.
Sinon le gameplay est suffisant.
Sur certaines machines, une astuce pour accélérer le jeu consistait à mettre les boucles et l'affichage en fin de programme.
Le regroupement des lignes, en lignes uniques ce qui accélère aussi le fonctionnement.
Oui, pas mal… même très jouable, mais les monstres ne sont pas très vaillants au début du jeu.
La seule chose perfectible est l'affichage du tableau, qui lui peut se faire en assembleur ou en modifiant la routine basic.
Sinon le gameplay est suffisant.
Sur certaines machines, une astuce pour accélérer le jeu consistait à mettre les boucles et l'affichage en fin de programme.
Le regroupement des lignes, en lignes uniques ce qui accélère aussi le fonctionnement.