La Place des Développeurs Projet Ambidex
Reprise du message précédent
MSXosaure :
ton AND #0x3F limite ton y à 63 non?
Oui, je pense que le problème vient de là ...
Tu élimines systématiquement toutes les valeurs supérieures à 63.
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)
J'ai testé en passant directement le Y, mais ça ne marche qu'a peine mieux. Y a toujours un décalage et parfois des plantages complets. 
En fait, le problème c'est que je ne sais plus du tout ce que je suis censé passer comme paramètre ! Les info étaient dans le forum de feu-MSXCafé.
J'ai bien cherché dans la doc du V9938, mais pas facile de trouver qq chose avec une doc scanné ! (D'ailleurs, si qq'un à une version numérique, ça m'intéresse grandement !)
Si quelqu'un a une routine pour écrire directement un pixel en VRAM en screen 8 (sans passer par le PSET), ça serait certainement le plus simple. Je l'adapterai à mes besoins.
Pareil pour une copie rapide d'un bloc en RAM vers la VRAM.
En fait, le problème c'est que je ne sais plus du tout ce que je suis censé passer comme paramètre ! Les info étaient dans le forum de feu-MSXCafé.
J'ai bien cherché dans la doc du V9938, mais pas facile de trouver qq chose avec une doc scanné ! (D'ailleurs, si qq'un à une version numérique, ça m'intéresse grandement !)
Si quelqu'un a une routine pour écrire directement un pixel en VRAM en screen 8 (sans passer par le PSET), ça serait certainement le plus simple. Je l'adapterai à mes besoins.
Pareil pour une copie rapide d'un bloc en RAM vers la VRAM.
On est toujours ignorant avant de savoir.
Tout est ici à partir de la page 129 (c'est un fichier pdf indexable) :
http://www.msxvillage.fr/download/download.php?id=3
Deux possibilités :
- Tu allumes un pixel à partir des macros du VDP
- Tu écris directement dans la VRAM mais il faut connaitre sa structure propre dans chaque mode graphique
http://www.msxvillage.fr/download/download.php?id=3
Deux possibilités :
- Tu allumes un pixel à partir des macros du VDP
- Tu écris directement dans la VRAM mais il faut connaitre sa structure propre dans chaque mode graphique
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)
Merci, je vais lire tout ça.
Par contre, votre expérience me serait très utile pour savoir si mon projet est techniquement réalisable. A savoir :
- En Screen 8 (256x212 en 256 couleurs), donc uniquement 2 page dans la VRAM
- Avoir un décors fixe fait de tiles (8x8) ; construit une fois en mémoire au début du niveau
- Jusqu'à 8 personnages mobiles (16x16~32x32) ; en sprites (2 par personnage) ou en copie depuis la mémoire (comment faire pour la transparence ?)
- Quelques objets ramassables (qui pourraient être compter comme un personnage ; si 2 objets, seulement 6 personnages)
Est-ce réalisable ?
Par contre, votre expérience me serait très utile pour savoir si mon projet est techniquement réalisable. A savoir :
- En Screen 8 (256x212 en 256 couleurs), donc uniquement 2 page dans la VRAM
- Avoir un décors fixe fait de tiles (8x8) ; construit une fois en mémoire au début du niveau
- Jusqu'à 8 personnages mobiles (16x16~32x32) ; en sprites (2 par personnage) ou en copie depuis la mémoire (comment faire pour la transparence ?)
- Quelques objets ramassables (qui pourraient être compter comme un personnage ; si 2 objets, seulement 6 personnages)
Est-ce réalisable ?
On est toujours ignorant avant de savoir.
en screen 8 ça limite pour utiliser les copy afin d'anime les personnages
le probléme n'étant pas de poser le perso en transparence mais de restaurer le décor une fois qu'il se déplace
les sprites n'ont pas cet inconvénient mais les persos sont moins riches en couleur
la palettes de sprites en screen 8 est limitée si je me rappelle bien
le screen 5 est plus ouvert pour faire des jeux
le probléme n'étant pas de poser le perso en transparence mais de restaurer le décor une fois qu'il se déplace
les sprites n'ont pas cet inconvénient mais les persos sont moins riches en couleur
la palettes de sprites en screen 8 est limitée si je me rappelle bien
le screen 5 est plus ouvert pour faire des jeux
Jipe :
en screen 8 ça limite pour utiliser les copy afin d'anime les personnages
le probléme n'étant pas de poser le perso en transparence mais de restaurer le décor une fois qu'il se déplace
les sprites n'ont pas cet inconvénient mais les persos sont moins riches en couleur
la palettes de sprites en screen 8 est limitée si je me rappelle bien
le screen 5 est plus ouvert pour faire des jeux
le probléme n'étant pas de poser le perso en transparence mais de restaurer le décor une fois qu'il se déplace
les sprites n'ont pas cet inconvénient mais les persos sont moins riches en couleur
la palettes de sprites en screen 8 est limitée si je me rappelle bien
le screen 5 est plus ouvert pour faire des jeux
Quel est le problème avec la recopie du décors (s'il est stocké déjà monté en RAM) ?
Pour les sprites, si j'en prends 2 par personnages, ça fait 32 couleurs, non ? Je crois que la limite par ligne est de 16 ; d'où ma limite à 8 personnages. Par contre, je connais pas la contrainte de taille des sprites (16x16 ?) ; j'espère que tout ça est expliqué dans le doc pointé par Metalion. Edité par aoineko Le 12/01/2011 à 17h48
On est toujours ignorant avant de savoir.
J'ai du mal à comprendre, tu as l'air d'avoir un super niveau? Ce doit être une méconnaissance du MSX (2) qui te bloque, je te conseille de te plonger dans ce bouquin: Le livre du MSX2, dans cette version dactylographiée par notre ami Granced tu trouveras plein d'info sur les registres du VDP (R46 à 10011000 correspond à une copie VRAM à VRAM avec gestion de la couleur transparente 0 pages 33-34) et comment faire ces copie à partir de la page 56 (du bouquin bien sûr 
)
Pour ce qui est de la gestion du point chaque point de l'écran correspond à une adresse mémoire (1 octet) du VDP en screen8 première ligne 0 à 255, deuxième 256 à 511, etc...). Rien de plus simple pour allumer (/éteindre) un point à l'écran il suffit d'envoyer la bonne valeur (couleur) au bon endroit (x+y*256). ;-)
c'est ça que tu cherchais ou j'ai rien pigé
Pour finir , tu peux réaliser un jeu en screen 8 en assembleur, ayant accès à la mémoire " haute" tu peux y stocker des graphismes et jouer par la suite sur les deux pages écran pour le reste, mais n'oublie pas que certains MSX2 ne possèdent que 64 k. Cela sera donc plus difficile à gérer que sur screen5 où une image écran prend 2 fois moins de place (unoctet pour 2 points)
PS: content de pouvoir te relire Metalion
)Pour ce qui est de la gestion du point chaque point de l'écran correspond à une adresse mémoire (1 octet) du VDP en screen8 première ligne 0 à 255, deuxième 256 à 511, etc...). Rien de plus simple pour allumer (/éteindre) un point à l'écran il suffit d'envoyer la bonne valeur (couleur) au bon endroit (x+y*256). ;-)
c'est ça que tu cherchais ou j'ai rien pigé
Pour finir , tu peux réaliser un jeu en screen 8 en assembleur, ayant accès à la mémoire " haute" tu peux y stocker des graphismes et jouer par la suite sur les deux pages écran pour le reste, mais n'oublie pas que certains MSX2 ne possèdent que 64 k. Cela sera donc plus difficile à gérer que sur screen5 où une image écran prend 2 fois moins de place (unoctet pour 2 points)
PS: content de pouvoir te relire Metalion
Le MSXien le plus à l'ouest
... ou presque 
en fait si tu utilises des sprites pas besoin de restaurer le décor ( je parlai des copy regarde les exemples mario en screen 5 dans le forum )
il y a 2 tailles pour les sprites 8X8 et 16X16 a définir au début du programme plus une fonction magnitude X2 donc max 32 x 32 mais pixelise
on peut afficher 32 sprites simultanés a l'écran mais il y a une limitation de 8 sprites maxi en MSX2 sur une seule ligne ( attention aux émulateurs qui augmentent parfois cette valeur )
un même sprite peut être multicolore ( une seule couleur par ligne ) avec l'instruction color sprite en basic
il y a 2 tailles pour les sprites 8X8 et 16X16 a définir au début du programme plus une fonction magnitude X2 donc max 32 x 32 mais pixelise
on peut afficher 32 sprites simultanés a l'écran mais il y a une limitation de 8 sprites maxi en MSX2 sur une seule ligne ( attention aux émulateurs qui augmentent parfois cette valeur )
un même sprite peut être multicolore ( une seule couleur par ligne ) avec l'instruction color sprite en basic
Quelqu'un aurait le tableau (numérique) des valeurs RGB des 256 couleurs du mode 8 ? J'en aurait besoin pour convertir des images (BMP2MSX ne me donne pas un résultat satisfaisant).
On est toujours ignorant avant de savoir.
Pas un tableau mais y a une formule:
Le code couleur se calcule comme suit: (Vert *32) + (Rouge*4) + Bleu
Par exemple: couleur 119= 3*32+ 5*4 + 1 -> 3 vert + 5 rouge + 1 bleu.
Attention:
Le rouge et le vert ont une variation de de 0 à 7 ( 8 ) et le bleu de 0 à 3 (4)
Le code couleur se calcule comme suit: (Vert *32) + (Rouge*4) + Bleu
Par exemple: couleur 119= 3*32+ 5*4 + 1 -> 3 vert + 5 rouge + 1 bleu.
Attention:
Le rouge et le vert ont une variation de de 0 à 7 ( 8 ) et le bleu de 0 à 3 (4)
Le MSXien le plus à l'ouest
... ou presque
Je m'y perd un peu au niveau des histoires de slots et de pages. 
Bon déjà, pour assurer la compatibilité de mon programme, je ne pense pas utiliser de memory-mapper (qui semble pas standard sur les MSX2 si j'ai bien compris).
Ensuite, pour le slot de ma ROM, les adresses relatives de mes datas seront t'elles les adresses que je pourrais passer au Z80 pour faire par exemple des copies de blocs vers la VRAM (après avoir changer le slot courant par celui de ma ROM). Si c'est le cas, cela veux dire que le début de ma ROM se trouver sur la page 0, la même que le BIOS. Comment faire donc si je veux utiliser une instruction BIOS qui lierait dans la page 0 de la ROM !? Si je set le slot courant de la page 0 a celui du BIOS j'ai plus accès à la page 0 de ma ROM et inversement.
En gros, que faut t'il faire pour transférer un blocs mémoire de ma ROM (des donnés que j'aurais inclus dedans), dont je ne connais que la position relative au début de la ROM, vers la VRAM ?
EDIT : Question subsidiaire : Dans le code que j'avais écris y a quelque temps, j'utilisai des valeurs en dur pour accéder aux ports du VDP au lieu de lire l'adresse dans le registre 7. Je pense que c'est l'un de vous qui m'avait conseillé cela.
A quel point c'est mal ? C'est juste philosophique ou est-ce que cela créé de réel incompatibilités ? Y a t'il un gain significatif en passant par une valeur en dur par rapport à la lecture du registre idoine ? (ça a au moins l'avantage de libérer un registre).
Edité par
aoineko
Le 14/01/2011 à 00h42
Bon déjà, pour assurer la compatibilité de mon programme, je ne pense pas utiliser de memory-mapper (qui semble pas standard sur les MSX2 si j'ai bien compris).
Ensuite, pour le slot de ma ROM, les adresses relatives de mes datas seront t'elles les adresses que je pourrais passer au Z80 pour faire par exemple des copies de blocs vers la VRAM (après avoir changer le slot courant par celui de ma ROM). Si c'est le cas, cela veux dire que le début de ma ROM se trouver sur la page 0, la même que le BIOS. Comment faire donc si je veux utiliser une instruction BIOS qui lierait dans la page 0 de la ROM !? Si je set le slot courant de la page 0 a celui du BIOS j'ai plus accès à la page 0 de ma ROM et inversement.
En gros, que faut t'il faire pour transférer un blocs mémoire de ma ROM (des donnés que j'aurais inclus dedans), dont je ne connais que la position relative au début de la ROM, vers la VRAM ?
EDIT : Question subsidiaire : Dans le code que j'avais écris y a quelque temps, j'utilisai des valeurs en dur pour accéder aux ports du VDP au lieu de lire l'adresse dans le registre 7. Je pense que c'est l'un de vous qui m'avait conseillé cela.
A quel point c'est mal ? C'est juste philosophique ou est-ce que cela créé de réel incompatibilités ? Y a t'il un gain significatif en passant par une valeur en dur par rapport à la lecture du registre idoine ? (ça a au moins l'avantage de libérer un registre).
Edité par
aoineko
Le 14/01/2011 à 00h42
On est toujours ignorant avant de savoir.
La première chose dans un projet comme le tien est de déterminer la structure de l'espace mémoire adressé par le Z80 durant l'exécution du code. La structure généralement retenue est la suivante :
slot 0 ($0000 - $3FFF) : page ROM contenant le BIOS afin d'accéder aux fonctions
slot 1 ($4000 - $7FFF) : page contenant le code principal du jeu, les librairies, la gestion du changement de pages ...
slot 2 ($8000 - $BFFF) : page libre, pouvant contenir n'importe quelle page de ta ROM
slot 3 ($C000 - $FFFF) : page RAM d'origine, afin préserver les hooks, notamment celui des interruptions, mais aussi pour garder un espace RAM de travail (décompression, stockage données, variables ...)
Bien évidemment, d'autres structures sont possibles ... On peut notamment transférer le code principal du jeu en RAM sur la page 3 et gérer un changement de page sur les slot 1 et 2, ce qui permet d'accéder à plus de données en même temps.
Pour répondre à ta question, les données contenues dans tes pages sont toujours en adressage relatif. Si tes données sont stockées en $1A00 sur ta page, leur adresse sera $1A00 si la page est sur le slot 0, $5A00 si la page est sur le slot 1, $9A00 si la page est sur le slot 2 ...
Dans la structure que je décris au dessus, tu initialise ton programme à partir de la page 1, puis tu gères tes données en les faisant apparaitre au besoin dans la page 2, le temps de les transférer en VRAM par exemple ...
Pour ta dernière question, la question est plutôt philosophique ... 99% des MSX ont leur ports VDP aux mêmes adresses ($98 et $99). Les cas d'incompatibilités connus sont plutôt rares : machines très exotiques, extension MSX2 pour MSX1, ... Or le gain est réellement significatif dans l'accès aux ports VDP si on utilise les valeurs en dur. De plus, on est plus vraiment à l'époque où cela avait une importance commerciale d'être absolument compatible à 100%. La majorité des amateurs MSX actuellement utilisent un émulateur, et ceux qui ont une machine n'ont pas généralement de bidules exotiques ... Tu peux utiliser ces valeurs en dur sans aucun problème.
slot 0 ($0000 - $3FFF) : page ROM contenant le BIOS afin d'accéder aux fonctions
slot 1 ($4000 - $7FFF) : page contenant le code principal du jeu, les librairies, la gestion du changement de pages ...
slot 2 ($8000 - $BFFF) : page libre, pouvant contenir n'importe quelle page de ta ROM
slot 3 ($C000 - $FFFF) : page RAM d'origine, afin préserver les hooks, notamment celui des interruptions, mais aussi pour garder un espace RAM de travail (décompression, stockage données, variables ...)
Bien évidemment, d'autres structures sont possibles ... On peut notamment transférer le code principal du jeu en RAM sur la page 3 et gérer un changement de page sur les slot 1 et 2, ce qui permet d'accéder à plus de données en même temps.
Pour répondre à ta question, les données contenues dans tes pages sont toujours en adressage relatif. Si tes données sont stockées en $1A00 sur ta page, leur adresse sera $1A00 si la page est sur le slot 0, $5A00 si la page est sur le slot 1, $9A00 si la page est sur le slot 2 ...
Dans la structure que je décris au dessus, tu initialise ton programme à partir de la page 1, puis tu gères tes données en les faisant apparaitre au besoin dans la page 2, le temps de les transférer en VRAM par exemple ...
Pour ta dernière question, la question est plutôt philosophique ... 99% des MSX ont leur ports VDP aux mêmes adresses ($98 et $99). Les cas d'incompatibilités connus sont plutôt rares : machines très exotiques, extension MSX2 pour MSX1, ... Or le gain est réellement significatif dans l'accès aux ports VDP si on utilise les valeurs en dur. De plus, on est plus vraiment à l'époque où cela avait une importance commerciale d'être absolument compatible à 100%. La majorité des amateurs MSX actuellement utilisent un émulateur, et ceux qui ont une machine n'ont pas généralement de bidules exotiques ... Tu peux utiliser ces valeurs en dur sans aucun problème.
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)
aoineko :
Je m'y perd un peu au niveau des histoires de slots et de pages.
Pas mieux. Et c'est pas faute de lire et relire les bouquins
Y aurait-il une âme charitable pour reprendre ça euh... tranquillement, dans un autre topic ou dossier ? (je comprends vite mais il faut m'expliquer lentement
).Sinon, j'allais répondre à propos des ports du VDP mais Metalion m'a devancé (et il est plus compétent que moi dans le domaine, tu peux donc lui faire confiance
).MSX un jour, MSX toujours !
La suite de la discussion sur les slots/pages se trouve sur cette page.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie