Ça m'intéresse plus que Breath of The Wild sur PC.
Je vais peaufiner ça un peu, voir jusqu'où ça peut aller. Je partirais sur un Shining Force IV plutôt que sur un Fire Emblem par contre.
Ma fille m'a proposé de faire les sprites, elle adore faire du pixel art
La méthodologie de travail, pour ceux que ça intéresse :
► Afficher le texte
Tout est en C. C'est le langage standard du développement Mega Drive amateur moderne, avec SGDK, une bibliothèque libre qui fournit le compilateur et les fonctions d'accès au matériel. Une petite partie de SGDK est en assembleur 68000, mais le code du jeu n'en contient pas.
make rom produit un fichier binaire, out/rom.bin, en quatre étapes :
1. tools/gen_assets.py dessine les tuiles du terrain, les personnages et la police en PNG avec Pillow, une bibliothèque Python d'images.
2. rescomp, l'outil de SGDK, convertit ces PNG au format de la console : des tuiles de 8×8 pixels en 16 couleurs, avec leurs palettes.
3. m68k-elf-gcc, une version de GCC qui produit du code 68000, compile le C. L'éditeur de liens assemble ensuite le tout avec l'en-tête de cartouche que la console lit au démarrage.
4. Tout cela tourne dans l'image Docker officielle de SGDK.
Le code est séparé en deux mondes.
- src/core/ contient les règles du jeu en C pur, sans aucun appel à la console : dégâts, chance, ordre des tours, déplacements, IA. Ce code se compile aussi avec le gcc normal du PC, ce qui permet les 47 tests de make test et la simulation d'équilibrage de make sim. On retrouve le principe de tests unitaires sur une logique métier isolée de l'affichage.
- src/gfx/ et src/scenes/ parlent au processeur graphique (le VDP) par SGDK : plans de tuiles, sprites, palettes, transferts DMA. battle_scene.c est une machine à états (début de tour, sélection, menu, choix de cible, animation, tour de l'IA, fin) appelée 60 fois par seconde.
Les contraintes de la machine ont pesé sur la façon d'écrire le code. Il n'y a pas d'allocation dynamique ni de nombres à virgule, et tout est en entiers et en tableaux de taille fixe. Chaque image dispose d'environ 16 ms. Les écritures en mémoire vidéo se font pendant le retour du balayage vertical (le VBlank), sinon des artefacts apparaissent à l'écran. La recherche de chemin de l'IA bloquait par exemple l'affichage pendant près de 100 images. Il a fallu la réécrire avec un algorithme mieux adapté pour descendre à 24 images au pire.
Pour vérifier le rendu, on a piloté un autre émulateur, Genesis Plus GX, par stable-retro, une bibliothèque Python qui l'embarque. tools/shot.py lit un script ("appuie sur A pendant 5 images, attends 30 images, capture") et enregistre des PNG qui ont ensuite été examinés. Les scripts sont dans tests/shots/ et se relancent avec make shot. C'est ainsi qu'on a repéré le curseur jaune invisible sur la surbrillance jaune, ou le chiffre de dégâts mal placé.
On a d'abord écrit la spécification. On en a tiré un plan en 13 tâches. Chaque tâche a été confiée à un agent qui écrivait les tests puis le code. Un second agent relisait le résultat par rapport à la spécification avant de passer à la tâche suivante. Une relecture globale de la branche a clos l'ensemble. L'historique git garde un commit par étape.
Par contre, on va pas se mentir : un mini-jeu vite fait comme ça c'est très simple et très rapide à faire. Un vrai jeu, complet, avec toutes les contraintes de la machine, c'est pas la même affaire.
La méthodologie de travail, pour ceux que ça intéresse :
► Afficher le texte
Tout est en C. C'est le langage standard du développement Mega Drive amateur moderne, avec SGDK, une bibliothèque libre qui fournit le compilateur et les fonctions d'accès au matériel. Une petite partie de SGDK est en assembleur 68000, mais le code du jeu n'en contient pas.
make rom produit un fichier binaire, out/rom.bin, en quatre étapes :
1. tools/gen_assets.py dessine les tuiles du terrain, les personnages et la police en PNG avec Pillow, une bibliothèque Python d'images.
2. rescomp, l'outil de SGDK, convertit ces PNG au format de la console : des tuiles de 8×8 pixels en 16 couleurs, avec leurs palettes.
3. m68k-elf-gcc, une version de GCC qui produit du code 68000, compile le C. L'éditeur de liens assemble ensuite le tout avec l'en-tête de cartouche que la console lit au démarrage.
4. Tout cela tourne dans l'image Docker officielle de SGDK.
Le code est séparé en deux mondes.
- src/core/ contient les règles du jeu en C pur, sans aucun appel à la console : dégâts, chance, ordre des tours, déplacements, IA. Ce code se compile aussi avec le gcc normal du PC, ce qui permet les 47 tests de make test et la simulation d'équilibrage de make sim. On retrouve le principe de tests unitaires sur une logique métier isolée de l'affichage.
- src/gfx/ et src/scenes/ parlent au processeur graphique (le VDP) par SGDK : plans de tuiles, sprites, palettes, transferts DMA. battle_scene.c est une machine à états (début de tour, sélection, menu, choix de cible, animation, tour de l'IA, fin) appelée 60 fois par seconde.
Les contraintes de la machine ont pesé sur la façon d'écrire le code. Il n'y a pas d'allocation dynamique ni de nombres à virgule, et tout est en entiers et en tableaux de taille fixe. Chaque image dispose d'environ 16 ms. Les écritures en mémoire vidéo se font pendant le retour du balayage vertical (le VBlank), sinon des artefacts apparaissent à l'écran. La recherche de chemin de l'IA bloquait par exemple l'affichage pendant près de 100 images. Il a fallu la réécrire avec un algorithme mieux adapté pour descendre à 24 images au pire.
Pour vérifier le rendu, on a piloté un autre émulateur, Genesis Plus GX, par stable-retro, une bibliothèque Python qui l'embarque. tools/shot.py lit un script ("appuie sur A pendant 5 images, attends 30 images, capture") et enregistre des PNG qui ont ensuite été examinés. Les scripts sont dans tests/shots/ et se relancent avec make shot. C'est ainsi qu'on a repéré le curseur jaune invisible sur la surbrillance jaune, ou le chiffre de dégâts mal placé.
On a d'abord écrit la spécification. On en a tiré un plan en 13 tâches. Chaque tâche a été confiée à un agent qui écrivait les tests puis le code. Un second agent relisait le résultat par rapport à la spécification avant de passer à la tâche suivante. Une relecture globale de la branche a clos l'ensemble. L'historique git garde un commit par étape.
Par contre, on va pas se mentir : un mini-jeu vite fait comme ça c'est très simple et très rapide à faire. Un vrai jeu, complet, avec toutes les contraintes de la machine, c'est pas la même affaire.
Moi mon workflow c'est :
1) Je demande à TryphonAI de porter Shinobi sur Megadrive et il me dit d'aller me faire enculer.
2)
