La Place des Développeurs MSXgl MSX Game Library
Reprise du message précédent
On s'inter-impressionne alors.
Par contre, je galère un peu sur la nouvelle version du player WYZ.
J'aimerai bien finir ça proprement avant de faire une nouvelle release officiel du moteur.
On est toujours ignorant avant de savoir.
Ca y est !!! 
Ca faisait plusieurs jours que j'essayais de comprendre pourquoi ma nouvelle version du player WYZ faisait parfois planter mes programmes.
Le fautif, c'est l'utilisation du registre IX dans une fonction !
J'avais jamais fait suffisamment attention, mais il est bien précisé dans la documentation de SDCC (le compilateur C), que tous les registres du Z80 sont utilisables dans les fonctions... sauf IX, qui est réservé pour le frame pointer.
Ca n'empêche pas d'utiliser IX dans une fonction, mais ça veut dire qu'il faut sauvegarder ce registre avant de l'utiliser (le push sur la pile) et le restaurer à la fin (pop).
Il y a aussi une option de compilation pour désactiver l'utilisation du frame pointer (--fomit-frame-pointer) mais intuitivement, j'aurai tendance à penser que ça impacterait négativement les performances.
En tout cas, je vais enfin pouvoir passer à autre chose.
Ca faisait plusieurs jours que j'essayais de comprendre pourquoi ma nouvelle version du player WYZ faisait parfois planter mes programmes.
Le fautif, c'est l'utilisation du registre IX dans une fonction !
J'avais jamais fait suffisamment attention, mais il est bien précisé dans la documentation de SDCC (le compilateur C), que tous les registres du Z80 sont utilisables dans les fonctions... sauf IX, qui est réservé pour le frame pointer.
Ca n'empêche pas d'utiliser IX dans une fonction, mais ça veut dire qu'il faut sauvegarder ce registre avant de l'utiliser (le push sur la pile) et le restaurer à la fin (pop).
Il y a aussi une option de compilation pour désactiver l'utilisation du frame pointer (--fomit-frame-pointer) mais intuitivement, j'aurai tendance à penser que ça impacterait négativement les performances.
En tout cas, je vais enfin pouvoir passer à autre chose.
On est toujours ignorant avant de savoir.
Hello,
Voici une nouvelle version officielle de MSXgl : version alpha 0.3.2.
Change log (depuis la v0.3.0) :
○ Mise-à-jour de la version de SDCC incluse (passage en 4.2.0)
○ Ajout de modules pour gérer de nouveaux matériels audio: MSX-Music, MSX-Audio et SCC.
○ Ajout de modules pour gérer de nouveaux formats audio (en plus de PT3 et ayFX):
• VGM (pour tous les hardware supportés),
• lVGM (format VMG-léger fait maison pour PSG),
• WYZ (version 47c de mvac7 + version 47d issue d'un code asm récent),
• PCM-Encoder (de ARTRAG).
○ Ajout d'un module (game_pawn) pour gérer les animations, déplacement et collision (basé sur les tile) d'un personnage. Le sample s_game a été mis à jour comme exemple d'utilisation de ce module.
○ Ajout d'une option de Build pour installer automatiquement le driver BDOS pour un programme en ROM (via le hook STKE).
○ Amélioration du support de l'émulateur Emulicious (break-point en ligne, génération des symboles et options de lancement).
○ Mise-à-jour de la documentation du code : /engine/doc/html/ (ça reste très basique)
Fonctions prévues pour les futures versions :
○ Ajouter du support pour de nouveaux formats audio : Arkos Tracker (WIP), TriloTracker.
○ Ajouter un module pour gérer le scrolling d'écran.
○ Ajouter d'un module pour gérer les fonctions BDOS (pour gérer l'accès au disque pour les programmes DOS, BIN et ROM).
○ Ajouter du support complet de MSX-DOS 1 et 2 (notamment les paramètres de ligne de command).
○ Réécrire le BuildTool en Python et le rendre multi-plateforme (Linux & MacOS). Désolé, c'est toujours pour Windows seulement pour le moment.
○ Optimiser, optimiser and optimiser (en taille et en nombre de cycless)!
Highlight de projet MSXgl :
○ msx3d par jbikker (https://github.com/jbikker/msx3d)
○ Wizzl par GFX (WIP)
Si vous avez des questions ou besoin d'aide concernant MSXgl, je suis disponible ici ou sur Discord.
PS : C'est une traduction de mon message sur MRC, mais en tant que francophone, ça me semble important de relayer l'info aussi dans la langue de Molière.
Voici une nouvelle version officielle de MSXgl : version alpha 0.3.2.
Change log (depuis la v0.3.0) :
○ Mise-à-jour de la version de SDCC incluse (passage en 4.2.0)
○ Ajout de modules pour gérer de nouveaux matériels audio: MSX-Music, MSX-Audio et SCC.
○ Ajout de modules pour gérer de nouveaux formats audio (en plus de PT3 et ayFX):
• VGM (pour tous les hardware supportés),
• lVGM (format VMG-léger fait maison pour PSG),
• WYZ (version 47c de mvac7 + version 47d issue d'un code asm récent),
• PCM-Encoder (de ARTRAG).
○ Ajout d'un module (game_pawn) pour gérer les animations, déplacement et collision (basé sur les tile) d'un personnage. Le sample s_game a été mis à jour comme exemple d'utilisation de ce module.
○ Ajout d'une option de Build pour installer automatiquement le driver BDOS pour un programme en ROM (via le hook STKE).
○ Amélioration du support de l'émulateur Emulicious (break-point en ligne, génération des symboles et options de lancement).
○ Mise-à-jour de la documentation du code : /engine/doc/html/ (ça reste très basique)
Fonctions prévues pour les futures versions :
○ Ajouter du support pour de nouveaux formats audio : Arkos Tracker (WIP), TriloTracker.
○ Ajouter un module pour gérer le scrolling d'écran.
○ Ajouter d'un module pour gérer les fonctions BDOS (pour gérer l'accès au disque pour les programmes DOS, BIN et ROM).
○ Ajouter du support complet de MSX-DOS 1 et 2 (notamment les paramètres de ligne de command).
○ Réécrire le BuildTool en Python et le rendre multi-plateforme (Linux & MacOS). Désolé, c'est toujours pour Windows seulement pour le moment.
○ Optimiser, optimiser and optimiser (en taille et en nombre de cycless)!
Highlight de projet MSXgl :
○ msx3d par jbikker (https://github.com/jbikker/msx3d)
○ Wizzl par GFX (WIP)
Si vous avez des questions ou besoin d'aide concernant MSXgl, je suis disponible ici ou sur Discord.
PS : C'est une traduction de mon message sur MRC, mais en tant que francophone, ça me semble important de relayer l'info aussi dans la langue de Molière.
On est toujours ignorant avant de savoir.
@aoineko
J'ai intégré dans ma librairie, le PCM ENCODER d'Artrag, comme tu l'as fait.
Etrangement, pour que le PCM soit correctement joué, je suis obligé d'ajouter un DI / EI dans la routine qui joue le sample. Alors que de ton coté tu ne semble pas l'avoir mis en place.
SI je ne fait pas un DI / EI , le sample est joué de façon hachée, on entend bien que ca ne va pas.
Je me demande bien pourquoi cette différence, alors qu'on utilise tous les 2 exacmenet le même code fourni par Arturo.
Edité par
ericb59
Le 18/03/2022 à 13h14
J'ai intégré dans ma librairie, le PCM ENCODER d'Artrag, comme tu l'as fait.
Etrangement, pour que le PCM soit correctement joué, je suis obligé d'ajouter un DI / EI dans la routine qui joue le sample. Alors que de ton coté tu ne semble pas l'avoir mis en place.
SI je ne fait pas un DI / EI , le sample est joué de façon hachée, on entend bien que ca ne va pas.
Je me demande bien pourquoi cette différence, alors qu'on utilise tous les 2 exacmenet le même code fourni par Arturo.
Edité par
ericb59
Le 18/03/2022 à 13h14
J'imagine que la question pour moi et non sebbeug.
Si tu laisses les interruptions activées, cela va forcement perturber le playback du son puisse que ça va changer le timing du code assembleur toutes les 1/50 ou 1/60 s.
Contrairement aux players de musique (PT3, WYZ, etc.) le player PCM est synchrone (il est synchronisé sur les instructions et non pas sur le VBlank).
Ceci dit, cela devrait être peu perceptible normalement (ce qui doit arriver avec ma version).
Si le son est vraiment déformé, c'est probablement un problème de data.
Il faut bien ajuster les paramètres de génération des données au player que tu veux utiliser (8, 11, 22 et 44 KHz).
Si tu laisses les interruptions activées, cela va forcement perturber le playback du son puisse que ça va changer le timing du code assembleur toutes les 1/50 ou 1/60 s.
Contrairement aux players de musique (PT3, WYZ, etc.) le player PCM est synchrone (il est synchronisé sur les instructions et non pas sur le VBlank).
Ceci dit, cela devrait être peu perceptible normalement (ce qui doit arriver avec ma version).
Si le son est vraiment déformé, c'est probablement un problème de data.
Il faut bien ajuster les paramètres de génération des données au player que tu veux utiliser (8, 11, 22 et 44 KHz).
On est toujours ignorant avant de savoir.
aoineko :
J'imagine que la question pour moi et non sebbeug.
Arf ! oui ! Non mais ...pfffff
J'ai modifié mon post.
J'ai aussi essayé avec le Sample Hello, que tu fournis dans ta librairie, j'ai le même soucis.
Effectivement, j'avais aussi désactivé les interruptions quand j'ai mis en place mon player de Sample via un module Covox.
Ce qui me surprenais, c'est que tu n'as pas désactivé les interruptions sur ta version. Et même que Arturo ne l'inclus pas dans son code directement.
Le seul risque que je vois c'est si tu as un périphérique autre que VDP qui est connecté aux ports I/O et que tu veux pas raté une interruption.
Mais dans 95% des cas, à mon avis c'est mieux de désactivé les interruptions.
Ceci dit, check quand même bien car si avec les interruptions activés tu n'as pas le même résultat que moi, c'est que tu as surement un soucis qq part. Désactiver les interruptions risque que de "cacher" le problème.
Mais dans 95% des cas, à mon avis c'est mieux de désactivé les interruptions.
Ceci dit, check quand même bien car si avec les interruptions activés tu n'as pas le même résultat que moi, c'est que tu as surement un soucis qq part. Désactiver les interruptions risque que de "cacher" le problème.
On est toujours ignorant avant de savoir.
@ericb59 Pour info j'ai porté mon outils CMSXbin (renommé MSXbin) sous GCC.
Je sais que c'est plus CMSXimg qui t'intéresse mais pour un premier test CMSXbin était beaucoup plus simple à porter sous GCC.
Je vais passer sur CMSXimg (renommé MSXimg) maintenant.
En plus du passage sous GCC, je vais le compléter pour supporter les images en screen 0 et en screen 1, et ajouter des fonctionnalités pour la gestion du scrolling.
Je sais que c'est plus CMSXimg qui t'intéresse mais pour un premier test CMSXbin était beaucoup plus simple à porter sous GCC.
Je vais passer sur CMSXimg (renommé MSXimg) maintenant.
En plus du passage sous GCC, je vais le compléter pour supporter les images en screen 0 et en screen 1, et ajouter des fonctionnalités pour la gestion du scrolling.
On est toujours ignorant avant de savoir.
Non, c'est pas encore sur GitHub.
J'en profite pour centraliser certains traitements qui étaient redondant d'un outil a l'autre.
J'ai converti MSXzip et je m'occupe de MSXmath.
Je garde le meilleur (et le plus compliqué) -- MSXimg -- pour la fin.
J'en profite pour centraliser certains traitements qui étaient redondant d'un outil a l'autre.
J'ai converti MSXzip et je m'occupe de MSXmath.
Je garde le meilleur (et le plus compliqué
) -- MSXimg -- pour la fin.
On est toujours ignorant avant de savoir.
Salut,
Voici une premier version du module de scrolling pour MSXgl : https://webmsx.org/?ROM=https://github.com/aoineko-fr/MSXgl/raw/main/projects/samples/emul/rom/s_scroll.rom
Le scrolling horizontal tile-par-tile en 32x22 prend 37% du temps CPU d'une frame ; c'est pas trop mal pour du C, mais ça mériterait des optimisations.
Je vais ajouter une option de wrapping pour pouvoir boucler le scrolling sur un level.
Ensuite, ça sera scrolling vertical, puis une combinaison des deux.
Voici une premier version du module de scrolling pour MSXgl : https://webmsx.org/?ROM=https://github.com/aoineko-fr/MSXgl/raw/main/projects/samples/emul/rom/s_scroll.rom
Le scrolling horizontal tile-par-tile en 32x22 prend 37% du temps CPU d'une frame ; c'est pas trop mal pour du C, mais ça mériterait des optimisations.
Je vais ajouter une option de wrapping pour pouvoir boucler le scrolling sur un level.
Ensuite, ça sera scrolling vertical, puis une combinaison des deux.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie