La Place des Développeurs Lire le contenu d'un fichier en ASM
Reprise du message précédent
GDX :
L'image n'est pas décalée ! Voici la capture de l'écran :
Oui, ça marche nickel dans ton exemple. Dans mon jeu, que ce soit mon image ou la tienne, j'ai le même soucis ; j'en conclu que ça viens pas du header de l'image.
On est toujours ignorant avant de savoir.
La routine qui appelle la Sub ROM est bien dans le Bank 2 ?
À part ça, peut-être que le pointeur de pile est mal placé (registre SP) ou que le compilateur utilise une zone de mémoire à l'endroit du buffer.
Autrement, tu n'as pas de routine de chargement en C pour MSX dans la bibliothèque ?
J'aimerai bien voir ce que ta ROM donne. Edité par GDX Le 29/04/2011 à 05h19
À part ça, peut-être que le pointeur de pile est mal placé (registre SP) ou que le compilateur utilise une zone de mémoire à l'endroit du buffer.
Autrement, tu n'as pas de routine de chargement en C pour MSX dans la bibliothèque ?
J'aimerai bien voir ce que ta ROM donne. Edité par GDX Le 29/04/2011 à 05h19
GDX :
La routine qui appelle la Sub ROM est bien dans le Bank 2 ?
Il est bien dans la Bank 2, mais la différence c'est que cette Bank pointe vers une ROM alors que dans ton exemple, elle pointe vers de la RAM. Y reste peut être un buffer pointant vers cette zone et ne pouvant donc pas être écrit. D'ailleurs, que ce passe t'il si on fait un LD vers une zone en ROM : ça fait rien ou ça crash ?
GDX :
À part ça, peut-être que le pointeur de pile est mal placé (registre SP) ou que le compilateur utilise une zone de mémoire à l'endroit du buffer.
Ma pile est placé en FC4Ah. J'ai encore jamais fait gaffe si elle était bien placé.
GDX :
Autrement, tu n'as pas de routine de chargement en C pour MSX dans la bibliothèque ?
J'utilise aucune routine du C. Je préfère maitriser tout ce que je fais. Le C permet juste de grandement me faciliter le code du gameplay.
GDX :
J'aimerai bien voir ce que ta ROM donne.
Je t'envoie ça à midi.
On est toujours ignorant avant de savoir.
Voila : carwar_prb_loading.zip.
C'est bizarre, on dirait que l'image est chargé dans un autre mode graphique.
Comme si les fonctions du DOS ne savaient pas qu'on est en mode 8.
C'est bizarre, on dirait que l'image est chargé dans un autre mode graphique.
Comme si les fonctions du DOS ne savaient pas qu'on est en mode 8.
On est toujours ignorant avant de savoir.
J'ai essayé un peu. Déjà, l'image est décalée parce que tu n'as pas corrigé l'erreur du tableau. Il y a un 020h qui ne s'écrit pas au bon endroit (coordonnée Y de destination). En remplaçant les 020h par des 0, l'image n'est plus décalée et s'affiche au bon endroit mais toujours anormalement. J'ai donc introduit un call 005fh pour mettre en screen8 avant le chargement et là bien que l'image se charge, l'écran reste noir ! 
Bizarre, on dirait que c'est un problème dans la gestion du VDP.
Autre chose, j'ai remarqué que ta ROM reste sur un écran noir sur un Turbo R A1-ST émulé par BlueMSX (sur OpenMSX ça marche). Edité par GDX Le 29/04/2011 à 14h43
Bizarre, on dirait que c'est un problème dans la gestion du VDP.
Autre chose, j'ai remarqué que ta ROM reste sur un écran noir sur un Turbo R A1-ST émulé par BlueMSX (sur OpenMSX ça marche). Edité par GDX Le 29/04/2011 à 14h43
Mon image (track_01.sc8) est en 256 x 212. Celle chargé par la ROM est celle de GDX, elle doit avoir la même taille, mais de toute façon, l'une ou l'autre on le même symptôme.
J'suis presque sur que DOS ne sait pas qu'on est en Screen 8 ; plus qu'à trouver pourquoi.
J'suis presque sur que DOS ne sait pas qu'on est en Screen 8 ; plus qu'à trouver pourquoi.
On est toujours ignorant avant de savoir.
aoineko :
J'suis presque sur que DOS ne sait pas qu'on est en Screen 8 ; plus qu'à trouver pourquoi.
Bingo ! C'était bien un problème en rapport avec la gestion du VDP. Tu ne mets pas la valeur du mode d'écran en cours à 8 dans les variables du système (0FCAFH). Lorsque c'est à 8, l'image se charge normalement.
Il ne te reste plus qu'à gérer les erreurs du disque...
J'ai patché la ROM d'hier afin de montrer ce que ça donne. Ça marche bien avec OpenMSX mais avec BlueMSX, ça ne marche que sur certains MSX. Par exemple, la ROM ne se lance pas sur un Turbo R A1-ST mais ça marche sur un A1-GT. Sur un MSX2+ Sony, ça retourne au Basic avec une erreur au moment de charger.
carwar.zip
Si ça marche sur un vrai MSX, c'est que BlueMSX a des problèmes. Edité par GDX Le 30/04/2011 à 12h44
carwar.zip
Si ça marche sur un vrai MSX, c'est que BlueMSX a des problèmes. Edité par GDX Le 30/04/2011 à 12h44
Pour les circuits, le plus simple est de remplir l'image avec la couleur 'wall'. Ensuite, tu dessines ton tracé avec une couleur de route ('road', 'grass', 'sand', etc.). Faut laisser une bordure (~8 pixels) autour de la route, mais pour le reste décors, c'est totalement libre (vu qu'on est pas censé y aller). A la fin, tu peux faire une passe d'ombre pour rendre le tout plus joli.
Voici des exemples de ce que ça pourrait donner.
Pour le mode 1 joueur, je compte pas le développer pour l'instant car : 1) c'est très difficile de faire une IA intéressante (qui fasse autre chose que suivre un chemin prédéfini) et 2) c'est un jeu a vocation multijoueur.
Ceci dit, en mode course, tu pourras toujours essayer de battre des records de vitesse.
Voici des exemples de ce que ça pourrait donner.
Pour le mode 1 joueur, je compte pas le développer pour l'instant car : 1) c'est très difficile de faire une IA intéressante (qui fasse autre chose que suivre un chemin prédéfini) et 2) c'est un jeu a vocation multijoueur.
Ceci dit, en mode course, tu pourras toujours essayer de battre des records de vitesse.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie