Citer : Posté le 04/09/2025 16:35 | #

---

je suis reparti d'une vm "neuve" sous debian 12
maintenant

cmake -B build-linux -DAZUR_PLATFORM=linux -DCMAKE_BUILD_TYPE=Release
-- Checking for module 'sdl2'
-- Package 'sdl2', required by 'virtual:world', not found
CMake Error at /usr/share/cmake-3.25/Modules/FindPkgConfig.cmake:607 (message):
A required package was not found
Call Stack (most recent call first):
/usr/share/cmake-3.25/Modules/FindPkgConfig.cmake:829 (_pkg_check_modules_internal)
CMakeLists.txt:93 (pkg_check_modules)

Citer : Posté le 04/09/2025 19:07 | #

---

merci
j'ai aussi installé libopengl-dev et libfreetype-dev

plus de messages d'erreurs. c'est déja ça.




maintenant faut que je trouve que faire...

Citer : Posté le 04/09/2025 19:39 | #

---

make -C build-linux install -j$(nproc)

comme indiqué par Lephé

---

Citer : Posté le 04/09/2025 20:08 | #

---

Probablement parce que l'exécutable python n'existe pas. Tu peux installer python-is-python3.

Citer : Posté le 04/09/2025 20:46 | #

---

Non ça c'est ma faute ! J'ai poussé une correction. Tu peux faire git pull et relancer la commande make (pas besoin de reprendre au début).

---

Citer : Posté le 04/09/2025 20:58 | #

---

Ah, je vois. Désolé que ce soit compliqué, on n'a pas encore de release officielle et ces instructions sont plutôt prévues pour des devs. Mais pas de souci, je vais t'y amener.

On est d'accord que tu as clôné Azur et mq ? On commence par compiler Azur. Rends-toi dans le dossier d'Azur...


Et ensuite dans MQ :

---

Citer : Posté le 04/09/2025 21:42 | #

---

Bravo ! Le plus facile de faire File » Open dans le menu et une fois le fichier chargé, le bouton démarrer dans la barre en haut. Pour contrôler tu cliques sur la fenêtre clavier et ensuite tu peux soit cliquer sur les touches soit utiliser ton clavier (mais toutes les touches ne sont pas encore contrôlables au clavier... c'est pas super pratique).

---

Citer : Posté le 05/09/2025 17:11 | # | Fichier joint

---

Allez, un petit teasing d'une prochaine feature en préparation...vous avez une idée de ce que ça pourrait être ?

Citer : Posté le 23/09/2025 21:26 | #

---

La capture en vidéo ?

Citer : Posté le 05/10/2025 10:47 | #

---

Petit progress report pour vous tenir au courant de l'évolution du projet. Au programme : Threading, RTC, stabilité et recording!

Threading

Première grosse nouveauté : le threading est officiellement supporté dans MQ!

Alors, ça ne devrait pas changer beaucoup de choses pour vous directement (quelque gain de FPS, surtout sur la version web), mais le threading nous permet d'être beaucoup plus précis dans l'émulation des addins et c'est exactement pour ça qu'on l'a mis en place.

Avant la mise en place des threads, MQ cherchait à maintenir l'application (l'émulation + la GUI) à 60FPS, et donnait, à chaque frame, ~25% du temps pour mettre à jour la GUI et ~75% pour l'émulation. Ce qui signifie que l'émulation tournait constamment en mode dégradé.

Autant au début on s'en fichait, autant avec l'ajout des timers et du support de l'horloge (dont on parlera plus en détail plus bas), on commence à remarquer des problèmes de précision dans les jeux qui reposent sur l'horloge et les timers. Il nous fallait donc isoler l'émulation dans un thread à part pour qu'elle puisse tourner "à 100%" et régler une bonne partie de nos problèmes de précision.


L'horloge de gintctl avant et apres le threading

Cependant, le threading peut très vite être un piege. Certes, ça permet de gagner un peu de temps sur l'émulation, mais ça peut rendre le projet terriblement infernal à déboguer si ce n'est pas correctement préparé à l'avance. Comme l'architecture originelle d'MQ englobait intimement la GUI et l'émulation, Lephe a fait un gros travail pour proprement dissocier et isoler les deux parties au travers d'un "observeur" qui fait office d'entremetteur entre eux.

A noter aussi qu'une réécriture de la partie GUI a été faite au passage avec quelques changements subtils pour faciliter l'implémentation de future fonctionnalité qui devrait vous plaire plus tard.


Duet avant et apres le threading

Support de la RTC

Lors des dernières nouvelles apportées par Lephe, on vous expliquait que l'implémentation du Clock Pulse Generator (CPG), le module responsable de la gestion des clocks, avait permis de grandement stabiliser les addins écrits avec Gint qui reposent (en interne) sur les informations du module pour configurer ses timers (c'est ce qui permet, au passage, à Gint de résister et supporter l'overclocking).

Cependant, on a remarqué que les addin "classique", dont la quasi-totalité des addin mono, étaient beaucoup trop rapides, ce qui les rendait pratiquement inutilisables. Après un peu de recherche, on s'est rendu compte que beaucoup d'entre eux utilisaient l'horloge de la calculatrice, la Real-Time Clock (RTC), pour gérer leur fréquence d'image, généralement au travers du syscall RTC_GetTicks().


GeometryDash sans la RTC

Plutôt qu'implémenter une émulation "haut-niveaux" (HLE) en utilisant l'horloge de l'ordinateur qui fait tourner MQ (via date() par exemple) pour simuler le temps qui passe, on a fait le choix de réimplémenter entièrement la RTC en essayant d'émuler le comportement physique le plus fidèlement possible (une émulation "low-level" (LLE)).


GeometryDash avec la RTC

Après quelques jours de travail, le module RTC est maintenant entièrement supporté par MQ. La RTC fonctionne bien et on a réussi à reproduire toutes les fonctionnalités qu'elle offre, même celles qu'absolument personne n'utilise, comme l'alarme ou les interruptions de carry qui produit une interruption matérielle toutes les secondes.


Nouveau menu de test RTC pour Gintctl

Resultat? La grande majorité des jeux mono se sont mis à fonctionner à une vitesse convenable (modulo la précision de l'emulation, qui a été résolue après avec le threading)! Et on s'est aussi rendu compte que GravityDuck ne plantait plus à l'arrivée à certains derniers niveaux et que Bust-a-Move était devenue totalement jouable, ce qui n'était pas le cas avant l'arrivée de la RTC et ce pour une raison très simple : l'aléatoire.


Gameplay de Bust-A-Move

Et oui, une grande majorité des jeux utilisent la RTC pour récupérer une graine "unique" pour leur générateur de nombres pseudo-aléatoires! Ce qui nous a permis de rendre Bust-a-Move parfaitement jouable puisqu'avant on avait toujours une boule bleue qui apparaissait (vu que les registres RTC retournaient toujours 0), ce qui rendait impossible de passer des niveaux. GravityDuck quant à lui plantait à cause d'un surplus de mémoire utilisé pour les projectiles aléatoires qui apparaissaient beaucoup trop vite d'un coup.

Enfin bref, c'est un grand pas en avant en termes de compatibilité!


Gameplay de GravityDuck (avec un micro bug dans l'animation du perso)

À ce sujet, au cours de la ré-implémentation de la RTC, on a écrit un petit addin de tests qui permet de tester des configurations complexes et de visualiser le comportement du module en temps réel. Voyant que cette micro-application était au final assez pratique (je vous raconterai plus tard la découverte de bugs assez fourbes qui ont été à l'origine, entre autres, d'un fix pour Gint), qu'on a fini par la refondre et l'intégrer directement dans gintctl qui se dote maintenant d'une toute nouvelle interface pour tester en profondeur la RTC.

J'en ai aussi profité pour écrire une documentation technique sur ma partie de la bible pour les curieux !

Je te vois 👁️

Voilà une fonctionnalité qui devrait faire extrêmement plaisir au développeur! MQ est maintenant équipé d'une nouvelle option dans le menu de sélection d'addin: Watch input file (ou Watch pour les intimes).


Screenshot GUI

Watch est une fonctionnalité qui, une fois activée, demande à MQ d'observer les activités du fichier addin en train d'être émulé. S'il détecte une modification, comme par exemple un fxsdk build, l'émulateur redémarre automatiquement avec la nouvelle version du fichier. Vous n'avez donc absolument plus rien à toucher côté interface lorsque vous développez. Et pour avoir conçu tout le sous-menu de gintctl pour la RTC (et dont le menu de la mono sans avoir de mono sous la main), je peux vous garantir que c'est infiniment pratique pour déboguer à la volée !


Démonstration fonctionement du Watch

Après, si vous êtes encore plus flemmard, on a aussi mis en place un système de "CLI" dans MQ qui permet d'activer des options de la GUI directement pendant l'invocation de MQ. Pour l'instant, il existe que deux options : le premier c'est mq mon_addin, qui permet de démarrer directement l'émulation de l'addin "mon_addin" sans avoir à cliquer dans le menu de sélection et le bouton "play". Le second c'est mq --watch qui permet d'activer directement l'option Watch input file sans avoir à cocher la fonctionnalité. Bien sûr, les arguments sont cumulables, vous pouvez faire (et c'est ce que je fais très souvent maintenant) mq --watch gintctl.g1a et vous n'avez plus rien à toucher!

Pour les curieux, on a simplement utilisé inotify pour surveiller les activités du fichier sélectionné.

Une découverte...suprenante...

Je préfère vous prévenir, cette section et celle qui suit sont assez techniques (en tout cas, plus que les sections précédentes) .

Lors de nos tests pour mettre à jour le magnifique tableau de compatibilité, nous avons fait une découverte surprenante : le SH4 compatibility tool et la version manuelle sont buggés!

Et oui, les addins passés dans l'outil incluent un bug (inofensif) lié au clavier. C'est le cas de 2048 Delux de Kirafi, par exemple, dont la version SH4 ne répondait à aucune touche pressée. Après investigation, il se trouve que le SH4 Compatibility tool tente de faire une lecture "rapide" des registres KEYSC.KIUDATAx qui contiennent l'état actuel des touches pressées en les lisant 4 octets par 4 octets via un memcpy(), ce qui est, sur papier, impossible.

Le KEYSC n'est pas documenté, mais dans toutes les documentations qu'on a croisées, il est écrit qu'on ne peut théoriquement pas y accéder autrement qu'en 16 bits. Et ça a aussi été confirmé par l'émulateur officiel du SH7305 de Renesas qui refuse de lire les registres autrement qu'en 16 bits... mais comme la machine nous dit que c'est parfaitement possible et au vu du fait que les jeux sont parfaitement jouables...et bien, on s'aligne sur la vraie machine.

Une fois le support des acces en 8, 16 et 32 bits des registres KEYSC.KIUDATAx, tout les jeux passé dans les griffes du SH4 Compatibility tool se sont mis a repondre au clavier et a fonctionné normalement!


2048 Delux fonctionne maintenant

Cependant.

Si vous tentez de lancer 2048 Deluxe ou tout autre addin converti dans MQ, vous allez avoir une pléthore d'avertissements vous indiquant unhandled read @ a44b000c et figurez-vous que a44b00c c'est un registre clavier appelé KEYSC.KIUCNTREG dont le rôle est de configurer et observer le comportement du scan du clavier en action. C'est un registre qui est 1) pas documenté et 2) pas (encore) implémenté dans MQ, donc on a été assez surpris de le voir ici. Après investigation, il se trouve que le SH4 Compatibility tool tente de faire une lecture "rapide" des registres juste avant KEYSC.KIUDATAx...mais lit 4 octets trop loin. C'est donc bien un bug de l'outil et non de nous!

Le bal masqué...

Un autre bug assez surprenant (et que je vous avais mentionné plus haut) a été découvert en lien avec a la RTC et plus particulièrement ses interruptions : "carry" chaque seconde, "periodique" chaque période donnée et "alarme"...pour l'alarme.

Le bug de Gint (et par conséquent MQ aussi) est assez traitre, car Gint n'y est pour rien. Le module RTC du SH7305 est exactement le même que celui décrit dans le datasheet du SH7724...à une exception près (en réalité il y a plusieurs détails qui diffèrent, mais celui-là est le plus impactant) : le bit 0x04 de IMxR10 ne concerne pas l'interruption de "carry" mais celui de l'alarme et le bit 0x01 de IMxR10 ne concerne pas l'interruption de l'alarme, mais celui de "carry". Il y a donc une inversion de bits concernant le masquage des interruptions RTC sur la variante du SH7305. Pourquoi Renesas a fait cette modification? Pas la moindre idée.

Ce qu'il se passait, c'est que si vous tentiez d'activer l'interruption RTC périodique avec Gint, l'addin pouvait crasher purement et simplement, car comme les registres IMxR10 sont responsables de masquer (ignorer) ou non les interruptions, quand vous demandiez à Gint d'autoriser l'interruption de "carry", ce dernier autorisait en réalité l'interruption périodique. Si vous n'aviez pas installé de quoi attraper l'interruption périodique (gint ne l'attrape pas par défaut), l'addin plantait sans avoir aucun moyen de faire quoi que ce soit.

Une inversion de bit plus tard, et Gint est de nouveau entièrement capable de supporter correctement les interruptions de la RTC, et un autre commit a permis d'ajouter tous les registres d'alarme manquants. Vous avez maintenant entièrement la main sur l'horloge!

Le second bug qu'on a réussi à capturer, encore grâce aux tests avec la RTC, était une mauvaise gestion des registres INTC.IMRx (oui encore eux). Il se trouve que Gint n'initialise pas ces registres quand vous démarrez un addin, car il initialise déjà tous les registres INTC.IPRx à zéro, ce qui a pour conséquence de masquer les interruptions...et comme INTC.IMRx servent à masquer les interruptions eux aussi, Gint les ignore pour ne pas avoir à s'embêter à tout initialiser à la main.

Mais ce choix implique implicitement que Gint hérite de la configuration de Casio! Hors dans MQ, par défaut on met tous les registres à zéro et que donc MQ laisse passer par défaut toutes les interruptions (si elles ne sont pas masquées par les INTC.IPRx). Ce qui nous avait amené dans les tests à avoir les interruptions RTC qui se produisaient dans MQ mais pas sur la vraie machine.

On a donc recuperé les configurations des IMRx et correctement initialisé les registres en conséquence. Maintenant MQ a le bon comportement par défaut.

Je suis en train d'vous filmer la!

Comme testé dans mon poste précédent, le record de l'écran est directement intégré dans MQ!

Cela permettra de nous montrer l'avancement de vos projets, faire des screen-shots, vous montrer des corrections de bugs, et probablement plein d'autres utilisations qui justifient d'avoir une telle fonctionnalité dans MQ.

C'est moi qui m'occupe de cette fonctionnalité et contrairement au threading, il me reste pas mal de travail encore avant qu'on puisse l'intégrer, mais la preuve de concept fonctionne! Et vous en avez pour preuve quelques vidéos d'exemple sur ce poste!


Screenshot GUI

Ce qui manque principalement... c'est de la performance. Actuellement, la preuve de concept que j'ai implémentée repose exclusivement sur le CPU, ce qui impacte terriblement les performances. Pour vous donner un ordre d'idée, dites-vous qu'un jeu à 60FPS descend vers 5/6FPS lors du record. Oui, c'est aussi terrible que ça.


Gameplay CubeField

Les plus perspicaces pourraient me rétorquer "mais pourtant les vidéos sont parfaitement fluides non ?"

Exact! Et c'est parce que lors de l'enregistrement de la vidéo, je dis à ffmpeg (qui s'occupe d'encoder la vidéo) : "il va y avoir 60 images par seconde", puis j'ajoute les frames de l'écran une par une. Donc les performances de l'émulateur pour générer une frame n'influencent en rien la vidéo finale. A noter que ce comportement devrait changer pour refléter les "vraies" performances de l'émulateur (c’est-à-dire que s’il y a des lags, ils seront retranmis).

J'ai des pistes pour grandement améliorer les performances. Principalement détecter automatiquement les encodeurs matériels fournis par ffmpeg, ce qui devrait grandement accélérer le processus, et ensuite isoler l'encodage vidéo dans un thread à part (oui comme l'émulation). Avec ces deux cartes en main, on devrait possiblement arriver à quelque chose de descendant.

On verra comment cette fonctionnalité évolue dans les semaines qui arrivent.

La suite?

Comme mentionné plus haut, on s'active pour implémenter le record de l'écran et polir un petit peu l'interface et le coeur de MQ, après ça, on va sûrement basculer sur d'autres projets secrets pendant quelque temps. Il y aura sûrement un autre progress report d'ici là.

Ceci étant dit, à notre retour, on aimerait regarder pour fournir des builds propres de MQ pour toutes les plateformes (Linux, MacOS, Windows et web) pour que vous n'ayez pas à construire le projet par vous-même puisqu'il commence à devenir assez complexe de ce côté-là.

En plus de simplifier le plus possible l'installation du projet, on va sûrement aussi implémenter l'interface BFile, qui est une assez grosse partie puisqu'on peut avoir plusieurs façons de la mettre en place.

La plus simple serait de faire une bête interface ordinateur <-> MQ via des open(), read(), write(), close() qui pourrait fonctionner dans la majorité des cas et qui ne devrait probablement pas trop être compliquée à mettre en place.

Cependant, Gint3 (oui, oui) devrait offrir un tout nouveau système de fichier qui devrait intégrer en son sein Fygue, une ré-implémentation de Fugue, le système de fichier utilisé dans toutes les calculatrices récentes, et Casiowin qui est le FS historique de Casio. Ces deux ajouts permettront aux développeurs de ne plus avoir à faire de world-switch pour chaque interaction avec des fichiers et d'avoir un gros boost de performance (exemple : Fygue est actuellement 4x plus rapide que BFile pour lire entièrement doom.wad qui fait plusieurs Mo) en plus de beaucoup d'autres avantages.

Par contre Fygue et Casiowin reposent sur un accès direct à la Flash pour lire un système de fichiers, donc contrairement au addin qui utilise BFile, il ne suffit pas d'émuler une liste de fichiers et de répertoires, il faut simuler un état cohérent de la ROM avec les données au bon endroit...et ça, c'est beaucoup plus complexe... Mais pas impossible, on a déjà une vague idée de comment s'y prendre. On vous tiendra au courant dans tous les cas.

Voilà, c'est à peu près tout pour ce progress report, j'espère que c'était compréhensible. Je serais curieux de savoir si les détails techniques vous intéressent ou non à l'avenir.

A+

Citer : Posté le 05/10/2025 20:06 | #

---

Je me joins à Cake pour aussi vous féliciter. C'est vraiment un superbe boulot que vous faites tous sur MQ.
Je suis admiratif des progrès qui sont faits sur l'émulations des diverses machines.
En quelques mois, on passe d'un prototype à un émulateur qui fait tourner un grand nombre d'addins, c'est vraiment la classe internationale
Bon courage à vous et à lire vos splendides progrès avec le plus grand plaisir.
<3

---