La Place des Développeurs MSX2 Screen5 test Test en assembleur du VDP en mode SCREEN5
Merci pour les tests 
Oui tu à raison d'une certaine manière il y a un décor
Je vais me pencher d'un peu plus près sur la synchronisation de l'affichage il y a peut être quelque chose que je n'ai pas compris/lut dans les docs ....
J'ai utilisé le classique
J'ai aussi essayé avec le Status register 2 mais même comportement.
Oui tu à raison d'une certaine manière il y a un décor
Je vais me pencher d'un peu plus près sur la synchronisation de l'affichage il y a peut être quelque chose que je n'ai pas compris/lut dans les docs ....
J'ai utilisé le classique
Code :
S#O = Status register 0 == | F | 5S | C | ! ! ! ! |
F: Vertical scanning interrupt flag When S#O is read, this flag is reset.
J'ai aussi essayé avec le Status register 2 mais même comportement.
Code :
S#2 = Status register 2 == | TR | VR | HR | BD | 1 | 1 | E0 | CE|
VR: Vertical scanning line timing flag During vertical scanning, this flag is set to 1.
De ma propre expérience (en Basic), si tu veux éviter le phénomène de "clipping" lors de l'affichage du "Speudo-Sprite", il faut ajouter une "étape" entre le départ et la destination...
Schématiquement:
1) Je copie le "fond d'écran" depuis la source vers la page de travail. (le fond d'écran est donc cloné)
2) Je copie le "Héro" depuis la source vers la page de travail. (par dessus le clone du fond d'écran)
3) Je copie le "résulta final" (qui contient le Fond d'écran cloné par dessus lequel à été cloné le Héro) depuis la page de travail vers la page Visible.
4) Le "Fond d'écran + Héro" apparaissent sans clipping sur la page visible.
Si tu sautes l'étape qui consiste à copier le "Fond d'écran + le Héro" sur une page non visible pour ensuite copier le tout vers une page visible, tu auras un clipping systématique.
C'est frustrant parce que cela ajoute une étape au processus et ralenti beaucoup le résulta final.
De mes expériences, il est possible d'éviter le clipping sans avoir à passer par l'étape 2 en jouant d'astuces dont voici le principe:
Pour cela, il faut se poser la question suivante:
L'affichage de deux choses différentes au même "endroit" génère un clipping!
Le clipping est donc du à "l'affichage alternatif" du fond d'écran et du Héro.
La solution consiste donc à ne pas copier le fond d'écran par dessus le Héro pour se débarrasser du clipping et donc gagner une étape
Cela pose donc un problème suivant => Si je ne recouvre pas le héro sous une couche de "fond d'écran", et que j'affiche la phase suivante de l'animation du héro, je vais me retrouver avec une superposition de phases différentes du héro qui au final va faire un truc dégueulasse
Il faut donc répondre à deux problèmes!
1) Ne pas afficher alternativement "Fond d'écran par dessus héro" puis "héro par dessus fond d'écran" etc...
2) Effacer "la phase précédente de l'animation du héro" présent sur la page visible.
Tout d'abord voici la solution en images:
Attendez avant de dire ...Euh...ca clippe... lol
En fait, j'ai travaillé sur fond Bleu avec un carré délimitant pour faciliter mes expérimentations mais ...Evidemment, il faut appliquer la transparence pour se retrouver avec un résulta plus qu'acceptable
Pour en arriver là, j'ai procéder comme suit:
Nous partons du principe ou le héro faite "16 X 16" pixels et se déplace par "Pas" de 4 pixels:
Prérequis:
A) Page 0 contient le Background Alpha
B) Page 1 contient le Background Beta (clone complet de la page 0 en page 1)
C) Page 2 contient les phases différentes du Héro.
Voici le processus pour un déplacement vers la droite: (le héro se trouve aux coordonnées suivantes => X=100, Y=60)
_Copier la Phase 1 du héro en page visible "ZERO" aux coordonnées X, Y. (le héro couvre donc les pixels X=>100 à 115 et Y=60 à 75)
Le héro se déplaçant vers la droite, il va générer du "déchet à sa gauche"!
_Copier le BackGround de la page 1 pour couvrir le déchet (futur) présent sur la page 0. (copier des X-4 jusqu'à X et de Y à Y+16 depuis la page 1 vers la page 0)
_J'incrémente X: (sachant que le pas est de 4 pixels)
X=X+4
Voici dont la boucle:
10 Copier la nouvelle phase du Héro vers la page 0 (le héro va donc s'afficher par dessus le décors ALPHA 4 pixels à droite de la phase précédente)
20 Copier le Background Beta de la page 1 vers la page 0 depuis X-4 jusqu'à X pour supprimer le déchet à venir sur la page 0.
30 X=X+4 : GOTO 10
Cela permet d'économiser énormément de ressources
Evidemment, il faut adapter le principe pour direction à gauche, en haut en bas etc...
Le processus devrait être tellement économe qu'on pourrait supprimer la page "Background Béta" en la remplacant par une copie supplémentaire du "background alpha" à mesure des déplacements du héros simplement en anticipant le mouvement du héro.
Pour cela, il suffit de "buffériser en temps réel", la partie se trouvant à droite du héro si ce dernier va à droite...La partie gauche si il va à gauche etc etc...
Schématiquement:
1) Je copie le "fond d'écran" depuis la source vers la page de travail. (le fond d'écran est donc cloné)
2) Je copie le "Héro" depuis la source vers la page de travail. (par dessus le clone du fond d'écran)
3) Je copie le "résulta final" (qui contient le Fond d'écran cloné par dessus lequel à été cloné le Héro) depuis la page de travail vers la page Visible.
4) Le "Fond d'écran + Héro" apparaissent sans clipping sur la page visible.
Si tu sautes l'étape qui consiste à copier le "Fond d'écran + le Héro" sur une page non visible pour ensuite copier le tout vers une page visible, tu auras un clipping systématique.
C'est frustrant parce que cela ajoute une étape au processus et ralenti beaucoup le résulta final.
De mes expériences, il est possible d'éviter le clipping sans avoir à passer par l'étape 2 en jouant d'astuces dont voici le principe:
Pour cela, il faut se poser la question suivante:
L'affichage de deux choses différentes au même "endroit" génère un clipping!
Le clipping est donc du à "l'affichage alternatif" du fond d'écran et du Héro.
La solution consiste donc à ne pas copier le fond d'écran par dessus le Héro pour se débarrasser du clipping et donc gagner une étape
Cela pose donc un problème suivant => Si je ne recouvre pas le héro sous une couche de "fond d'écran", et que j'affiche la phase suivante de l'animation du héro, je vais me retrouver avec une superposition de phases différentes du héro qui au final va faire un truc dégueulasse
Il faut donc répondre à deux problèmes!
1) Ne pas afficher alternativement "Fond d'écran par dessus héro" puis "héro par dessus fond d'écran" etc...
2) Effacer "la phase précédente de l'animation du héro" présent sur la page visible.
Tout d'abord voici la solution en images:
Attendez avant de dire ...Euh...ca clippe... lol
En fait, j'ai travaillé sur fond Bleu avec un carré délimitant pour faciliter mes expérimentations mais ...Evidemment, il faut appliquer la transparence pour se retrouver avec un résulta plus qu'acceptable
Pour en arriver là, j'ai procéder comme suit:
Nous partons du principe ou le héro faite "16 X 16" pixels et se déplace par "Pas" de 4 pixels:
Prérequis:
A) Page 0 contient le Background Alpha
B) Page 1 contient le Background Beta (clone complet de la page 0 en page 1)
C) Page 2 contient les phases différentes du Héro.
Voici le processus pour un déplacement vers la droite: (le héro se trouve aux coordonnées suivantes => X=100, Y=60)
_Copier la Phase 1 du héro en page visible "ZERO" aux coordonnées X, Y. (le héro couvre donc les pixels X=>100 à 115 et Y=60 à 75)
Le héro se déplaçant vers la droite, il va générer du "déchet à sa gauche"!
_Copier le BackGround de la page 1 pour couvrir le déchet (futur) présent sur la page 0. (copier des X-4 jusqu'à X et de Y à Y+16 depuis la page 1 vers la page 0)
_J'incrémente X: (sachant que le pas est de 4 pixels)
X=X+4
Voici dont la boucle:
10 Copier la nouvelle phase du Héro vers la page 0 (le héro va donc s'afficher par dessus le décors ALPHA 4 pixels à droite de la phase précédente)
20 Copier le Background Beta de la page 1 vers la page 0 depuis X-4 jusqu'à X pour supprimer le déchet à venir sur la page 0.
30 X=X+4 : GOTO 10
Cela permet d'économiser énormément de ressources
Evidemment, il faut adapter le principe pour direction à gauche, en haut en bas etc...
Le processus devrait être tellement économe qu'on pourrait supprimer la page "Background Béta" en la remplacant par une copie supplémentaire du "background alpha" à mesure des déplacements du héros simplement en anticipant le mouvement du héro.
Pour cela, il suffit de "buffériser en temps réel", la partie se trouvant à droite du héro si ce dernier va à droite...La partie gauche si il va à gauche etc etc...
@Igal: Justement je n'ai volontairement pas utilisé de buffer pour voir ce que je pouvais faire avec le VDP, maintenant que je connais un peu mieux les limites de ce VDP, si on veux utiliser des grand "sprites" il faut utiliser un buffer ou swapping entre 2 pages, mais du coup on perd 1 page de VRAM 
L'idée est d'avoir 1 page pour l'affichage 1 pages pour le/les persos et 2 pages pour les décors par exemple, mais pour l'instant aucun projet précis juste des expérimentations du VDP des MSX2.
@Jipe: excellent pour du Basic, tu pourrais le finaliser et en faire un jeu en rajoutant des objets et/ou ennemis
Qu'est ce que ce X-Basic à de plus par rapport au basic d'origine du MSX2 ?
Dès que j'ai un peu de temps je fait un test plus poussé avec des persos plus petits et un décor qui défile pour voir ce que j'arrive à faire sur MSX2 ...
Edité par 6502man Le 19/07/2018 à 17h55
L'idée est d'avoir 1 page pour l'affichage 1 pages pour le/les persos et 2 pages pour les décors par exemple, mais pour l'instant aucun projet précis juste des expérimentations du VDP des MSX2.
@Jipe: excellent pour du Basic
, tu pourrais le finaliser et en faire un jeu en rajoutant des objets et/ou ennemis Qu'est ce que ce X-Basic à de plus par rapport au basic d'origine du MSX2 ?
Dès que j'ai un peu de temps je fait un test plus poussé avec des persos plus petits et un décor qui défile pour voir ce que j'arrive à faire sur MSX2 ...
Edité par 6502man Le 19/07/2018 à 17h55
c'est un compilateur en temps réel
la notice en anglais est ici avec le programme
https://www.msx.org/downloads/utilities/miscellaneous/x-basic-tutorial
la notice en anglais est ici avec le programme
https://www.msx.org/downloads/utilities/miscellaneous/x-basic-tutorial
7zip n'arrive pas à décompresser l'archive X-basic 
Tu dit que c'est un compilateur temps réel, le Basic d'origine est un langage interprété ce qui fait ca lenteur contrairement au langages compilés Assembleur, C, ...
La même démo que tu à faite en X-Basic donnerais quoi en Basic MSX2 standard (en terme de vitesse) ?
Tu dit que c'est un compilateur temps réel, le Basic d'origine est un langage interprété ce qui fait ca lenteur contrairement au langages compilés Assembleur, C, ...
La même démo que tu à faite en X-Basic donnerais quoi en Basic MSX2 standard (en terme de vitesse) ?
Je viens de réaliser un test avec un personnage plus petit et l'animation est beaucoup plus rapide mais trop pour le coup, le clignotement n'est pas visible sur émulateur en tout cas.
Demain si je trouve un peu de temps j'essaie d’implémenter un scrolling du décor, mais la ca risque de ramer à fond, j'ai une petite idée mais il faut que j'essaie pour voir si c'est réalisable ....
Pour vous faire une idée de la vitesse de déplacement du personnage avec son animation :Vigi.zip Edité par 6502man Le 19/07/2018 à 22h32
Demain si je trouve un peu de temps j'essaie d’implémenter un scrolling du décor, mais la ca risque de ramer à fond, j'ai une petite idée mais il faut que j'essaie pour voir si c'est réalisable ....
Pour vous faire une idée de la vitesse de déplacement du personnage avec son animation :Vigi.zip Edité par 6502man Le 19/07/2018 à 22h32
Très sympa pour un simple test
Un petit retour d'expérience personnelle qui relève donc du Basic
Les Sprites Hardwares:
Lorsque l'on utilise le Scrolling Horizontal HardWare du VDP 9958, le Background se déplace très simplement horizontalement alors que le Sprite lui reste "figé" sur sa position X au regard du spectateur.
Avantage: obtient visuellement, un Héro qui se déplace sur le Background le plus simplement du monde et utilisant absolument aucune ressource pour cela. (si ce n'est que le déroulement du Background évidemment!)
Inconvénient: Si t'es ennemis sont aussi des vrais Sprites, il faut relaloriser leurs positions X à chaque cycle pour donner l'illusion qu'ils ont "les pieds ancrés au sol qui déroule à l'écran"! (Sans cela, on verrait le sol "glisser sous les pieds des ennemis")
Les Sprites Softwares:
Contrairement aux Sprites Hardwares, les "Sprites Softwares" vont suivre "littéralement" le déroulement du Background dans tous ces mouvements X et Y.
Inconvénient: implique qu'il faut repositionner ton héro à chaque cycle.
Avantage: Les ennemis "coïncident" au mouvements X et Y de Scrolling du BackGround sans nécessité la moindre ressource.
Nb: Contrairement au Scrolling Hardware Horizontal "SET SCROLL X ou encore VDP(27)=VDP(27)+X" possible qu'à partir du MSX2+(VDP 9958) ...
Le Scrolling Hardware Vertical "VDP(24)=VDP(24)+Y" possible à partir du MSX2 (VDP 9938), déplace (visuellement) le sprite Hardware dans la verticalité sans pour autant affecter sa variable Y.
Autrement dit, Si tu scroll Verticalement, le Vrai Sprite suit le scrolling (comme si les pieds du héros étaient ancrés au sol) sans nécessiter de ressources particulières.
Voila...Tout cela relève du Basic et ne concerne "peut être pas" la programmation directe en langage machine!
Dans tous les cas, j'ai trouvé pertinent de te rapporter ces détails qui peuvent aider à la compréhension du Hardware spécifique au MSX.
Bonne journée à tous
Edité par
igal
Le 20/07/2018 à 08h57
Un petit retour d'expérience personnelle qui relève donc du Basic
Les Sprites Hardwares:
Lorsque l'on utilise le Scrolling Horizontal HardWare du VDP 9958, le Background se déplace très simplement horizontalement alors que le Sprite lui reste "figé" sur sa position X au regard du spectateur.
Avantage: obtient visuellement, un Héro qui se déplace sur le Background le plus simplement du monde et utilisant absolument aucune ressource pour cela. (si ce n'est que le déroulement du Background évidemment!)
Inconvénient: Si t'es ennemis sont aussi des vrais Sprites, il faut relaloriser leurs positions X à chaque cycle pour donner l'illusion qu'ils ont "les pieds ancrés au sol qui déroule à l'écran"! (Sans cela, on verrait le sol "glisser sous les pieds des ennemis")
Les Sprites Softwares:
Contrairement aux Sprites Hardwares, les "Sprites Softwares" vont suivre "littéralement" le déroulement du Background dans tous ces mouvements X et Y.
Inconvénient: implique qu'il faut repositionner ton héro à chaque cycle.
Avantage: Les ennemis "coïncident" au mouvements X et Y de Scrolling du BackGround sans nécessité la moindre ressource.
Nb: Contrairement au Scrolling Hardware Horizontal "SET SCROLL X ou encore VDP(27)=VDP(27)+X" possible qu'à partir du MSX2+(VDP 9958) ...
Le Scrolling Hardware Vertical "VDP(24)=VDP(24)+Y" possible à partir du MSX2 (VDP 9938), déplace (visuellement) le sprite Hardware dans la verticalité sans pour autant affecter sa variable Y.
Autrement dit, Si tu scroll Verticalement, le Vrai Sprite suit le scrolling (comme si les pieds du héros étaient ancrés au sol) sans nécessiter de ressources particulières.
Voila...Tout cela relève du Basic et ne concerne "peut être pas" la programmation directe en langage machine!
Dans tous les cas, j'ai trouvé pertinent de te rapporter ces détails qui peuvent aider à la compréhension du Hardware spécifique au MSX.
Bonne journée à tous
Edité par
igal
Le 20/07/2018 à 08h57
@Igal: Le scrolling horizontal hardware n'est pas implémenté dans le VDP des MSX2, mais uniquement celui des MSX2+ et comme je m’intéresse pour l'instant qu'au MSX2, et puis les MSX2+ sont pas les plus répandus chez les gamers/collectionneurs d'ordinosaures
Sinon j'ai choisi de ne pas utiliser pour mes premiers tests les sprites hardware, car ils sont limités à 1 couleur par ligne et je voudrais obtenir des sprites un peu plus colorés sans avoir besoins de définir 50 sprites pour un perso
@Jipe: merci pour l'archive, je vais regarder ca, même si le Basic n'est pas mon premier choix ca peut être intéressant
Premier test de scrolling du décor derrière le personnage et j'ai opté pour la solution du personnage qui ne change pas de coordonnées écran par simplicité et facilité, qui à dit que les programmeurs étaient un peu paresseux
L'impression de déplacement est réaliste, mais comme on s'y attendais il faut utiliser un buffer pour éviter le clignotement
Pour ceux qui veulent tester, c'est brut il y a un petit décalage du décor scrollant (c'est normal j'ai pas ajusté les coordonnées vu que ce n'est qu'un test) :
Vigi2.zip
la suite : un gestion d'un buffer en "page off" pour éviter le clignotement et quelques petits trucs en plus pour m'amuser ....
Sinon j'ai choisi de ne pas utiliser pour mes premiers tests les sprites hardware, car ils sont limités à 1 couleur par ligne et je voudrais obtenir des sprites un peu plus colorés sans avoir besoins de définir 50 sprites pour un perso
@Jipe: merci pour l'archive, je vais regarder ca, même si le Basic n'est pas mon premier choix ca peut être intéressant
Premier test de scrolling du décor derrière le personnage et j'ai opté pour la solution du personnage qui ne change pas de coordonnées écran par simplicité et facilité, qui à dit que les programmeurs étaient un peu paresseux
L'impression de déplacement est réaliste, mais comme on s'y attendais il faut utiliser un buffer pour éviter le clignotement
Pour ceux qui veulent tester, c'est brut il y a un petit décalage du décor scrollant (c'est normal j'ai pas ajusté les coordonnées vu que ce n'est qu'un test) :
Vigi2.zip
la suite : un gestion d'un buffer en "page off" pour éviter le clignotement et quelques petits trucs en plus pour m'amuser ....
Salut à toi 6502Man
J'ai bien compris que tu souhaites rester sur un 9938 (Msx2) pour le moment.
Quelqu'un à dit un jour...)> "Igal...Tu lui fermes la porte, il passe par le fenêtre"!
Mode [fenêtre ON]:
J'avais expérimenté avec Space Manbow (en Basic) un scrolling MSX2 en m'inspirant de ce que l'on voit sur le jeu original "Space Manbow" lorsque l'on à un VDP9938 donc un VDP qui n'est pas équipé du Scrolling Horizontal Hardware.
J'avais pour intuition que Konami a utilisé un truc dans le genre
Partons du constat suivant:
Sur un 9958 (MSX2+), la commande SET SCROLL X permet un scrolling Honrizontal hardware.
Cette commande agit sur le registre 27 (je dis ça de tête) du 9958
Comment faire Scroller Horizontalement l'écran d'un 9938 (Msx2)?
J'avais travaillé sur la solution suivante => SET ADJUST (X,Y)
Set adjust permet de faire glisser l'écran du MSX de façon complètement Hardware et donc économe en ressource!
Les valeurs de X de SET ADJUST va de 8 à -7 (pour info, il en est de même pour Y)
Grosso modo, j'ai fait un truc du genre:
10 X = 9 (prérequis)
20 X = X - 1 : SET ADJUST (X,0)
30 COPY "bribe d'image 001.SC5" tout à droite de la page visible. (bribe d'image est une colonne large d'un pixel et haute de 212 pixels)
40 bribe d'image = bribe d'image + 001 :IF X=-7 THEN GOTO 60 => (cela signifie que bribe est égal à 016)
50 GOTO 20
60 Bribe d'image = 001 : déplacer l'intégralité de l'image de 16 pixels d'un coup (je me rappel plus comment) : GOTO 10
Je me souviens plus comment je faisais pour déplacer d'un coup l'image de 16 pixels mais je me souviens qu'en basic, le résulta me donnait envie de vomir
J'ai bien compris que tu souhaites rester sur un 9938 (Msx2) pour le moment.
Quelqu'un à dit un jour...)> "Igal...Tu lui fermes la porte, il passe par le fenêtre"!
Mode [fenêtre ON]:
J'avais expérimenté avec Space Manbow (en Basic) un scrolling MSX2 en m'inspirant de ce que l'on voit sur le jeu original "Space Manbow" lorsque l'on à un VDP9938 donc un VDP qui n'est pas équipé du Scrolling Horizontal Hardware.
J'avais pour intuition que Konami a utilisé un truc dans le genre
Partons du constat suivant:
Sur un 9958 (MSX2+), la commande SET SCROLL X permet un scrolling Honrizontal hardware.
Cette commande agit sur le registre 27 (je dis ça de tête) du 9958
Comment faire Scroller Horizontalement l'écran d'un 9938 (Msx2)?
J'avais travaillé sur la solution suivante => SET ADJUST (X,Y)
Set adjust permet de faire glisser l'écran du MSX de façon complètement Hardware et donc économe en ressource!
Les valeurs de X de SET ADJUST va de 8 à -7 (pour info, il en est de même pour Y)
Grosso modo, j'ai fait un truc du genre:
10 X = 9 (prérequis)
20 X = X - 1 : SET ADJUST (X,0)
30 COPY "bribe d'image 001.SC5" tout à droite de la page visible. (bribe d'image est une colonne large d'un pixel et haute de 212 pixels)
40 bribe d'image = bribe d'image + 001 :IF X=-7 THEN GOTO 60 => (cela signifie que bribe est égal à 016)
50 GOTO 20
60 Bribe d'image = 001 : déplacer l'intégralité de l'image de 16 pixels d'un coup (je me rappel plus comment) : GOTO 10
Je me souviens plus comment je faisais pour déplacer d'un coup l'image de 16 pixels mais je me souviens qu'en basic, le résulta me donnait envie de vomir
@Jipe: J'utilise Tasm64 pour développer en assembleur sur la plupart des plateformes que j'utilise (6502, Z80, TMS8xxx,...), et j'utilise d'autres assembleurs pour les CPU 6809 ou TMS99xx
Pourquoi cette question ?
@Igal: Je connais pas "SET SCROLL X" et "SET ADJUST (X,0)" c'est des commandes basic qui envoie les commandes au VDP ???
Pour le 9938 il n'y a pas de scrolling horizontal hardware ou j'ai pas trouvé ?
Donc le BASIC doit faire comme j'ai fait c'est à dires copier une portion d'écran vers la droite ou vers la gauche et compléter la partie restante.
Par contre X varie que de 8 à -7 mais quand est il de la zone des 8 à -7 ???
Voici l’implémentation d"un backbuffer avec swapping des pages pour éviter le clignotement, c'est pas encore optimal il me reste une bricole à régler pas eu le temps de finir ....
Vigi3.zip
Le principe que j'ai mis en place :
Donc en pratique à chaque déplacement du perso on change de page active plutôt que de tout recopier vers la page active
La suite: à suivre ...
Pourquoi cette question ?
@Igal: Je connais pas "SET SCROLL X" et "SET ADJUST (X,0)" c'est des commandes basic qui envoie les commandes au VDP ???
Pour le 9938 il n'y a pas de scrolling horizontal hardware ou j'ai pas trouvé ?
Donc le BASIC doit faire comme j'ai fait c'est à dires copier une portion d'écran vers la droite ou vers la gauche et compléter la partie restante.
Par contre X varie que de 8 à -7 mais quand est il de la zone des 8 à -7 ???
Voici l’implémentation d"un backbuffer avec swapping des pages pour éviter le clignotement, c'est pas encore optimal il me reste une bricole à régler pas eu le temps de finir ....
Vigi3.zip
Le principe que j'ai mis en place :
Code :
PAGE 0 et PAGE 1 => page visible en alternance
PAGE 2 => données perso
PAGE 3 => données décor
boot
-----
(variable en RAM VideoPage défini à 0)
(variable en RAM CoordXperso défini à 0)
(variable en RAM AnimPerso défini à 0)
Copie des données en VRAM par une boucle OUT(),A
Copie du décor entier de la PAGE 3 vers la PAGE 0 et PAGE 1 par la commande du VDP HMMM (2 fois)
Affichage du perso sur la page 0 avec gestion de la transparence par la commande du VDP LMMM
Active la PAGE 0 (VideoPage)
Pendant l’exécution
-------------------------
Si il y a déplacement du perso sinon on attend qu'une touche de direction soit utilisé.
(XOR $01 sur Videopage) [changera la page active 0/1]
incrémente ou décrémente (CoordXperso)
Copie de la partie du décor de la PAGE 3 (zone CoordXperso à $FF) vers la PAGE[VideoPage] par la commande du VDP HMMM
Copie de la partie du décor de la PAGE 3 (zone 0 à CoordXperso) vers la PAGE[VideoPage] par la commande du VDP HMMM
Affichage du perso sur la page 0 avec gestion de la transparence par la commande du VDP LMMM
incremente (AnimPerso)
Active la PAGE[VideoPage]
Donc en pratique à chaque déplacement du perso on change de page active plutôt que de tout recopier vers la page active
La suite: à suivre ...
Désolé si je t'ai induit en erreur..
SET SCROLL est une commande réservée au MSX2+ donc au VDP 9958.
Cette commande joue sur le registre VDP(27) qui n'existe pas sur le VDP 9938 (msx2).
La présence du registre VDP(27) permet un scrolling horizontal Hardware et très facile à mettre en oeuvre sur MSX2+.
Tout cela ne t'intéresse pas en définitive puisque tu souhaites te limiter au MSX2 soit le VDP 9938 qui n'a pas ce registre.
(C'était juste pour te mettre au parfum sur ce procédé)
Passons à la chose suivante.
Le VDP 9938 (msx2) à la commande SET ADJUST (je sais pas quel registres cela concerne dans la pratique).
Bref.. Le ou les registres qui sont utilisés lors de la commande SET ADJUST permettent de déplacer l'écran sur l'axe H et/ou V de 16 pixels au total et bien sur en Hardware!
J'avais exploré cette piste de la façon suivante:
1) je valorise SET ADJUST à -7
2) j'affiche une bribe d'image verticale épaisse d'un pixel.
3) je valorise SET ADJUST à -6
4) j'affiche une nouvelle bribe verticale épaisse d'un pixel.
etc etc...
Tu peux faire par tranche de 2 pixels ou plus... c'est selon la fluidité du scroll que tu recherche.
Une fois SET ADJUST à 8, il suffit de déplacer (je me rappel plus comment) la colonne épaisse de 16 pixels que tu as créé par morceaux de bribes.. Il te reste plus qu'à la déplacer d'un cran de 16 pixels d'un coup puis de remettre SET ADJUST à -7...
Tu recommences tout ca en boucle et tu obtiens un scrolling hardware sur VDP 9938.
Il te suffit de chercher quel registre est affecté par SET ADJUST X pour essayer la chose!
Encore une fois, en basic, lors du déplacement du bloc de 16 pixels et le retour à SET ADJUST -7, ca foutait la gerbe.
Par contre, je pense qu'en langage machine, cela devrait passer très facilement
SET SCROLL est une commande réservée au MSX2+ donc au VDP 9958.
Cette commande joue sur le registre VDP(27) qui n'existe pas sur le VDP 9938 (msx2).
La présence du registre VDP(27) permet un scrolling horizontal Hardware et très facile à mettre en oeuvre sur MSX2+.
Tout cela ne t'intéresse pas en définitive puisque tu souhaites te limiter au MSX2 soit le VDP 9938 qui n'a pas ce registre.
(C'était juste pour te mettre au parfum sur ce procédé)
Passons à la chose suivante.
Le VDP 9938 (msx2) à la commande SET ADJUST (je sais pas quel registres cela concerne dans la pratique).
Bref.. Le ou les registres qui sont utilisés lors de la commande SET ADJUST permettent de déplacer l'écran sur l'axe H et/ou V de 16 pixels au total et bien sur en Hardware!
J'avais exploré cette piste de la façon suivante:
1) je valorise SET ADJUST à -7
2) j'affiche une bribe d'image verticale épaisse d'un pixel.
3) je valorise SET ADJUST à -6
4) j'affiche une nouvelle bribe verticale épaisse d'un pixel.
etc etc...
Tu peux faire par tranche de 2 pixels ou plus... c'est selon la fluidité du scroll que tu recherche.
Une fois SET ADJUST à 8, il suffit de déplacer (je me rappel plus comment) la colonne épaisse de 16 pixels que tu as créé par morceaux de bribes.. Il te reste plus qu'à la déplacer d'un cran de 16 pixels d'un coup puis de remettre SET ADJUST à -7...
Tu recommences tout ca en boucle et tu obtiens un scrolling hardware sur VDP 9938.
Il te suffit de chercher quel registre est affecté par SET ADJUST X pour essayer la chose!
Encore une fois, en basic, lors du déplacement du bloc de 16 pixels et le retour à SET ADJUST -7, ca foutait la gerbe.
Par contre, je pense qu'en langage machine, cela devrait passer très facilement
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie