La Place des Développeurs Projet Carwar
Bien vu Guil'
Je suis perplexe, je ne comprends pas ce qui ne fonctionne pas dans ce petit programme (pour tester les collisions en page 1).
Les valeurs &h7XXX sont pour les sprites en page0, Les valeurs en &hFXXX pour les sprite en page1 ( &h7XXX+&h8XXX=&HFxxx)
D'une part la génération de sprite en page 1 ne fonctionne pas
(alors qu'on allume facilement un point en page1 par un vpoke&h8111,15)
D'autre part les sprites s'affichent en blanc alors que je leurs alloue une couleur (Jaune et rouge)
Que n'ai-je point compris, y a-t-il une limite provoqué par le MSX Basic, le colonel Moutarde a-t-il tué le Professeur Violet avec le chandelier dans la bibliothèque
Vous le saurez en suivant nos prochain posts! 
OUF! J'ai bien failli oublié d'envoyer le code avec toutes ces âneries! 
Les valeurs &h7XXX sont pour les sprites en page0, Les valeurs en &hFXXX pour les sprite en page1 ( &h7XXX+&h8XXX=&HFxxx)
D'une part la génération de sprite en page 1 ne fonctionne pas
(alors qu'on allume facilement un point en page1 par un vpoke&h8111,15) D'autre part les sprites s'affichent en blanc alors que je leurs alloue une couleur (Jaune et rouge)
Que n'ai-je point compris, y a-t-il une limite provoqué par le MSX Basic, le colonel Moutarde a-t-il tué le Professeur Violet avec le chandelier dans la bibliothèque
Vous le saurez en suivant nos prochain posts! Code BASIC :
10 SCREEN 5,1:SETPAGE0,0:CLS:'OPEN"grp:"FOROUTPUTAS#1 12 DEFINT A-Z 15 ONSPRITE GOSUB600 20 FORI=&H7800TO&H7807:VPOKEI,255:NEXT 30 FORI=&HF800TO&HF807:VPOKEI,255:NEXT 40 FORI=&H7600TO&H7607:READL:VPOKEI,L:NEXT 50 FORI=&HF600TO&HF607:READL:VPOKEI,L:NEXT 56 'SETPAGE1,1 57 FORI=&H7800TO&H7807:VPOKEI,255:NEXT 60 FORI=0TO240 70 VPOKE&H7601,I:VPOKE&H7605,240-I 80 VPOKE&HF601,I:VPOKE&HF605,240-I 90 SPRITE ON 100 NEXT 200 GOTO 200 500 DATA 50,0,0,8,80,240,0,10 510 DATA 50,0,0,8,50,240,0,10 600 SPRITEOFF:BEEP:RETURN
OUF! J'ai bien failli oublié d'envoyer le code avec toutes ces âneries!
Le MSXien le plus à l'ouest
... ou presque 
Pourriez vous juste me confirmer que switcher les pages mémoires est assez léger pour pouvoir en faire une dizaine par frame ?
(pour les sprites en page 1, j'essayerai en C après avoir fini la gestion des 2 pages graphiques)
(pour les sprites en page 1, j'essayerai en C après avoir fini la gestion des 2 pages graphiques)
On est toujours ignorant avant de savoir.
Je ne comprends pas la structure mémoire de ton jeu
Si c'est une ROM 32Ko, d'ou viennent les 64Ko de données graphique ? D'une disquette ? D'une décompression à partir de la ROM ?
Je ne sais pas si on peut switcher plusieurs fois par frame les banks (je suppose que oui), mais ce qui est sur, c'est que :
1. Si tout l'espace mémoire du Z80 est occupé par des données graphiques ... Où est ton code ? Au moment ou tu vas switcher, le Z80 va poursuivre l'exécution commencée en incrémentant le registre PC, et il va aller chercher une instruction au beau milieu de tes données graphiques : plantage !!!
2. Transférer 64Ko de la RAM vers la VRAM prends beaucoup de temps. Pour info, l'instruction HMMM, qui est une instruction rapide, vu qu'elle ne travaille que sur la VRAM, transfère environ 3600 octets par frame (par 50e de seconde). Imaginons qu'avec HMMC, on descende à 2400 octets/50e de seconde, transférer 64Ko va te prendre 27 frames, soit un peu plus d'une demi-seconde (ce n'est qu'une estimation). Impossible dans ces conditions de le faire plusieurs fois par frame.
3. Tu peux mettre de la RAM en page 0 si tu n'utilises pas le BIOS mais il ne faut pas oublier que la gestion des interruptions se fait dans le BIOS. Donc, soit tu interdit les interruptions pendant que tu as de la RAM en page 0, mais alors tu perds la possibilité d'utilser le hook H.TIMI, soit tu écris ta propre routine de gestion en $0038, mais tu devras alors gérer une alternance entre ta routine d'interruption (quand tu switches la RAM) et celle du BIOS (quand tu switches la ROM). Plutôt casse-tête, sans compter que tu pers alors un peu d'espace pour tes données graphiques dans la page 0.
Je pense qu'il faut que tu sois plus réaliste sur le mode graphique : le SCREEN 8 est beaucoup trop gourmand en mémoire pour être utilisé dans un double buffering graphique. Il vaut mieux se rabattre sur un mode graphique moins gourmand (SCREEN 5 est généralement un bon compromis), ou alors définir une fenêtre graphique plus réduite (voire même les 2).
Pour gagner en vitesse, il faut absolument que toutes tes données graphiques soit chargées en VRAM à l'initialisation du programme, et que tu n'aies plus ensuite qu'à les manipuler dans la VRAM avec les macro du VDP. D'où l'intérêt d'utiliser un mode graphique qui t'offre plus que 2 pages ...
Si c'est une ROM 32Ko, d'ou viennent les 64Ko de données graphique ? D'une disquette ? D'une décompression à partir de la ROM ?
Je ne sais pas si on peut switcher plusieurs fois par frame les banks (je suppose que oui), mais ce qui est sur, c'est que :
1. Si tout l'espace mémoire du Z80 est occupé par des données graphiques ... Où est ton code ? Au moment ou tu vas switcher, le Z80 va poursuivre l'exécution commencée en incrémentant le registre PC, et il va aller chercher une instruction au beau milieu de tes données graphiques : plantage !!!
2. Transférer 64Ko de la RAM vers la VRAM prends beaucoup de temps. Pour info, l'instruction HMMM, qui est une instruction rapide, vu qu'elle ne travaille que sur la VRAM, transfère environ 3600 octets par frame (par 50e de seconde). Imaginons qu'avec HMMC, on descende à 2400 octets/50e de seconde, transférer 64Ko va te prendre 27 frames, soit un peu plus d'une demi-seconde (ce n'est qu'une estimation). Impossible dans ces conditions de le faire plusieurs fois par frame.
3. Tu peux mettre de la RAM en page 0 si tu n'utilises pas le BIOS mais il ne faut pas oublier que la gestion des interruptions se fait dans le BIOS. Donc, soit tu interdit les interruptions pendant que tu as de la RAM en page 0, mais alors tu perds la possibilité d'utilser le hook H.TIMI, soit tu écris ta propre routine de gestion en $0038, mais tu devras alors gérer une alternance entre ta routine d'interruption (quand tu switches la RAM) et celle du BIOS (quand tu switches la ROM). Plutôt casse-tête, sans compter que tu pers alors un peu d'espace pour tes données graphiques dans la page 0.
Je pense qu'il faut que tu sois plus réaliste sur le mode graphique : le SCREEN 8 est beaucoup trop gourmand en mémoire pour être utilisé dans un double buffering graphique. Il vaut mieux se rabattre sur un mode graphique moins gourmand (SCREEN 5 est généralement un bon compromis), ou alors définir une fenêtre graphique plus réduite (voire même les 2).
Pour gagner en vitesse, il faut absolument que toutes tes données graphiques soit chargées en VRAM à l'initialisation du programme, et que tu n'aies plus ensuite qu'à les manipuler dans la VRAM avec les macro du VDP. D'où l'intérêt d'utiliser un mode graphique qui t'offre plus que 2 pages ...
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)
Les voitures prennent 13(largeur) x 11(hauteur) x 16(étape de rotation) x 4(nombre de voiture) = environs 9Ko. Les circuits seront fait par assemblage de blocs 16x16 compressé (4 bits) et ré-orientable (un virage ne sera en mémoire qu'une seule fois). Imaginons que j'ai 32 blocs, cela fait 16(largeur) x 16(hauteur) x 0.5(compression) x 32(nombre de block) = 4Ko. Du coup, je pense que cela peut rentrer sans problème dans les 32 Ko d'une cartouche.
Pour ce qui est des performances, une fois que le fond de mon circuit est en RAM, je n'ai besoin d'effacer que 4 blocs de 13x11 avec le fond à l'ancienne place de mes voitures, puis ré-afficher mes 4 blocs de 13x11 à leur nouvelle place.
Reste le problème de la perte du code au moment du switch... ça m'avait complètement échappé.
Du coup, j'imagine une architecture du genre :
En temps normal :
Au moment d'effacer mes sprites avec la partie haute du décors, je switcherai sur :
Et au moment d'effacer mes sprites avec la partie basse du décors, je switcherai sur :
Comme ça, j'ai toujours le code et mes informations gameplay en mémoire et ça m'oblige juste à faire l'effacement en 2 fois pour les sprites à cheval sur la partie haute et la partie basse de l'écran. Donc au pire, si les 4 voitures sont en mouvement et à cheval sur la moitié de l'écran, ça fait 8 HMMC pour effacer avec le fond et 4 pour réafficher les voitures.
EDIT : Ceci dit, si je n'utilise pas les sprites, il me reste 44*256 pixel libre en bas de chacune des 2 pages graphiques, non ? Si je peux les utiliser librement (?) ça me permettrait d'y stocker mes sprites pour accélérer leur affichage. Edité par aoineko Le 26/01/2011 à 10h08
Pour ce qui est des performances, une fois que le fond de mon circuit est en RAM, je n'ai besoin d'effacer que 4 blocs de 13x11 avec le fond à l'ancienne place de mes voitures, puis ré-afficher mes 4 blocs de 13x11 à leur nouvelle place.
Reste le problème de la perte du code au moment du switch... ça m'avait complètement échappé.
Du coup, j'imagine une architecture du genre :
En temps normal :
Page 0 : [Slot 0-0 - BIOS]
Page 1 : [Slot 1-0 - ROM] // Point d'entrée du code (qui jump direct en page 2) et données
Page 2 : [Slot 1-0 - ROM] // Code et données
Page 3 : [Slot 3-1 - RAM] // Informations gameplay (position voiture, temps, etc.)
Page 1 : [Slot 1-0 - ROM] // Point d'entrée du code (qui jump direct en page 2) et données
Page 2 : [Slot 1-0 - ROM] // Code et données
Page 3 : [Slot 3-1 - RAM] // Informations gameplay (position voiture, temps, etc.)
Au moment d'effacer mes sprites avec la partie haute du décors, je switcherai sur :
Page 0 : [Slot 3-1 - RAM] // Partie haute...
Page 1 : [Slot 3-1 - RAM] // ... du circuit
Page 2 : [Slot 1-0 - ROM] // Code et données
Page 3 : [Slot 3-1 - RAM] // Informations gameplay (position voiture, temps, etc.)
Page 1 : [Slot 3-1 - RAM] // ... du circuit
Page 2 : [Slot 1-0 - ROM] // Code et données
Page 3 : [Slot 3-1 - RAM] // Informations gameplay (position voiture, temps, etc.)
Et au moment d'effacer mes sprites avec la partie basse du décors, je switcherai sur :
Page 0 : [Slot 3-2 - RAM] // Partie basse...
Page 1 : [Slot 3-2 - RAM] // ... du circuit
Page 2 : [Slot 1-0 - ROM] // Code et données
Page 3 : [Slot 3-1 - RAM] // Informations gameplay (position voiture, temps, etc.)
Page 1 : [Slot 3-2 - RAM] // ... du circuit
Page 2 : [Slot 1-0 - ROM] // Code et données
Page 3 : [Slot 3-1 - RAM] // Informations gameplay (position voiture, temps, etc.)
Comme ça, j'ai toujours le code et mes informations gameplay en mémoire et ça m'oblige juste à faire l'effacement en 2 fois pour les sprites à cheval sur la partie haute et la partie basse de l'écran. Donc au pire, si les 4 voitures sont en mouvement et à cheval sur la moitié de l'écran, ça fait 8 HMMC pour effacer avec le fond et 4 pour réafficher les voitures.
EDIT : Ceci dit, si je n'utilise pas les sprites, il me reste 44*256 pixel libre en bas de chacune des 2 pages graphiques, non ? Si je peux les utiliser librement (?) ça me permettrait d'y stocker mes sprites pour accélérer leur affichage. Edité par aoineko Le 26/01/2011 à 10h08
On est toujours ignorant avant de savoir.
Aoineko ... Ce n'est pas encore suffisamment clair pour pouvoir te répondre sur la faisabilité 
Je voudrais comprendre ta gestion graphique, est-ce que tu pourrais la détailler (étape par étape) ?
Est-ce que tu recopies tout le fond d'écran (64Ko) à chaque fois que tes sprites bougent ?
Ou est-ce que tu ne recopies que le rectangle dans lequel le sprite a bougé ?
Je persiste et j'insiste : la meilleure solution (et de loin), c'est d'avoir toutes les données en VRAM et de ne plus avoir à les manipuler qu'à travers des macro du VDP opérant directement sur la VRAM. Et le meilleur mode graphique, le plus flexible et celui qui permet d'avoir plus d'espace en VRAM, c'est le mode SCREEN 5.
PS : Et ta division du switch vers la RAM en 2 parties ne résoud toujours pas le problème posé par la routine de gestion des interruptions. Soit tu interdit les interruptions pendant ce switch, soit tu vas devoir les gérer toi même.
Je voudrais comprendre ta gestion graphique, est-ce que tu pourrais la détailler (étape par étape) ?
Est-ce que tu recopies tout le fond d'écran (64Ko) à chaque fois que tes sprites bougent ?
Ou est-ce que tu ne recopies que le rectangle dans lequel le sprite a bougé ?
Je persiste et j'insiste : la meilleure solution (et de loin), c'est d'avoir toutes les données en VRAM et de ne plus avoir à les manipuler qu'à travers des macro du VDP opérant directement sur la VRAM. Et le meilleur mode graphique, le plus flexible et celui qui permet d'avoir plus d'espace en VRAM, c'est le mode SCREEN 5.
PS : Et ta division du switch vers la RAM en 2 parties ne résoud toujours pas le problème posé par la routine de gestion des interruptions. Soit tu interdit les interruptions pendant ce switch, soit tu vas devoir les gérer toi mê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)
Metalion :
Je voudrais comprendre ta gestion graphique, est-ce que tu pourrais la détailler (étape par étape) ?
Est-ce que tu recopies tout le fond d'écran (64Ko) à chaque fois que tes sprites bougent ?
Ou est-ce que tu ne recopies que le rectangle dans lequel le sprite a bougé ?
Est-ce que tu recopies tout le fond d'écran (64Ko) à chaque fois que tes sprites bougent ?
Ou est-ce que tu ne recopies que le rectangle dans lequel le sprite a bougé ?
Ok, allons y étape par étape :
Imaginons que j'ai déjà le fond de mon circuit en RAM dans les 2 premières pages des slots 3-1 (partie haute) et 3-2 (partie basse).
- Switcher la page courante
- Effacer les voitures à leur position de la frame N-2 (puisse que le nouvel écran de travail représente l'état du jeu il y a 2 frames de cela).
- Pour chaque voiture, détecter dans quelle partie de l'écran elle se trouve ou si elle se trouve à l'intersection du haut et du bas
- Si elle se trouve dans une seule partie, sélectionner les pages mémoires 0 et 1 correspondantes (désactiver les interruptions), faire un HMMC de 13*11 pixels du circuit en RAM vers la position en VRAM, puis reseter les pages mémoires (reactiver les interruptions).
- Si elle se trouve à cheval entre les deux zones, faire le même traitement que ci-dessus, mais en 2 fois : une pour la partie du sprite se trouvant dans la partie haut du circuit et une autre pour la partie basse. La somme des 2 HMMC équivaudra à un transfert de 13*11 pixels.
- Afficher les voitures via un LMMC (ou LMMM si je peux mettre les voitures qq part en VRAM)
- Attendre la synchronisation verticale
Est-ce plus clair ?
On est toujours ignorant avant de savoir.
Oui, c'est plus clair
Donc, pour chaque voiture (et je ne sais pas combien il y en a), tu auras besoin d'un transfert de 2x13x11 pixels, soit 286 octets.
Cela passera largement dans une frame, donc c'est réalisable.
Donc, pour chaque voiture (et je ne sais pas combien il y en a), tu auras besoin d'un transfert de 2x13x11 pixels, soit 286 octets.
Cela passera largement dans une frame, donc c'est réalisable.
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)
En fait ça marche déjà presque. 
Voici une version avec les 4 voitures, dont 2 sont jouables : carwar v0.0.1
Ça utilise le switch entre les 2 pages graphiques.
Le premier joueur utilise les touches gauche/droite pour tourner et haut pour accélérer.
Le deuxième joueur utilise les touches (en QWERTY) Z/C pour tourner et X pour accélérer.
Sur MSXBlue, ça ne marche pas très bien à cause de la limitation du nombre de touche en simultané.
Quelqu'un peut me confirmer que ça marche sur un vrai MSX ?
Prochaine mission... le décors et les collisions.
EDIT : Les 2 autres joueurs seront jouables à la manette. Edité par aoineko Le 27/01/2011 à 14h23
Voici une version avec les 4 voitures, dont 2 sont jouables : carwar v0.0.1
Ça utilise le switch entre les 2 pages graphiques.
Le premier joueur utilise les touches gauche/droite pour tourner et haut pour accélérer.
Le deuxième joueur utilise les touches (en QWERTY) Z/C pour tourner et X pour accélérer.
Sur MSXBlue, ça ne marche pas très bien à cause de la limitation du nombre de touche en simultané.
Quelqu'un peut me confirmer que ça marche sur un vrai MSX ?
Prochaine mission... le décors et les collisions.
EDIT : Les 2 autres joueurs seront jouables à la manette. Edité par aoineko Le 27/01/2011 à 14h23
On est toujours ignorant avant de savoir.
Content que ça plaise. C'est aussi grâce à vous.
J'ai deux p'tites questions pour les spécialistes :
1. Est t'il plus intéressant de faire 1 seul LMMC (copie RAM->VRAM avec gestion de transparence) de 13x11 ou bien 11 HMMC (un par ligne ; sans gestion de transparence) ? En fait, quel est le coup des tests logiques faits par les instructions de type LMxx par rapport aux versions High Speed ?
2. Comment accéder à l'espace mémoire situé hors des deux pages graphiques via les commandes VDP ? Par exemple, dans la page 1, les zones 0xC000-0xEFFF et 0xFA80-0xFFFF (autour de la zone alloué au sprite). D'ailleurs, peut t'on désactiver la gestion des sprites pour utiliser librement tout l'espace 0xC000-0xFFFF ?
Effectivement, ça pourrait être cool. Par contre, j'espère que la prochaine convention est pas avant qq mois... y a encore beaucoup de boulot.
Edité par
aoineko
Le 27/01/2011 à 23h59
J'ai deux p'tites questions pour les spécialistes :
1. Est t'il plus intéressant de faire 1 seul LMMC (copie RAM->VRAM avec gestion de transparence) de 13x11 ou bien 11 HMMC (un par ligne ; sans gestion de transparence) ? En fait, quel est le coup des tests logiques faits par les instructions de type LMxx par rapport aux versions High Speed ?
2. Comment accéder à l'espace mémoire situé hors des deux pages graphiques via les commandes VDP ? Par exemple, dans la page 1, les zones 0xC000-0xEFFF et 0xFA80-0xFFFF (autour de la zone alloué au sprite). D'ailleurs, peut t'on désactiver la gestion des sprites pour utiliser librement tout l'espace 0xC000-0xFFFF ?
MSXosaure :
Une fois fini ça pourrait faire l'objet d'un beau concours/défi/tournoi pour la prochaine convention 
Effectivement, ça pourrait être cool. Par contre, j'espère que la prochaine convention est pas avant qq mois... y a encore beaucoup de boulot.
Edité par
aoineko
Le 27/01/2011 à 23h59
On est toujours ignorant avant de savoir.
Aoineko !!! Tu avales du R800 effervescent lorsque tu codes ?? Whaouaouaou !! Qu'est-ce que tu nous fais-là ? C'est impressionnant !
Je rêve d'un Supersprint !!! Trop fort ! Je revoie Motoraoder, c'est GENIAL !
En plus tu pourrais le décliner en BMX simulator aussi...
Bravo Aoineko !
Sur MSX, ça tourne nikel et sur Turbo-R je m'entraine en crazy mode !
Guil'
Je viens de penser à un truc... J'ai pas besoin d'avoir mon circuit en RAM !
Il suffit que je fasse un backup des 4 zones de 13x11 ou je vais afficher ma voiture (que je pourrais surement stocker qq part dans la VRAM) puis d'utiliser ces blocks pour effacer mes voitures la prochaine fois. A cause de l'affichage sur 2 pages graphiques, j'aurai besoin de tout stocker en double, mais 8x13x11 (1144 octets), ça doit rentrer sans problème dans les espaces inoccupés de la VRAM. Reste plus qu'à trouver comment accéder à ces zones.
Merci ! Par contre, je suis étonné que tu ais encore le Crazy Mode sur Turbo-R vu que normalement j'attends la fin du balayage vertical avant de dessiner une nouvelle image... ça devrait pas aller plus vite. A moins qu'on soit à 60fps sur Turbo-R et seulement à 30 sur MSX2. Edité par aoineko Le 28/01/2011 à 01h01
Il suffit que je fasse un backup des 4 zones de 13x11 ou je vais afficher ma voiture (que je pourrais surement stocker qq part dans la VRAM) puis d'utiliser ces blocks pour effacer mes voitures la prochaine fois. A cause de l'affichage sur 2 pages graphiques, j'aurai besoin de tout stocker en double, mais 8x13x11 (1144 octets), ça doit rentrer sans problème dans les espaces inoccupés de la VRAM. Reste plus qu'à trouver comment accéder à ces zones.
GuillianSeed :
Sur MSX, ça tourne nikel et sur Turbo-R je m'entraine en crazy mode !
Merci ! Par contre, je suis étonné que tu ais encore le Crazy Mode sur Turbo-R vu que normalement j'attends la fin du balayage vertical avant de dessiner une nouvelle image... ça devrait pas aller plus vite. A moins qu'on soit à 60fps sur Turbo-R et seulement à 30 sur MSX2. Edité par aoineko Le 28/01/2011 à 01h01
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie