Catégorie : Non classé

Il n’y a pas eu beaucoup de posts ces dernières semaines à propos du développement de BriXen.

Cela ne veut pas dire que nous avons chômé…

Nous sommes beaucoup pris sur plusieurs projets (RetroANA, FaRK entre autres) mais surtout par le portage de BriXen sur d’autres plateformes. (Amiga, Super Nintendo, SEGA MasterSystem et SDL2 pour l’instant).

Pour simplifier le développement sur ces plateformes et ne voulant pas installer de lourds outils pour le développement cross-plateform sur mes ordinateurs, je suis en train de faire des images Docker sur Docker Hub permettant de compiler facilement mes outils.

Par exemple, sur Sega Master System, il suffit de taper cette commande à la racine du projet

docker run --rm -v $PWD:/src/ -it redbug26/devitsms-docker make

Facile, non ?

Pour l’instant, les Repositories existants sont:

• Sega Master System via devkitsms: https://hub.docker.com/r/redbug26/devkitsms-docker
• Super Nintendo via pvsneslib: https://hub.docker.com/r/redbug26/pvsneslib-docker
• Amstrad CPC via Crazy Piri Toolchain: https://hub.docker.com/r/redbug26/cptc-docker

Les autres plateformes suivront ;p

Mon ordinateur prinicpal est un mac et sur macOS, le choix de l’émulateur est assez facile: Arnold ou Retro Virtual Machine (RVM).

Malgré que Arnold soit un très bon émulateur, niveau developpement RVM reste plus pratique avec toutes ses options de debugging et sa possibilité d’être appelé via la ligne de commande.

Retro Virtual Machine

Comme vu dans l’épisode 3, j’utilise une tâche pour lancer rapidement mon binaire dans Visual Studio avec la commande suivante

/Applications/Retro Virtual Machine 2.app/Contents/MacOS/Retro Virtual Machine 2 -w -b=cpc6128 -i brixen.dsk -c=run"main

J’utilise principalement les 3 vues suivantes:

la première affiche une vue d’ensemble du processeur Z80
la seconde qui affiche la mémoire
et enfin, la 3ème qui affiche une vue du code désassemblé.

SDCC étant assez verbeux et créant des fichiers .map et .lst du code qu’il a compilé, il est assez facile de faire la correspondance entre le code désassemblé de RVM et votre code C.

CrocoDS

En plus de RVM, ayant quand même notre propre émulateur (CrocoDS, vous connaissez ?), j’ai aussi ajouté quelques fonctions dans celui-ci qui m’aide régulièrement:

Redirection de l’imprimante.

CrocoDS redirige le port imprimante vers un fichier log. J’ai donc deux fonctions qui me permettent d’envoyer du texte à partir du CPC vers la console

void cpc_out(u8 b)
{
    (void)b;
 __asm
    ld hl, #2 + 0
    add hl, sp
    ld c, (hl)
    ld b, #0xEF
    out(c), c
    ld a, #0x80
    xor c
    ld c, a
    out(c), c
    __endasm;
}

void cpc_Debug(const char *str)
{
    char *a = (char *)str;
    while (*a != 0) {
         cpc_out(*a);
         a++;
     }
 }

Capture d’écran

Un opcode spécial (ED FD) me permet de demander une capture d’écran à partir de l’Amstrad. Je l’utilise pour sortir la liste des 32 niveaux de BriXen en fichier pdf. Plus facile à consulter pour l’équipe.

__asm
.db #0xED
.db #0xFD
__endasm;

Comptage de FRAME

Autre opcode (ED FE) qui me logge le compteur de frame et le compteur de cycle:

F4 - T123/80000
F4 - T3153/80000

Cela me permet facilement de voir le temps que prend une routine et de l’optimiser si nécessaire.

Conclusion

Comme d’habitude, ces outils correspondent à mes besoins. Beaucoup ne jure que par WinAPE pour développer sous Windows (Certains jeux ont même été entièrement réalisé à partir de son assembleur intégré).

Et puis, n’oubliez pas: testez aussi sur vos vraies machines ! (et restez couvert)

A suivre pour un prochain épisode

Quand j’étais petit, j’adorais le mode démo dans les jeux. Cela permettait d’avoir une musique et une animation qui tourne en fond. 

Pour BriXen, il en fallait donc un.

Niveau développement, c’est assez simple. En gros, on joue à un niveau, chaque modification de touche est sauvée avec un compteur de frame et dans le mode démo, le programme utilise la séquence pour simuler le joueur qui joue.

J’ai donc deux fonctions à faire:

• une qui enregistre (que je pourrais supprimer dans la version finale)
• une qui joue.

Pour cela, j’ai crée une scène SC_DEMO qui est appelé après 30 secondes (soit 1500 frames).

Un chaine de replay se ressemble à ça (pour le level 1)

const u8 seq_level0[] = {22, 2, 18, 0, 14, 2, 10, 0, 17, 2, 9, 0, 14, 2, 9, 0, 10, 2, 11, 0, 14, 2, 17, 0, 21, 2, 8, 0, 78, 2, 11, 0, 36, 2, 8, 0, 51, 1, 84, 0, 15, 1, 5, 0, 16, 2, 16, 0, 21, 2, 19, 0, 23, 1, 7, 0, 11, 2, 24, 0, 10, 2, 17, 0, 19, 2, 21, 0, 37, 2};

Cela se traduit par:

• 1er octet: nombre de frame avant d’executer la commande
• 2éme octet: commande à executer (1: gauche, 2: droite, 0: on relache)

Arrivé à la fin de la chaine, j’aurai pu crée une commande 3… Mais vu que je ne fais que de la lecture et que cela n’influence qu’une simulation d’appui de touche, je laisse aller le pointeur au-delà de la chaine. De toute façon, il ne lira que quelques octets avant de compléter le niveau…

Un des choses qui nous fait le plus vite défaut sur l’Amstrad, c’est le peu de mémoire dont nous disposons.

Actuellement, je préfère n’utiliser que les 64k de disponible afin de rendre nos jeux compatibles avec le plus de machine possible (c’est même une des conditions de la CPC Retrodev)

De nombreuses méthodes de compression existent pour notre Z80. La plus connues des demomakers est Shrinkler de par son haut taux de compression. Malheureusement, son temps de décompression est plus de 25 fois la vitesse de la commande assembleur LDIR (copie d’octets).

Pour un jeu, ce n’est pas acceptable. Il m’a donc fallu trouver un compromis vitesse/taux de compression.

Mon choix s’est porté sur LZSA de Emmanuel Marty.

Il nous donne un taux de compression de 2 pour une vitesse de LDIR x2. C’est plus qu’acceptable. Le meilleur, c’est que la fonction de décompression ne prend que 220 octets ! Il n’y a donc presque pas de raisons de ne pas l’utiliser.

La fonction est disponible dans le template Crazy Piri.

A suivre pour un prochain épisode…