La Place des Développeurs Curse of lies Participation au MSXdev24
popolon
Membre non connecté
Villageois
j'ai vu que tu n'avais pas utilisé de 3eme voix PSG, donc j'ai ajouté une voix reprenant la mélodie mais moitié moins forte et un chouilla décalée (classique pour grossir le morceau)
et j'ai baissé l'octave de l'accompagnement en 2eme partie mais ça devient limite funéraire
et j'ai baissé l'octave de l'accompagnement en 2eme partie mais ça devient limite funéraire
aoineko
Membre non connecté
Conseiller Municipal
Pour te faciliter la vie, tu peux générer directement ton fichier .DSK depuis un script (après la compilation par ex.).
Pour ça, récupère ma version du logiciel msxtar et ajoute dans un script .BAT cette ligne :
(en listant tous les fichiers à mettre dans la disquette)
Ceci dit, comme te disait Jipe, c'est un peu overkill d'utiliser le MSX-DOS2 pour un jeu MSX1.
Contrairement au MSX-DOS1, le 2 nécessite un BIOS supplémentaire qu'on trouve directement dans certains MSX ou en cartouche.
Ça limite le nombre de personnes qui pourront lancer ton jeu sur un vrai MSX, même si à mon avis une très grande majorité des MSXiens ont ce qu'il faut pour lancer le MSX-DOS2. Edité par aoineko Le 28/09/2024 à 22h16
Pour ça, récupère ma version du logiciel msxtar et ajoute dans un script .BAT cette ligne :
Code BASH :
msxtar -cf curse.dsk --dos2 --verbose --size=360K autoexec.bat COMMAND2.COM MSXDOS2.SYS curse.com ...
(en listant tous les fichiers à mettre dans la disquette)
Ceci dit, comme te disait Jipe, c'est un peu overkill d'utiliser le MSX-DOS2 pour un jeu MSX1.
Contrairement au MSX-DOS1, le 2 nécessite un BIOS supplémentaire qu'on trouve directement dans certains MSX ou en cartouche.
Ça limite le nombre de personnes qui pourront lancer ton jeu sur un vrai MSX, même si à mon avis une très grande majorité des MSXiens ont ce qu'il faut pour lancer le MSX-DOS2. Edité par aoineko Le 28/09/2024 à 22h16
On est toujours ignorant avant de savoir.
@Rei-VaX-82, en ce qui concerne les droits d'exclusivité, j'ai eu un peu de feedback, et en fait, tu as lancé un vrai débat donc ma réponse ne sera pas complète
La seule chose pour laquelle on est 100% sûr: publier des screenshots, musiques, ou partie du code dans des forums c'est vraiment pas un problème.
Par contre publier des versions jouable de ton œuvre en dehors du site officiel, rien n'est moins sûr, pourtant j'en ai déjà vu le faire sans être inquiété...
Une chose est sûr, c'est que les juges ne peuvent pas t'aider ou donner des avis avant la fin de l'évaluation finale et cela me semble aussi correct.
Voilà, j'attends encore un mail de la personne principale de l'organisation qui doit trancher car franchement c'est pas clair pour moi non plus.
Bien à toi
La seule chose pour laquelle on est 100% sûr: publier des screenshots, musiques, ou partie du code dans des forums c'est vraiment pas un problème.
Par contre publier des versions jouable de ton œuvre en dehors du site officiel, rien n'est moins sûr, pourtant j'en ai déjà vu le faire sans être inquiété...
Une chose est sûr, c'est que les juges ne peuvent pas t'aider ou donner des avis avant la fin de l'évaluation finale et cela me semble aussi correct.
Voilà, j'attends encore un mail de la personne principale de l'organisation qui doit trancher car franchement c'est pas clair pour moi non plus.
Bien à toi
Mumbly
Bonne nouvelle !!!!
MSXdev m'a annoncé que mon jeu est officiellement admit au concours.
Je compte toutefois améliorer cette version.
Il reste encore du taf :
- compatibilité avec Canon V20 MSX1
- transformation en rom
- colorisation progressive du jeu
Aller hop! au travail !!
MSXdev m'a annoncé que mon jeu est officiellement admit au concours.
Je compte toutefois améliorer cette version.
Il reste encore du taf :
- compatibilité avec Canon V20 MSX1
- transformation en rom
- colorisation progressive du jeu
Aller hop! au travail !!
Rien ne sert de courir, il faut juste avancer ...
Un petit Bug bizarre !!
Bonjour,
J'ai un bug avec "Fusion C" et SpriteOFF();
Sur l'emulateur OpenMSX avec la config :
machine Philips_NMS_8255
ext msxdos2
ext gfx9000
bind F12 cycle videosource
plug joyporta mouse
plug printerport simpl
diska dsk/
tout fonctionne bien.
Sur l'emulateur OpenMSX avec la config :
machine Canon V-20 (EU)
Il y a un Bug d'affichage dès que le programme fait appel à SpriteOff ();
Je te mets un petit programme de test et une rom pour les tests.
Bug-LT2.rom
LT2.zip
Si quelqu'un a une idée et du temps, je suis preneur.
Bonjour,
J'ai un bug avec "Fusion C" et SpriteOFF();
Sur l'emulateur OpenMSX avec la config :
machine Philips_NMS_8255
ext msxdos2
ext gfx9000
bind F12 cycle videosource
plug joyporta mouse
plug printerport simpl
diska dsk/
tout fonctionne bien.
Sur l'emulateur OpenMSX avec la config :
machine Canon V-20 (EU)
Il y a un Bug d'affichage dès que le programme fait appel à SpriteOff ();
Je te mets un petit programme de test et une rom pour les tests.
Bug-LT2.rom
LT2.zip
Si quelqu'un a une idée et du temps, je suis preneur.
Rien ne sert de courir, il faut juste avancer ...
aoineko
Membre non connecté
Conseiller Municipal
Tu peux décrire le bug en question ?
(j'ai pas d'émulateur ni de MSX sous la main)
Si ça ne marche pas sur MSX1 (en partant du principe que ton bug serait un sprite avec de mauvais attributs ou un mauvais dessin), cela pourrait venir des temps d'accès à la VRAM qui sont plus lent sur MSX1 que sur MSX2. Il y a donc du code assembleur qui peut copier trop vite dans la VRAM d'un MSX1 alors que le même code ne posera pas de problème sur MSX2.
Si tu veux des détails, j'ai écris un article à ce sujet : https://aoineko.org/msxgl/index.php?title=VRAM_access_timing
Après, ça pourrait être autre chose. Edité par aoineko Le 03/10/2024 à 14h17
(j'ai pas d'émulateur ni de MSX sous la main)
Si ça ne marche pas sur MSX1 (en partant du principe que ton bug serait un sprite avec de mauvais attributs ou un mauvais dessin), cela pourrait venir des temps d'accès à la VRAM qui sont plus lent sur MSX1 que sur MSX2. Il y a donc du code assembleur qui peut copier trop vite dans la VRAM d'un MSX1 alors que le même code ne posera pas de problème sur MSX2.
Si tu veux des détails, j'ai écris un article à ce sujet : https://aoineko.org/msxgl/index.php?title=VRAM_access_timing
Après, ça pourrait être autre chose. Edité par aoineko Le 03/10/2024 à 14h17
On est toujours ignorant avant de savoir.
Voici un petit descriptif :
Je charge un tableau des noms des tiles et les copy en Vram 0x1800.
L'ecran fait son job et affiche les Tiles à la bonne place.
Je fait un "SpritesOff();" :
Tout l'ecran se mélange, les tiles ne sont plus à la bonne place.
Je fait un "SpritesOn();" :
Tout l'écran revient à la normale, les tiles sont de nouveau à la bonne place.
Je charge un tableau des noms des tiles et les copy en Vram 0x1800.
L'ecran fait son job et affiche les Tiles à la bonne place.
Je fait un "SpritesOff();" :
Tout l'ecran se mélange, les tiles ne sont plus à la bonne place.
Je fait un "SpritesOn();" :
Tout l'écran revient à la normale, les tiles sont de nouveau à la bonne place.
Rien ne sert de courir, il faut juste avancer ...
je ne connais pas le C mais le VDP du MSX à bien un registre 8
mais pas sur qu'il ait la recopie dans les variables systèmes en FFE7
a creuser
mais pas sur qu'il ait la recopie dans les variables systèmes en FFE7
a creuser
/*
___________________________________________________________
/ __ _ \
| / _| (_) |
| | |_ _ _ ___ _ ___ _ __ |
| | _| | | / __| |/ _ \| '_ \ |
| | | | |_| \__ \ | (_) | | | | |
| |_| \__,_|___/_|\___/|_| |_| * |
| |
| The MSX C Library for SDCC |
| V1.0 - 09-10-11 2018 |
| |
| Eric Boez & Fernando Garcia |
| |
| C S O U R C E C O D E |
| compilation : > sdcc -mz80 -c msx_misc.c |
| |
\___________________________________________________________/
*/
/* spriteOff
| 2018 Eric Boez Updated November 2020
*/
void SpriteOff(void) __naked
{
__asm
RG1SAV = 0xF3E0
DPPAGE = 0xFAF5
ATRBAS = 0xF928
RG25SAV = 0xFFFA
RG2SAV = 0xF3E1
RG8SAV = 0xFFE7
RG9SAV = 0xFFE8
push ix
ld a,(RG8SAV)
or #0b00000010
ld (RG8SAV),a
ld b,a
ld c,#8
ld ix,#0x0047 ; Write VDP Bios
ld iy, (0xFCC0) ; mainrom slotaddress
call 0x001c ; interslotcall
ei
pop ix
ret
__endasm;
}
___________________________________________________________
/ __ _ \
| / _| (_) |
| | |_ _ _ ___ _ ___ _ __ |
| | _| | | / __| |/ _ \| '_ \ |
| | | | |_| \__ \ | (_) | | | | |
| |_| \__,_|___/_|\___/|_| |_| * |
| |
| The MSX C Library for SDCC |
| V1.0 - 09-10-11 2018 |
| |
| Eric Boez & Fernando Garcia |
| |
| C S O U R C E C O D E |
| compilation : > sdcc -mz80 -c msx_misc.c |
| |
\___________________________________________________________/
*/
/* spriteOff
| 2018 Eric Boez Updated November 2020
*/
void SpriteOff(void) __naked
{
__asm
RG1SAV = 0xF3E0
DPPAGE = 0xFAF5
ATRBAS = 0xF928
RG25SAV = 0xFFFA
RG2SAV = 0xF3E1
RG8SAV = 0xFFE7
RG9SAV = 0xFFE8
push ix
ld a,(RG8SAV)
or #0b00000010
ld (RG8SAV),a
ld b,a
ld c,#8
ld ix,#0x0047 ; Write VDP Bios
ld iy, (0xFCC0) ; mainrom slotaddress
call 0x001c ; interslotcall
ei
pop ix
ret
__endasm;
}
extrait de pratique du MSX2
0F3DFH RG0SAV 1 Contenu du registre 0 du VDP
0F3E0H RG1SAV 1 Contenu du registre 1 du VDP
0F3E1H RG2SAV 1 Contenu du registre 2 du VDP
0F3E2H RG3SAV 1 Contenu du registre 3 du VDP
0F3E3H RG4SAV 1 Contenu du registre 4 du VDP
0F3E4H RG5SAV 1 Contenu du registre 5 du VDP
0F3E5H RG6SAV 1 Contenu du registre 6 du VDP
0F3E6H RG7SAV 1 Contenu du registre 7 du VDP
0F3E7H STATFL 1 Contenu du registre de statut du VDP (registre 8)
0F3E0H RG1SAV 1 Contenu du registre 1 du VDP
0F3E1H RG2SAV 1 Contenu du registre 2 du VDP
0F3E2H RG3SAV 1 Contenu du registre 3 du VDP
0F3E3H RG4SAV 1 Contenu du registre 4 du VDP
0F3E4H RG5SAV 1 Contenu du registre 5 du VDP
0F3E5H RG6SAV 1 Contenu du registre 6 du VDP
0F3E6H RG7SAV 1 Contenu du registre 7 du VDP
0F3E7H STATFL 1 Contenu du registre de statut du VDP (registre 8)
aoineko
Membre non connecté
Conseiller Municipal
Tant qu'on n'utilise que le BIOS, tout changement du registre 8 du VDP est censé être recopié dans 0xFFE7.
Par contre, il est possible qu'une autre fonction de Fusion-C modifie ce registre sans passer par le BIOS; dans ce cas, ça peut être problématique.
Je jetterai un œil à ton code ce soir.
Par contre, il est possible qu'une autre fonction de Fusion-C modifie ce registre sans passer par le BIOS; dans ce cas, ça peut être problématique.
Je jetterai un œil à ton code ce soir.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie