Après avoir bidouillé avec Sultan’s Maze, je me suis dit que j’allais tenter le coup avec Roland on the Ropes.
J’ai demandé à Claude s’il pouvait modifier le défilement pour remplacer les grands sauts horizontaux par quelque chose d’un peu plus fluide.
Et il a réussi. Le défilement horizontal se déplace désormais par blocs de caractères du mode 1 au lieu des blocs du mode 0, ce qui est bien plus agréable.
Cela a entraîné un scintillement désagréable sur Roland lui-même, ce qui a demandé quelques allers-retours pour être corrigé.
L’étape suivante consistait à essayer d’accélérer le jeu.
Cela a nécessité plusieurs itérations et idées, mais comme vous le verrez, c’est désormais sacrément plus rapide.
Enfin, le scintillement sur les 4 côtés de l’écran lors du défilement.
Cela se produit à cause de l’utilisation du défilement matériel, et je voulais voir si Claude pouvait faire quelque chose pour le réduire au minimum.
Ce n’est pas totalement parti (même après plusieurs améliorations), mais c’est bien meilleur.
Il y a eu quelques erreurs en cours de route, mais avec suffisamment de tests et d’itérations, on est arrivé à un très bon résultat !
Veuillez noter que je n’ai pas testé tous les aspects du gameplay, mais tout semble bien fonctionner.
[ÉDIT] Hmmm, c’est étrange. Dans le lecteur RVM intégré au navigateur, le jeu tourne vraiment très lentement !
[ÉDIT 2] Il semble que ce soit lié à la méthode de contrôle sélectionnée. Je retire le dsk pour le moment.
J’essayais de trouver comment ajouter à la publication tout le texte que j’avais écrit, et j’ai pu le coller dans « Project Notes & Prompts ».
Je trouvais ça bizarre de ne pas pouvoir publier quelque chose sur le jeu dans le sujet.
Est-ce fait exprès que les publications sur ce qui est vibe-codé soient limitées en termes de contenu ?
Aussi, je me demande pourquoi le fil sur Sultan’s Maze a été fermé ? (J’aimerais savoir si j’ai fait une erreur, et à quoi je devrais faire attention à l’avenir).
Je me demande s’il a utilisé mes infos pour éviter le scintillement sur les côtés…
L’autre jour, j’ai demandé à ChatGPT comment faire un truc avec le défilement (curieux de voir s’il pouvait sortir quelque chose de nouveau à partir des infos existantes, mais non). Je lui ai demandé où il avait trouvé ses infos, et il me citait mes propres propos du vieux forum cpcwiki. Bon, en même temps, je l’avais publié là-bas pour que les gens l’utilisent…
Ok, c’est pas le scintillement du R3 auquel je pensais.
C’est le défilement matériel habituel, sans utiliser le R3, et ce n’est pas du double buffering, ce qui est intéressant. Ok, on dirait qu’il a déroulé l’affichage des tuiles avec des LDI.
Concernant l’utilisation des instructions LDI, l’un de mes premiers prompts était le suivant :
je voudrais regarder comment patcher le code du jeu pour améliorer le scrolling. et si c’est possible, qu’un nouveau .bin soit généré pour pouvoir être réintégré sur le dsk. pour l’instant, le scrolling est très saccadé, se déplaçant de ce qui ressemble à 1 caractère en mode 0 à la fois. j’aimerais qu’il se déplace par saut de la taille d’un caractère en mode 1
et Claude a répondu :
C’est faisable, et les fichiers patchés ROLANDC.BIN et ROLANDD.BIN sont prêts à être déposés sur le dsk sous les mêmes noms. Je ne les ai faits tourner que dans mon propre environnement de test (un cœur Z80 avec des appels de firmware simulés), pas sur un CPC ni sur un vrai ému, il faut donc les tester sur le vôtre.
Comment le jeu gère le scrolling
Le jeu est en Mode 0, construit à partir de tuiles de 4×8 octets (un caractère Mode 0), avec une fenêtre de 20×23 tuiles plus un panneau de statut de 2 lignes.
Le scrolling utilise le scrolling matériel du firmware (SCR SET OFFSET) : ±4 octets horizontalement, ±80 verticalement, puis une nouvelle colonne ou ligne de tuiles est dessinée.
Les pas verticaux sont de 8 lignes de balayage, ce qui correspond déjà à la hauteur d’un caractère Mode 1, je n’ai donc pas touché à l’axe vertical.
Tout le rendu passe par un seul blitter de tuiles à &2AF8, ce qui a permis de garder un patch léger.
Ce que fait le patch
Chaque pas horizontal se fait désormais en deux étapes de 2 octets. La logique du jeu reste intacte et déplace toujours une tuile par boucle.
Premier demi-pas (crochet à &A1DA, juste après la reconstruction du buffer de tuiles) : décale l’offset de 2, dessine la moitié de la colonne arrivante, et redessine le joueur ainsi que le panneau de statut.
Second demi-pas (crochet à &34EF, le point de scrolling d’origine) : décale des 2 autres octets, dessine la colonne complète, et restaure les tuiles sous le joueur.
Blitter plus rapide : J’ai également remplacé &2AF8 par une version LDI déroulée pour compenser le coût du rendu supplémentaire. Cela affecte l’ensemble du jeu, pas seulement le scrolling.
Où il se trouve : 397 octets à &A900 dans le remplissage de zéros à la fin de ROLANDC, et 118 octets à &2A79 dans le remplissage sous l’ancien blitter. La taille des fichiers et les en-têtes restent inchangés.
Et plus tard, en essayant de réduire le scintillement causé par le défilement matériel, Claude a déclaré ceci :
Ce qui a changé
Glissement du panneau à travers le bouclage (wrap) : la longueur des séquences est calculée une fois par déplacement (jusqu’à trois séquences droites par ligne de balayage, divisées là où la source ou la destination atteint la fin de ses 2 K), puis chaque ligne est copiée avec LDIR/LDDR. S’il n’y a pas de bouclage qui gêne, il utilise toujours la copie déroulée.
Rétractation du premier demi-pas supprimée : le redessin du panneau à demi-état a disparu, puisque le glissement n’échoue plus à cause du bouclage.
Pas de corde (rope steps) : le glissement fonctionne désormais aussi dans la zone sur les pas verticaux.
C’est impressionnant ce qu’il peut faire, et aussi rapidement.
Je l’utilise au travail et, l’autre jour, en regardant le code qui avait été généré, j’ai remarqué qu’il avait utilisé une méthode de recherche rapide que je ne connaissais pas. J’ai donc fait des recherches dessus et j’ai appris quelque chose de nouveau.
Ce qui est bien avec la méthode utilisée dans cette version, c’est que le défilement horizontal peut être plus fluide que le défilement vertical, car il n’y a aucun défilement en diagonale dans le jeu.
Vraiment génial ! Je n’ai jamais aimé le jeu à cause du défilement. Maintenant, c’est « assez bon » pour que je puisse en profiter. Pas besoin d’un meilleur défilement.
Absolument génial et une excellente façon d’utiliser l’IA.
Eh bien, j’étais plutôt hésitant quant à l’utilisation de l’IA, mais je dois admettre qu’elle a résolu pas mal de « problèmes » ici dans Roland On The Ropes.
Après y avoir joué, je dirais que la vitesse de jeu vraiment très rapide — bien qu’impressionnante — gâche un peu le gameplay général. En jouant au jeu depuis des années, encore assez régulièrement, ça rend le timing des sauts par-dessus les rats beaucoup trop difficile, pour ne citer qu’un exemple évident. Dans les niveaux ultérieurs avec des ennemis multiples comme les chauves-souris, etc., ça va juste être une véritable horreur et une énorme source de frustration.
Y a-t-il un moyen de conserver ces améliorations tout en modérant la vitesse ?
C’est une belle amélioration, et une excellente utilisation de l’IA pour effectuer de petites modifications ciblant l’amélioration de bases de code existantes, sans avoir à passer tout son temps à faire des analyses et des correctifs manuels. Je trouve que c’est bien différent de l’utilisation de l’IA générative pour créer des jeux à partir de zéro avec très peu d’intervention des développeurs ou des graphistes.
Ce qui serait sympa, ce serait d’avoir un affichage par transparence (transparent blitting) du sprite du fantôme lorsqu’il traverse les murs, plutôt que ce grand déplacement saccadé.
Je ne sais pas quoi dire. Tu as complètement transformé l’expérience de jeu. Je l’avais dans mon pack de bienvenue quand j’ai eu le CPC pour la première fois. Je l’aimais bien, mais le défilement était un peu dérangeant, alors que maintenant… C’est tellement fluide et réussi — bravo !
Penses-tu que l’affichage des sprites pourrait être amélioré en utilisant l’IA ? On peut voir qu’il n’y a pas de transparence, car tous les sprites ont un fond noir. Ce serait génial si cela pouvait être amélioré.
Et sinon, non, il n’y a pas de limite à ce que tu peux publier dans cette catégorie. La seule condition préalable, c’est le formulaire (et je ne sais toujours pas comment tu as réussi à passer à côté )
Je l’avais initialement créé dans le mauvais sous-forum, et après que tu m’as signalé que je devais le créer dans un sous-forum approprié lié à l’IA, je l’ai déplacé dans « Vibe-coded games ».
Le fil a ensuite été fermé, et ce n’est que plus tard que j’ai compris que tu voulais peut-être dire que je devais le recréer dans le forum approprié.
Mon erreur a donc été de simplement le déplacer dans Vibe-coded au lieu de le y recréer.
)
