La Place des Développeurs Projet Carwar
Reprise du message précédent
aoineko :
Comment faire ? Le viewer de VRAM de BlueMSX ne semble pas fonctionner
Si, il fonctionne, je l'ai souvent utilisé.
Re-vérifie ton code, si tu ne vois pas tes données dans le VRAM au bon endroit, c'est que le transfert ne s'est pas fait correctement.
Tu peux poster ton code de transfert des données sprites ?
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 :
Tu peux poster ton code de transfert des données sprites ?
Actuellement, j'ai la version via HMMC. Tu préfères que je rebranche la version avec la série d'otri ? A ce propos, perso je trouve les copies via HMMC plus souple car permettant une copie d'un nombre variables d'octet. En plus, c'est plus rapide, non ?
On est toujours ignorant avant de savoir.
aoineko :
Actuellement, j'ai la version via HMMC. Tu préfères que je rebranche la version avec la série d'otir ?
Peu importe, poste ta dernière version ...
aoineko :
A ce propos, perso je trouve les copies via HMMC plus souple car permettant une copie d'un nombre variables d'octet. En plus, c'est plus rapide, non ?
Plus souple, peut-être, bien que tu puisses paramètrer la série d'OTIR pour arriver exactement au nombre d'octets dont tu as besoin. Mais par contre, c'est plus rapide avec OTIR, car comme le VDP ne travaille pas, il n'y a pas à attendre qu'il soit prêt comme lorsque l'on exécute une macro.
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)
Donc le HMMC n'a aucun avantage ? Puisse que la souplesse relative du HMMC peut aussi se retrouvé avec une boucle variable d'otri, non ?
Je vais poster ma version actuelle à midi, mais ensuite je rebrancherai la copie directe en VRAM. Autant faire mes testes avec la version la plus performante.
Je vais poster ma version actuelle à midi, mais ensuite je rebrancherai la copie directe en VRAM. Autant faire mes testes avec la version la plus performante.
On est toujours ignorant avant de savoir.
Voici les fichiers .rom et .asm (et .lst/.map/.sym au cas ou) : carwar_prb_sprite.zip
Dans le .asm, ma fonction de copie RAM -> VRAM se trouve à _RAMtoVRAM_start.
Ma boucle principale (ou je fais toutes mes init) se trouve à _MainLoop_start.
Mon code de test pour l'initialisation des sprites en C est :
Qui se trouve à la ligne 10115 du .asm. Edité par aoineko Le 02/02/2011 à 12h49
Dans le .asm, ma fonction de copie RAM -> VRAM se trouve à _RAMtoVRAM_start.
Ma boucle principale (ou je fais toutes mes init) se trouve à _MainLoop_start.
Mon code de test pour l'initialisation des sprites en C est :
Code C :
const u8 defaultColor[] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF }; /* ... */ const u8 charTable[] = { 0x7C, 0xEE, 0xEE, 0xEE, 0xEE, 0xEE, 0xEE, 0x7C }; /* ... */ u8 testSprt[4] = { 0x40, 0x40, 0, 0 }; /* ... */ RAMtoVRAM(0, 0, 245, 8, 1, (u16)&defaultColor); // x=0, y=245, addr=F500h ? RAMtoVRAM(0, 0, 247, 3, 1, (u16)&testSprt); // x=0, y=247, addr=F700h ? RAMtoVRAM(0, 0, 248, 8, 1, (u16)&charTable); // x=0, y=248, addr=F800h ?
Qui se trouve à la ligne 10115 du .asm. Edité par aoineko Le 02/02/2011 à 12h49
On est toujours ignorant avant de savoir.
le déplacement des voitures n'est pas bloqué aux 212 lignes de l'écran et on passe dans un écran virtuel de 256 x 256 qui fait de &H0 a &HFFFF
dans ce cas on écrase des zones datas et on modifie les sprites sans le vouloir
il faut tenir compte des 212 lignes maxi et repasser a 0 au lieu de déborder et tout rentrera dans l'ordre
pour voir ce qui se passe actuellement dans la zone 212 a 255 tu peux modifier le registre 23 qui permet un décalage
dans ce cas on écrase des zones datas et on modifie les sprites sans le vouloir
il faut tenir compte des 212 lignes maxi et repasser a 0 au lieu de déborder et tout rentrera dans l'ordre
pour voir ce qui se passe actuellement dans la zone 212 a 255 tu peux modifier le registre 23 qui permet un décalage
Jipe :
le déplacement des voitures n'est pas bloqué aux 212 lignes de l'écran et on passe dans un écran virtuel de 256 x 256 qui fait de &H0 a &HFFFF
dans ce cas on écrase des zones datas et on modifie les sprites sans le vouloir
il faut tenir compte des 212 lignes maxi et repasser a 0 au lieu de déborder et tout rentrera dans l'ordre
pour voir ce qui se passe actuellement dans la zone 212 a 255 tu peux modifier le registre 23 qui permet un décalage
dans ce cas on écrase des zones datas et on modifie les sprites sans le vouloir
il faut tenir compte des 212 lignes maxi et repasser a 0 au lieu de déborder et tout rentrera dans l'ordre
pour voir ce qui se passe actuellement dans la zone 212 a 255 tu peux modifier le registre 23 qui permet un décalage
Oui, je sais que je peux écraser la zone VRAM au delà de (1)D400h avec la voiture, mais pour l'instant c'est pas grave. Ça m'a même permis de trouver qq bugs.
Pour le registre 23, je connaissais pas. J'avais testé à la main de faire mes manipulations dans la partie visible de l'écran en retirant un offset, mais avec ce registre, c'est encore plus simple.
On est toujours ignorant avant de savoir.
aoineko :
Voici les fichiers .rom et .asm (et .lst/.map/.sym au cas ou)
Désolé, aoineko, mais ce code généré par ton compilateur C est complètement imbuvable ...
Et d'ailleurs, le peu que j'ai pu comprendre me semble extrèmement compliqué : il utilise énormément (beaucoup trop) les registres IX, IY, fait beaucoup d'empilage/dépilage de registres et manipule allègrement le registre SP ... Très compliqué et certainement plus lent qu'une programmation directe en assembleur. Mais bon, je peux comprendre la facilité offerte par le langage C ...
Je voudrais t'aider, mais là, ton code est vraiment trop compliqué à décortiquer
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 :
Désolé, aoineko, mais ce code généré par ton compilateur C est complètement imbuvable ...
Et d'ailleurs, le peu que j'ai pu comprendre me semble extrèmement compliqué : il utilise énormément (beaucoup trop) les registres IX, IY, fait beaucoup d'empilage/dépilage de registres et manipule allègrement le registre SP ... Très compliqué et certainement plus lent qu'une programmation directe en assembleur. Mais bon, je peux comprendre la facilité offerte par le langage C ...
Je voudrais t'aider, mais là, ton code est vraiment trop compliqué à décortiquer
aoineko :
Voici les fichiers .rom et .asm (et .lst/.map/.sym au cas ou)
Désolé, aoineko, mais ce code généré par ton compilateur C est complètement imbuvable ...
Et d'ailleurs, le peu que j'ai pu comprendre me semble extrèmement compliqué : il utilise énormément (beaucoup trop) les registres IX, IY, fait beaucoup d'empilage/dépilage de registres et manipule allègrement le registre SP ... Très compliqué et certainement plus lent qu'une programmation directe en assembleur. Mais bon, je peux comprendre la facilité offerte par le langage C ...
Je voudrais t'aider, mais là, ton code est vraiment trop compliqué à décortiquer
Je compte passer le plus possible de code en ASM au fur et à mesure, mais le C, pour prototyper c'est quand même top. En fait le compilateur passe tous les paramètres de la fonction dans la pile. Le premier se retrouve en 4(IX), le second dans 5(ix), etc. C'est clairement pas optimisé comme du vrai ASM, mais bon, c'est pratique pour écrire le corps d'une fonction en assembleur et ça semble suffisamment performant pour ce que j'en fait.
Pour mon problème de sprite hardware, je vais continuer à creuser...
On est toujours ignorant avant de savoir.
Je comprends rien, mais ça marche... 
Comme supposé, la copie de la TGS (forme des sprites) en F800h ne pose pas de problème.
Par contre, pour que mes sprites apparaissent, il faut que je copie ma TAS (table d'attribut) et ma TCS (table de couleur) 256 octets avant l'adresse mise dans les registres du VDP.
Alors soit faut que j'arrête de boire (je bois déjà pas beaucoup) soit y a une couille dans le pâté.
Le code qui marche est :
HMMC de 8 octets (TCS) vers 0,244 ; soit une adresse VRAM de F400h (au lieu de F500h).
HMMC de 3 octets (TAS) vers 0,246 ; soit une adresse VRAM de F600h (au lieu de F700h).
Et mes registres :
Je veux bien avoir un bug de mon coté, mais là, je vois pas du tout.
Et pour BlueMSX, j'ai confirmation que le viewer de VRAM marche pas/mal en mode 8 car actuellement, même si tout marche bien, nul trace de mes couleurs 0x0F que ce soit en F400h qu'en F500h ni nul part entre D400h et 1000h.
Bon, j'ai déjà passé tellement de temps à ça que je pense pas creuser la question d'avantage pour l'instant... passons à la suite.
Comme supposé, la copie de la TGS (forme des sprites) en F800h ne pose pas de problème.
Par contre, pour que mes sprites apparaissent, il faut que je copie ma TAS (table d'attribut) et ma TCS (table de couleur) 256 octets avant l'adresse mise dans les registres du VDP.
Alors soit faut que j'arrête de boire (je bois déjà pas beaucoup
) soit y a une couille dans le pâté.Le code qui marche est :
HMMC de 8 octets (TCS) vers 0,244 ; soit une adresse VRAM de F400h (au lieu de F500h).
HMMC de 3 octets (TAS) vers 0,246 ; soit une adresse VRAM de F600h (au lieu de F700h).
Et mes registres :
| R5 | ee | Partie basse adresse TAS 01EEh pour F700h |
| R6 | 1f | Adresse TGS 001Fh pour F800h |
| R11 | 01 | Partie haute adresse TAS 01EEh pour F700h |
Je veux bien avoir un bug de mon coté, mais là, je vois pas du tout.
Et pour BlueMSX, j'ai confirmation que le viewer de VRAM marche pas/mal en mode 8 car actuellement, même si tout marche bien, nul trace de mes couleurs 0x0F que ce soit en F400h qu'en F500h ni nul part entre D400h et 1000h.
Bon, j'ai déjà passé tellement de temps à ça que je pense pas creuser la question d'avantage pour l'instant... passons à la suite.
On est toujours ignorant avant de savoir.
Il y a donc une erreur quelque part dans ta routine de transfert en VRAM, elle doit certainement envoiyer les données 256 octets trop tôt dans la VRAM, car les registres sont correctement initialisés.
Je vais regarder pour le viewer VRAM de BlueMSX, car je n'ai jamais eu de problème avec cette partie du débuggeur.
Je vais regarder pour le viewer VRAM de BlueMSX, car je n'ai jamais eu de problème avec cette partie du débuggeur.
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 :
Il y a donc une erreur quelque part dans ta routine de transfert en VRAM, elle doit certainement envoiyer les données 256 octets trop tôt dans la VRAM, car les registres sont correctement initialisés.
Je vais regarder pour le viewer VRAM de BlueMSX, car je n'ai jamais eu de problème avec cette partie du débuggeur.
Je vais regarder pour le viewer VRAM de BlueMSX, car je n'ai jamais eu de problème avec cette partie du débuggeur.
Je vois vraiment pas pourquoi ma routine HMMC marcherait sans problème pour la TGS ou pour les blocs contenants les voitures et pas pour la TAS...
C'est pas plutôt que l'adresse de la TAS qui doit être multiple de 200h ou un truc comme ça ?
Ce midi, j'essayerai avec des valeurs pour la TAS :
| R5 | EC | Partie basse adresse TAS 01ECh pour F600h |
| R11 | 01 | Partie haute adresse TAS 01ECh pour F600h |
EDIT : Bon, ça ne marche pas en mettant l'adresse de la TAS à F600h ; la ou je fais ma copie. Je comprends vraiment rien.
Edité par
aoineko
Le 03/02/2011 à 11h04
On est toujours ignorant avant de savoir.
Ça y est ; j'ai enfin fini avec mon système d'affichage : à chaque frame, je reconstitue le terrain avec les morceaux sauvegardés (2 frames avant) dans un coin de la VRAM, puis je re-sauvegarde la ou je vais dessiner, et enfin, je dessine.
Le fond psychédélique, c'est juste pour les tests.
J'ai ralenti les voitures pour qu'elles soient jouables ; d'ailleurs, j'ai commencé à implémenter les caractéristiques de chaque voiture.
Si quelqu'un peut tester sur un vrai MSX, ça serait cool : Carwar v0.0.3
D'ailleurs, normalement je me synchronise avec le balayage vertical donc ça devrait tourner à la même vitesse même sur un TurboR.
Le fond psychédélique, c'est juste pour les tests.
J'ai ralenti les voitures pour qu'elles soient jouables ; d'ailleurs, j'ai commencé à implémenter les caractéristiques de chaque voiture.
Si quelqu'un peut tester sur un vrai MSX, ça serait cool : Carwar v0.0.3
D'ailleurs, normalement je me synchronise avec le balayage vertical donc ça devrait tourner à la même vitesse même sur un TurboR.
On est toujours ignorant avant de savoir.
j'ai essayé dans mon turbo-r
avec odo -> écran noir
dans la flashrom -> écran noir
dans la mega-sram scc -> écran noir
dans ça ne marche vraiment pas sur une vraie machine
par contre j'ai vu dans BlueMSX que tu maitrisais bien les sprites multicolores maintenant
avec odo -> écran noir
dans la flashrom -> écran noir
dans la mega-sram scc -> écran noir
dans ça ne marche vraiment pas sur une vraie machine
par contre j'ai vu dans BlueMSX que tu maitrisais bien les sprites multicolores maintenant
Jipe :
donc ça ne marche vraiment pas sur une vraie machine
Aie !!
Une idée du genre de chose qui fait que ça marche sur BlueMSX et pas un vrai MSX ?
Faut vraiment que je récupère un ordi pour pouvoir tester au fur et à mesure sinon ça va être de plus en plus difficile d'assurer la compatibilité.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie