La Place des Développeurs Curse of lies Participation au MSXdev24
C'est un peu pointu pour moi. C'est pour cela que j'utilise des librairies.
J'ai fait une version du jeu qui n'utilise plus la fonction SpriteOff() mais cela fait un peu bricolage ( je place les 32 sprites en 0,0 avec une couleur de 0) .
Et avec toutes vos explications, j'ai fait un .rom qui fonctionne sur OpenMSX même en mode Canon V20(EU).
J'ai envoyé une première mise à jour à MSXdev24.
Je reste toujours à l'écoute, surtout s'il y a une solution élégante.
J'ai fait une version du jeu qui n'utilise plus la fonction SpriteOff() mais cela fait un peu bricolage ( je place les 32 sprites en 0,0 avec une couleur de 0) .
Et avec toutes vos explications, j'ai fait un .rom qui fonctionne sur OpenMSX même en mode Canon V20(EU).
J'ai envoyé une première mise à jour à MSXdev24.
Je reste toujours à l'écoute, surtout s'il y a une solution élégante.
Rien ne sert de courir, il faut juste avancer ...
j'ai trouvé ça pour la raison du sprite off mais avec ton jeu ça ne doit pas jouer beaucoup
When we analyze these tables a bit, several conclusions can be drawn:
- First of all, a highspeed copy (HMMM) is a little more than 2.8, meaning almost 3 times as fast as a lowspeed copy! An YMMM copy is even faster, it’s 3.4 times as fast.
- Secondly, did you notice that disabling the sprites during a copy-command matters a huge lot? Say disabling the screen gives a speedup of 100%. Compared to that, disabling the sprites gives you a speedup 87%!!! So, by simply disabling the sprites you can already gain almost as much VDP-processor power as by disabling the entire screen!!!
- From the previous you MIGHT conclude that the sprites use up 87% of the display process and that the building of the screen itself only uses 13% of the time. I don’t know if that’s a 100% correct though.
- In case of a copy it matters very little whether you’ve got the screen set to either 212 or 192 lines. With the sprites enabled, the difference it a bit more, 64 bytes in case of a HMMV, which is a half line in screen 5.
- First of all, a highspeed copy (HMMM) is a little more than 2.8, meaning almost 3 times as fast as a lowspeed copy! An YMMM copy is even faster, it’s 3.4 times as fast.
- Secondly, did you notice that disabling the sprites during a copy-command matters a huge lot? Say disabling the screen gives a speedup of 100%. Compared to that, disabling the sprites gives you a speedup 87%!!! So, by simply disabling the sprites you can already gain almost as much VDP-processor power as by disabling the entire screen!!!
- From the previous you MIGHT conclude that the sprites use up 87% of the display process and that the building of the screen itself only uses 13% of the time. I don’t know if that’s a 100% correct though.
- In case of a copy it matters very little whether you’ve got the screen set to either 212 or 192 lines. With the sprites enabled, the difference it a bit more, 64 bytes in case of a HMMV, which is a half line in screen 5.
Ah non, mais en fait c'est juste que le VDP du MSX1 n'a pas de fonction pour cacher les sprites comme sur MSX2.
Forcement, écrire dans un registre du VDP qui n'existe pas sur MSX1 ne risque pas de fonctionner.
Le plus simple pour cacher les sprites sur MSX1 c'est d'utiliser la coordonnée Y magique 208.
Si tu mets un sprite à la position Y = 208, ce sprite, et tous les suivants (dans l'ordre de leur index), ne s'afficheront pas.
A noter que sur MSX2, la coordonnée Y magique est 216.
Tu peux regarder dans le BIOS si c'est un MSX1 ou un MSX2 et utiliser soit la fonction pour désactiver les sprites sur MSX2, ou déplacer le premier sprite (index 0) à la position 208 sur MSX1.
Je ne sais pas si Fusion-C a une fonction pour récupérer la version du MSX, mais sinon tu as juste besoin de lire le valeur à l'adresse 0x002D.
Voici les valeurs :
Forcement, écrire dans un registre du VDP qui n'existe pas sur MSX1 ne risque pas de fonctionner.
Le plus simple pour cacher les sprites sur MSX1 c'est d'utiliser la coordonnée Y magique 208.
Si tu mets un sprite à la position Y = 208, ce sprite, et tous les suivants (dans l'ordre de leur index), ne s'afficheront pas.
A noter que sur MSX2, la coordonnée Y magique est 216.
Tu peux regarder dans le BIOS si c'est un MSX1 ou un MSX2 et utiliser soit la fonction pour désactiver les sprites sur MSX2, ou déplacer le premier sprite (index 0) à la position 208 sur MSX1.
Je ne sais pas si Fusion-C a une fonction pour récupérer la version du MSX, mais sinon tu as juste besoin de lire le valeur à l'adresse 0x002D.
Voici les valeurs :
Code :
Edité par
aoineko
Le 03/10/2024 à 21h19
0 = MSX 1
1 = MSX 2
2 = MSX 2+
3 = MSX turbo R
On est toujours ignorant avant de savoir.
Tiens, cadeau, une fonction pour cacher les sprites qui marchent sur MSX1 et MSX2 (non-testé) :
Je ne connais pas la fonction de Fusion-C pour changer la position d'un sprite, mais je pense que tu vois l'idée.
Edité par
aoineko
Le 03/10/2024 à 21h27
Code C :
void HideAllSprite() { HideY = 216; if(GetMSXVersion() == 0) // MSX1 HideY = 208; SetSpriteCoordinate(0, 0, HideY); // Merttre le sprite 0 (le 1er) à la position 0;HideY }
Je ne connais pas la fonction de Fusion-C pour changer la position d'un sprite, mais je pense que tu vois l'idée.
Edité par
aoineko
Le 03/10/2024 à 21h27
On est toujours ignorant avant de savoir.
Je me souviens de fonctions "spriteon" et "spriteoff" en basic sur msx1.( Vieux souvenirs de mes programmes en basic dans les année 80 )
Peut-on facilement les traduire en C ?
Si non, c'est une bonne astuce de les cacher. Pour ma part, je les mets de couleur 0 (transparents) et je les gare en (0,0).
je vais tester ton astuce du Y magique.
Peut-on facilement les traduire en C ?
Si non, c'est une bonne astuce de les cacher. Pour ma part, je les mets de couleur 0 (transparents) et je les gare en (0,0).
je vais tester ton astuce du Y magique.
Rien ne sert de courir, il faut juste avancer ...
Non mais c'est sûr à 100% que la fonction SpriteOff() de Fusion-C ne fonctionne pas sur un MSX1.
Le register 8 qu'elle utilise n'existe simplement pas sur MSX1.
Ne cherche pas plus loin.
L'avantage de la technique du Y magique, c'est que tu n'as besoin de bouger qu'un seul sprite pour le faire disparaitre ainsi que tous les suivants.
Donc si tu le fais sur le 1er sprite (index 0), tu vas pouvoir cacher tous les sprites d'un coup. Edité par aoineko Le 03/10/2024 à 22h18
Le register 8 qu'elle utilise n'existe simplement pas sur MSX1.
Ne cherche pas plus loin.
L'avantage de la technique du Y magique, c'est que tu n'as besoin de bouger qu'un seul sprite pour le faire disparaitre ainsi que tous les suivants.
Donc si tu le fais sur le 1er sprite (index 0), tu vas pouvoir cacher tous les sprites d'un coup. Edité par aoineko Le 03/10/2024 à 22h18
On est toujours ignorant avant de savoir.
Salut,
Désolé c'était peut être pas précisé dans le premier bouquin de Fusion-C, mais SpriteOn, SpriteOff sont dédiées au MSX2 et supérieur.
C'est indiqué dans le nouveau bouquin, qui sortira ... un jour
Désolé c'était peut être pas précisé dans le premier bouquin de Fusion-C, mais SpriteOn, SpriteOff sont dédiées au MSX2 et supérieur.
C'est indiqué dans le nouveau bouquin, qui sortira ... un jour
@Rei-VaX-82 s'il n'y pas de fonction dans Fusion-C pour désactiver le "clic" du clavier généré par le BIOS, tu peux utiliser ce code :
Pour l'utiliser, il suffit de mettre ce code au début de ta fonction main() :
Code C :
#define M_CLIKSW 0xF3DB // 1 Key click switch. (0 = Disabled / 1 = Enabled) u8 __at(M_CLIKSW) g_CLIKSW; // Enable or disable key click // // Parameters: // enable - TRUE to enable and FALSE to disable inline void Bios_SetKeyClick(bool enable) { g_CLIKSW = enable; }
Pour l'utiliser, il suffit de mettre ce code au début de ta fonction main() :
Code C :
Edité par
aoineko
Le 10/10/2024 à 22h12
Bios_SetKeyClick(false);
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie