La Place des Développeurs MSXgl MSX Game Library
Je ne me suis jamais penché dessus, mais au regard des échanges que j'ai pu lire ici et là, l'outil a l'air vraiment abouti, et prenant en compte l'essentiel des périphériques MSX.
S'y tenir et le faire évoluer pendant 2 ans est également une grande prouesse : BRAVO !
S'y tenir et le faire évoluer pendant 2 ans est également une grande prouesse : BRAVO !
On ne mesure pas encore l'influence que cet outil aura sur les futurs développements de logiciels MSX mais le MSXDev'23 nous en a donné une idée.
Bravo.
Bravo.
MSX1: Yeno DPC-64 - Sanyo PHC-28S - Sanyo PHC-28L - Canon V20 - Sony HB-75F - Yeno MX-64
MSX2: Panasonic FS-A1F 128Ko RAM 128 Ko VRAM + Gotek + Gotek / Philips NMS 8255 Azerty
Carnivore 2 : 8Mb FlashROM ° 1024Ko RAM ° IDE ° FM-PAC(MSX Music)° SCC+
Wozblaster
Merci. 
Y a beaucoup de projets en préparation... mais impossible de savoir combien iront jusqu'au bout.
En tout cas, je fais mon possible pour qu'ils ne trébuchent pas sur des soucis techniques.
Y a beaucoup de projets en préparation... mais impossible de savoir combien iront jusqu'au bout.
En tout cas, je fais mon possible pour qu'ils ne trébuchent pas sur des soucis techniques.
On est toujours ignorant avant de savoir.
Je commence à regarder cette librairie MSX-gl et, pour le peu que j'en ai déjà vu, il s'agit vraiment là d'un travail de pro ! Vraiment un grand bravo à Aoineko !!!
Même sur l'aspect packaging, les templates et samples étant pleinement opérationnels de suite. Il y aurait d'ailleurs là assez de matière pour écrire un livre sur le sujet.
J'ai vu sinon dans le fichier msxgl_config.h qu'il y avait possibilité de faire du debug, y a t'il quelque part une doc explicitant cela ? Notamment pour tout ce qui tourne autour d'OpenMSX avec les différentes features possibles ...
Edité par Chris (Spysoft) Le 22/08/2024 à 13h57
Même sur l'aspect packaging, les templates et samples étant pleinement opérationnels de suite. Il y aurait d'ailleurs là assez de matière pour écrire un livre sur le sujet.
J'ai vu sinon dans le fichier msxgl_config.h qu'il y avait possibilité de faire du debug, y a t'il quelque part une doc explicitant cela ? Notamment pour tout ce qui tourne autour d'OpenMSX avec les différentes features possibles ...
Edité par Chris (Spysoft) Le 22/08/2024 à 13h57
.......................>>> SPYSOFT <<< ...........................
...___.__..__..._.....__..__._____..__.._____.___..._...__..__...
../.__|..\/..|./_\...|..\/../.__\.\/./.|_..._|.__|./_\.|..\/..|..
..\__.\.|\/|.|/._.\..|.|\/|.\__.\>..<....|.|.|._|./._.\|.|\/|.|..
..|___/_|..|_/_/.\_\.|_|..|_|___/_/\_\...|_|.|___/_/.\_\_|..|_|..
.....
Salut Chris,
Content que la lib MSXgl te plaise.
Y a encore plein de choses qui arrivent.
Pour le debug, c'est un peu particulier car ça dépend entièrement du périphérique de debug utilisé... et donc, aujourd'hui, de l'émulateur utilisé (en attendant qu'un périphérique physique soit créé).
Tu trouveras des infos sur les fonctions du module Debug sur cette page : https://aoineko.org/msxgl/index.php?title=Modules/debug
Emulicious supporte toutes les fonctions, mais pour openMSX c'est plus compliqué.
De base (quand DEBUG_TOOL est égal à DEBUG_OPENMSX), tu n'auras que la fonction de log.
Pour pallier à cette lacune, un utilisateur de MSXgl a créé un script TCL pour ajouter de nouvelles fonctionnalités à openMSX.
Quand DEBUG_TOOL est égal à DEBUG_OPENMSX_P, le build tool de MSXgl va lancer openMSX en ajoutant automatique le fameux script, ce qui permet de débloquer l'utilisation des autres fonctions.
Ceci dit, je trouve que les outils de debug et de profiling (coté émulateur) de Emulicious sont beaucoup plus puissant que ce que propose openMSX.
Et si tu utilises VS Code come IDE (outil pour écrire ton code), tu peux avoir un débugueur directement intégré à l'IDE, ce qui est super pratique.
Les explications se trouvent là : https://aoineko.org/msxgl/index.php?title=Emulators#How_to_debug_using_VS_Code
Bonne programmation.
Edité par
aoineko
Le 23/08/2024 à 22h28
Content que la lib MSXgl te plaise.
Y a encore plein de choses qui arrivent.
Pour le debug, c'est un peu particulier car ça dépend entièrement du périphérique de debug utilisé... et donc, aujourd'hui, de l'émulateur utilisé (en attendant qu'un périphérique physique soit créé).
Tu trouveras des infos sur les fonctions du module Debug sur cette page : https://aoineko.org/msxgl/index.php?title=Modules/debug
Emulicious supporte toutes les fonctions, mais pour openMSX c'est plus compliqué.
De base (quand DEBUG_TOOL est égal à DEBUG_OPENMSX), tu n'auras que la fonction de log.
Pour pallier à cette lacune, un utilisateur de MSXgl a créé un script TCL pour ajouter de nouvelles fonctionnalités à openMSX.
Quand DEBUG_TOOL est égal à DEBUG_OPENMSX_P, le build tool de MSXgl va lancer openMSX en ajoutant automatique le fameux script, ce qui permet de débloquer l'utilisation des autres fonctions.
Ceci dit, je trouve que les outils de debug et de profiling (coté émulateur) de Emulicious sont beaucoup plus puissant que ce que propose openMSX.
Et si tu utilises VS Code come IDE (outil pour écrire ton code), tu peux avoir un débugueur directement intégré à l'IDE, ce qui est super pratique.
Les explications se trouvent là : https://aoineko.org/msxgl/index.php?title=Emulators#How_to_debug_using_VS_Code
Bonne programmation.
Edité par
aoineko
Le 23/08/2024 à 22h28
On est toujours ignorant avant de savoir.
Merci pour ces infos. La partie VS Code m'intéresse en effet. Je vais regarder ça et reviendrais vers toi si besoin d'infos complémentaires...
.......................>>> SPYSOFT <<< ...........................
...___.__..__..._.....__..__._____..__.._____.___..._...__..__...
../.__|..\/..|./_\...|..\/../.__\.\/./.|_..._|.__|./_\.|..\/..|..
..\__.\.|\/|.|/._.\..|.|\/|.\__.\>..<....|.|.|._|./._.\|.|\/|.|..
..|___/_|..|_/_/.\_\.|_|..|_|___/_/\_\...|_|.|___/_/.\_\_|..|_|..
.....
aoineko :
Salut Chris,
Content que la lib MSXgl te plaise.
Y a encore plein de choses qui arrivent.
Pour le debug, c'est un peu particulier car ça dépend entièrement du périphérique de debug utilisé... et donc, aujourd'hui, de l'émulateur utilisé (en attendant qu'un périphérique physique soit créé).
Tu trouveras des infos sur les fonctions du module Debug sur cette page : https://aoineko.org/msxgl/index.php?title=Modules/debug
Emulicious supporte toutes les fonctions, mais pour openMSX c'est plus compliqué.
De base (quand DEBUG_TOOL est égal à DEBUG_OPENMSX), tu n'auras que la fonction de log.
Pour pallier à cette lacune, un utilisateur de MSXgl a créé un script TCL pour ajouter de nouvelles fonctionnalités à openMSX.
Quand DEBUG_TOOL est égal à DEBUG_OPENMSX_P, le build tool de MSXgl va lancer openMSX en ajoutant automatique le fameux script, ce qui permet de débloquer l'utilisation des autres fonctions.
Ceci dit, je trouve que les outils de debug et de profiling (coté émulateur) de Emulicious sont beaucoup plus puissant que ce que propose openMSX.
Et si tu utilises VS Code come IDE (outil pour écrire ton code), tu peux avoir un débugueur directement intégré à l'IDE, ce qui est super pratique.
Les explications se trouvent là : https://aoineko.org/msxgl/index.php?title=Emulators#How_to_debug_using_VS_Code
Bonne programmation.
Content que la lib MSXgl te plaise.
Y a encore plein de choses qui arrivent.
Pour le debug, c'est un peu particulier car ça dépend entièrement du périphérique de debug utilisé... et donc, aujourd'hui, de l'émulateur utilisé (en attendant qu'un périphérique physique soit créé).
Tu trouveras des infos sur les fonctions du module Debug sur cette page : https://aoineko.org/msxgl/index.php?title=Modules/debug
Emulicious supporte toutes les fonctions, mais pour openMSX c'est plus compliqué.
De base (quand DEBUG_TOOL est égal à DEBUG_OPENMSX), tu n'auras que la fonction de log.
Pour pallier à cette lacune, un utilisateur de MSXgl a créé un script TCL pour ajouter de nouvelles fonctionnalités à openMSX.
Quand DEBUG_TOOL est égal à DEBUG_OPENMSX_P, le build tool de MSXgl va lancer openMSX en ajoutant automatique le fameux script, ce qui permet de débloquer l'utilisation des autres fonctions.
Ceci dit, je trouve que les outils de debug et de profiling (coté émulateur) de Emulicious sont beaucoup plus puissant que ce que propose openMSX.
Et si tu utilises VS Code come IDE (outil pour écrire ton code), tu peux avoir un débugueur directement intégré à l'IDE, ce qui est super pratique.
Les explications se trouvent là : https://aoineko.org/msxgl/index.php?title=Emulators#How_to_debug_using_VS_Code
Bonne programmation.
Je n'ai pas trouvé dans ta doc à l'adresse https://aoineko.org/msxgl/index.php?title=Emulators#How_to_debug_using_VS_Code la façon de lancer le build du projet depuis Visual Studio Code ... N'y aurait il pas un fichier tasks.json à créer ?
J'arrive bien à faire le build en lançant "./build.sh" depuis le terminal de VS Code mais est ce comme cela que tu procèdes personnellement ?
Sinon même en ajoutant les définitions debug indiquées sur la page https://aoineko.org/msxgl/index.php?title=Modules/debug, avec le mode Debug Emulicious défini dans le fichier msxgl_config.h, je me retrouve avec une vue DEBUG du code assembleur (voir début ci dessous) plutôt qu'avec mon programme C, qu'ai je pu oublier comme définition ?
<<<
; This disassembly was created using Emulicious (https://www.emulicious.net) br /> ; You might need to adjust this page layout to reassemble the disassembly to an equal ROM
defpage 0, 0x4000, 0x4000
defpage 1..1
map 0xc000
....
>>> Edité par Chris (Spysoft) Le 26/08/2024 à 16h00
.......................>>> SPYSOFT <<< ...........................
...___.__..__..._.....__..__._____..__.._____.___..._...__..__...
../.__|..\/..|./_\...|..\/../.__\.\/./.|_..._|.__|./_\.|..\/..|..
..\__.\.|\/|.|/._.\..|.|\/|.\__.\>..<....|.|.|._|./._.\|.|\/|.|..
..|___/_|..|_/_/.\_\.|_|..|_|___/_/\_\...|_|.|___/_/.\_\_|..|_|..
.....
Hello,
C'est dans le point #5.
Après, tu peux certainement automatiser avec des raccourcis claviers ou un bouton custom, mais je ne suis pas un pro de VS Code.
Pour ta 2e question, je n'ai pas bien compris le soucis. Edité par aoineko Le 27/08/2024 à 09h15
C'est dans le point #5.
Citation :
5. Vous êtes maintenant prêt à déboguer votre application à partir de VS Code. Allez dans le panneau " Run and Debug " et sélectionnez Attach (pour vous attacher à un jeu en cours d'exécution sur Emulicious) ou Launch (pour lancer votre jeu dans Emulicious). Si "stopOnEntry" est défini à true dans votre launch.json, le débogueur de VS Code devrait s'interrompre au début de votre fonction main().
5. Vous êtes maintenant prêt à déboguer votre application à partir de VS Code. Allez dans le panneau " Run and Debug " et sélectionnez Attach (pour vous attacher à un jeu en cours d'exécution sur Emulicious) ou Launch (pour lancer votre jeu dans Emulicious). Si "stopOnEntry" est défini à true dans votre launch.json, le débogueur de VS Code devrait s'interrompre au début de votre fonction main().
Après, tu peux certainement automatiser avec des raccourcis claviers ou un bouton custom, mais je ne suis pas un pro de VS Code.
Pour ta 2e question, je n'ai pas bien compris le soucis. Edité par aoineko Le 27/08/2024 à 09h15
On est toujours ignorant avant de savoir.
Le point #5 te permet de lancer le Run de l'application dans Emulicious mais pas de lancer la compilation de cette application. Mais je procède finalement en lançant le build.sh dans le terminal de VS Code.
Pour la seconde question, le problème était que je passais en mode debug sur le code assembleur généré et non sur mon programme C.
Mais j'ai trouvé la solution en déclarant debug=true dans le fichier project_config.js, ce que je n'avais pas vu indiqué dans la doc sur le debug.
En tout cas c'est vraiment top de pouvoir debugger son application C avec Visual Studio Code et Emulicious ... Edité par Chris (Spysoft) Le 27/08/2024 à 13h01
Pour la seconde question, le problème était que je passais en mode debug sur le code assembleur généré et non sur mon programme C.
Mais j'ai trouvé la solution en déclarant debug=true dans le fichier project_config.js, ce que je n'avais pas vu indiqué dans la doc sur le debug.
En tout cas c'est vraiment top de pouvoir debugger son application C avec Visual Studio Code et Emulicious ... Edité par Chris (Spysoft) Le 27/08/2024 à 13h01
.......................>>> SPYSOFT <<< ...........................
...___.__..__..._.....__..__._____..__.._____.___..._...__..__...
../.__|..\/..|./_\...|..\/../.__\.\/./.|_..._|.__|./_\.|..\/..|..
..\__.\.|\/|.|/._.\..|.|\/|.\__.\>..<....|.|.|._|./._.\|.|\/|.|..
..|___/_|..|_/_/.\_\.|_|..|_|___/_/\_\...|_|.|___/_/.\_\_|..|_|..
.....
Je n'avais pas compris la question.
Effectivement MSXgl n'a pas d'intégration particulière pour VS Code donc le plus simple pour build un project c'est de taper "build" dans le terminal (note qu'en fonction du choix du type de terminal, tu peux utiliser le .SH ou le .BAT).
On doit pouvoir facilement ajouter un bouton pour ça, mais j'ai pas encore regardé comment faire.
Ça fait un bout de temps que je pense à permettre de redéfinir les étapes de build depuis la ligne de commande. Ça permettrait d'avoir des boutons séparés pour l'assembage, la compilation, le link, le deployment et le démarrage. Edité par aoineko Le 28/08/2024 à 19h06
Effectivement MSXgl n'a pas d'intégration particulière pour VS Code donc le plus simple pour build un project c'est de taper "build" dans le terminal (note qu'en fonction du choix du type de terminal, tu peux utiliser le .SH ou le .BAT).
On doit pouvoir facilement ajouter un bouton pour ça, mais j'ai pas encore regardé comment faire.
Ça fait un bout de temps que je pense à permettre de redéfinir les étapes de build depuis la ligne de commande. Ça permettrait d'avoir des boutons séparés pour l'assembage, la compilation, le link, le deployment et le démarrage. Edité par aoineko Le 28/08/2024 à 19h06
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie