La Place des Développeurs Projet Carwar
Reprise du message précédent
Alleluia !!Et bravo à toi pour avoir trouvé l'origine du problème... j'aurai pu chercher 6 mois sans trouver !
On est toujours ignorant avant de savoir.
Bravo Aoineko !!
Et tu avais raison, sur Turbo-R c'est tout à fait jouable !
Bonne continuation !!
Et tu avais raison, sur Turbo-R c'est tout à fait jouable !
Bonne continuation !!
je l'ai mis dans une romflash pour tester : c'est ok
j'ai testé la 3éme et 4éme voiture avec un joystick : ça marche
par contre le tour COLOR ,,X en basic est bleu ça serait mieux en noir
lors du choix il y a 2 fois 3 players a l'écran
ça m'est déja arrivé de chercher longtemps sur des problémes genre pourquoi sur un turbo-r les touches ne marchent pas avec le jeu pyroman et c'est un autre qui a trouvé !!
j'ai testé la 3éme et 4éme voiture avec un joystick : ça marche
par contre le tour COLOR ,,X en basic est bleu ça serait mieux en noir
lors du choix il y a 2 fois 3 players a l'écran
ça m'est déja arrivé de chercher longtemps sur des problémes genre pourquoi sur un turbo-r les touches ne marchent pas avec le jeu pyroman et c'est un autre qui a trouvé !!
GuillianSeed :
Et tu avais raison, sur Turbo-R c'est tout à fait jouable !
Jouable ou identique ? En fait, je suis pas bien sur de mon code de synchronisation de l'affichage .
J'utilise :
Code ASM :
di WAIT_RETRACE: in a,(0x99) and #0x80 cp #0 jr z, WAIT_RETRACE ei
Est-ce la façon correcte d'attendre la fin de l'affichage sur tous les MSX ?
On est toujours ignorant avant de savoir.
Jipe :
ça m'est déja arrivé de chercher longtemps sur des problémes genre pourquoi sur un turbo-r les touches ne marchent pas avec le jeu pyroman et c'est un autre qui a trouvé !!
C'est moi qui a trouvé mais j'avoue que j'ai recherché sur le net la solution. Je ne l'ai pas trouvé mais c'est un message d'un certain "Jipé" qui m'a mis sur la voie. Eh oui !
Le message disait que le Pyro-Man ne fonctionnait que sur un MSX français. J'ai donc cherché dans cette voie et trouvé qu'en fait la ROM du BIOS contient un tableau du mappage des touches. Ce tableau est placé au même endroit sur la plupart des MSX ayant un clavier international. Le développeur de Pyro-Man accédait directement a ce tableau en mettant l'adresse de début dans HL pour obtenir les caractères correspondant aux touches. Autant dire qu'il ne respectait pas tellement la norme MSX.
J'ai remarqué que ce tableau commence toujours par "0123456789" sauf sur certains MSX de Panasonic. C'est l'exception qui empêche de rechercher ce tableau puis de mettre l'adresse dans HL. J'ai alors recopié ce tableau dans le lanceur du jeu pour le mettre en RAM puis changé l'adresse de HL. Par chance, Pyro-man n'utilise pas de touches mappées différemment d'un MSX à l'autre.
Après, il ne restait plus que la manette à faire fonctionner et surprise, c'était la même méthode. Il y a aussi un tableau pour le mappage des manettes dans la ROM du BIOS !
Macadam Bumper et d'Illusions avant exactement le même problème.
Enfin bref, je ne pense pas que Aoineko fasse la même chose. Son problème de clavier doit être causé par autre chose. Edité par GDX Le 14/02/2011 à 02h02
GDX :
Enfin bref, je ne pense pas que Aoineko fasse la même chose. Son problème de clavier doit être causé par autre chose.
J'ai pas de problème de clavier.
J'avais juste des valeurs incorrectes dans certains registres du VDP. Tout est maintenant ok (à part qq comportement bizarre des sprites sur lequels je me pencherai plus tard).
On est toujours ignorant avant de savoir.
aoineko :
Est-ce la façon correcte d'attendre la fin de l'affichage sur tous les MSX ?
Code ASM :
di WAIT_RETRACE: in a,(0x99) and #0x80 cp #0 jr z, WAIT_RETRACE ei
Est-ce la façon correcte d'attendre la fin de l'affichage sur tous les MSX ?
Et tu fais quoi exactement ? Je ne comprends pas.
Tu lis une valeur sur le port du VDP mais laquelle ?
Le seul signal de la fin de l'affichage est donné par le VBLANK généré par le VDP.
Il génère une interruption qui appelle $38 puis le hook HTIMI en $FD9F.
Tu pourrais donc faire une petite routine appelée par le hook $FD9F qui modifierai une variable en RAM.
Et ensuite une boucle dans ton code principal qui lit la valeur et attend sa modification ...
Mais il y a certainement d'autres solutions.
La plus simple pourrait être de positionner une opcode "HALT".
Le Z80 se met en pause et attend la prochaine interruption avant de redémarrer.
Le problème c'est qu'il peut y avoir d'autres interruptions que le VBLANK, ce n'est donc pas sur à 100%.
PS : l'opcode "AND" positionne déjà les flags de résultat, tu n'as donc pas besoin de la ligne "CP 0", tu peux la supprimer.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Metalion :
Et tu fais quoi exactement ? Je ne comprends pas.
Aucune idée.
En fait, c'est un bout de code que j'avais du récupérer y a 2 ans quand j'avais essayé de me mettre au MSX et dont je ne me souviens pas du tout la provenance !
Pour la méthode "propre", il ne suffit pas d'attendre que le bit VR du registre S#2 soit à 0 ?
On est toujours ignorant avant de savoir.
Et dans la série "j'utilise du code sans savoir à quoi ça sert", y a aussi l'entête de ma ROM que je set à :
Ou puis-je trouver la signification des 16 bytes d'entête d'une ROM ?
(Il me semble que AB est le code d'identification du début d'entête et que 4010h est l'adresse de début de mon code ; par contre, je sais pas du tout à quoi sert le reste...) Edité par aoineko Le 14/02/2011 à 10h28
Code ASM :
41 42 10 40 00 00 00 00 00 00 00 00 00 00 00 00
Ou puis-je trouver la signification des 16 bytes d'entête d'une ROM ?
(Il me semble que AB est le code d'identification du début d'entête et que 4010h est l'adresse de début de mon code ; par contre, je sais pas du tout à quoi sert le reste...) Edité par aoineko Le 14/02/2011 à 10h28
On est toujours ignorant avant de savoir.
description d'Elektor février 1986
00 01 ID 41 42 = ROM
02 03 INIT adresse d'init
04 05 STATEMENT adresse sous programme CALL
06 07 DEVICE adresse d'organe matériel
08 09 TEXT adresse début texte BASIC si basic en rom
0A 10 RESERVE
00 01 ID 41 42 = ROM
02 03 INIT adresse d'init
04 05 STATEMENT adresse sous programme CALL
06 07 DEVICE adresse d'organe matériel
08 09 TEXT adresse début texte BASIC si basic en rom
0A 10 RESERVE
aoineko :
Et dans la série "j'utilise du code sans savoir à quoi ça sert", y a aussi l'entête de ma ROM que je set à :
Ou puis-je trouver la signification des 16 bytes d'entête d'une ROM ?
(Il me semble que AB est le code d'identification du début d'entête et que 4010h est l'adresse de début de mon code ; par contre, je sais pas du tout à quoi sert le reste...)
Code ASM :
41 42 10 40 00 00 00 00 00 00 00 00 00 00 00 00
Ou puis-je trouver la signification des 16 bytes d'entête d'une ROM ?
(Il me semble que AB est le code d'identification du début d'entête et que 4010h est l'adresse de début de mon code ; par contre, je sais pas du tout à quoi sert le reste...)
L'explication promise arrivera prochainement. Elle est importante pour ton jeu car sinon, tu ne pourras pas faire fonctionner le lecteur de disquette.
PS: J'ai cru remarqué que dans ton programme que tu ne tient pas compte des Slot secondaire. Ton jeu risque de ne pas marcher sur un multiplicateur de Slot. Edité par GDX Le 14/02/2011 à 14h03
En fait, j'ai pas vraiment de problème avec ma ROM, mais dans BlueMSX, elle est reconnue comme "Mirrored ROM" ; je me demandais si c'était normal ou s'il ne manquait pas qq infos.
On est toujours ignorant avant de savoir.
Voici une nouvelle version de mon projet : Carwar v0.0.8.
Au premier coup d'oeil, vous verrez peut-être pas les améliorations, mais en fait, il y a un changement majeur : la physique des voitures en maintenant entièrement paramétrable ! J'ai passé toute la semaine dessus, mais j'ai enfin trouvé un moyen d'avoir un maximum de flexibilité pour un moindre cout CPU. Du coup, on peut paramétrer :
En plus des voitures, le terrain change maintenant aussi ces paramètres (faible adhérence sur la glace, grosse friction dans le sable, etc.).
Le terrain est détecté en fonction des couleurs sur le circuit :
On pourra soit utiliser une image SC8 (256x212) faite avec un éditeur d'image et chargé depuis un disque ou bien choisir parmi les circuits en dur sur la ROM (fait avec de blocs 32x32 compressés).
La suite bientôt...
EDIT : J'ai mis à jour le premier post de cette discussion avec des images et l'avancement du projet. Edité par aoineko Le 19/02/2011 à 00h42
Au premier coup d'oeil, vous verrez peut-être pas les améliorations, mais en fait, il y a un changement majeur : la physique des voitures en maintenant entièrement paramétrable ! J'ai passé toute la semaine dessus, mais j'ai enfin trouvé un moyen d'avoir un maximum de flexibilité pour un moindre cout CPU. Du coup, on peut paramétrer :
- L'accélération
- La vitesse maximal
- La vitesse de rotation
- La friction
- L'adhérence
En plus des voitures, le terrain change maintenant aussi ces paramètres (faible adhérence sur la glace, grosse friction dans le sable, etc.).
Le terrain est détecté en fonction des couleurs sur le circuit :
On pourra soit utiliser une image SC8 (256x212) faite avec un éditeur d'image et chargé depuis un disque ou bien choisir parmi les circuits en dur sur la ROM (fait avec de blocs 32x32 compressés).
La suite bientôt...
EDIT : J'ai mis à jour le premier post de cette discussion avec des images et l'avancement du projet. Edité par aoineko Le 19/02/2011 à 00h42
On est toujours ignorant avant de savoir.
J'ai ajouté les collisions entre les voitures et le décors.
Ca se passe par ici : Carwar v0.0.9.
Bon, faudra que je diminue la vitesse lors des collisions mais bon, au moins, ça marche.
Ca se passe par ici : Carwar v0.0.9.
Bon, faudra que je diminue la vitesse lors des collisions mais bon, au moins, ça marche.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie