La Place des Développeurs [RESOLU] VDP(27) le Scrolling hardware Horizontal Comment alimenter de nouveaux décors VDP (27)?
Reprise du message précédent
Je viens de retrouver une vidéo que j'avais fait avec des Scroll dans tous les sens mais en Screen 5 et non en Screen 10
https://www.youtube.com/watch?v=45ueWHQkbI0
Je viens de faire quelques testes avec la commande SET SCROLL -N et ca le fait parfaitement bien en screen 10
Par contre, je suis quand même intéressé par l'écriture arithmétique.
Par exemple pour pour créer des mouvements "pseudo pseudo aléatoires", je me suis servi des valeurs de VDP(27) et VDP(24) pour incrémenter mes [Variables] servant au mouvement des Ennemiss ennemis
Donc je repose la question:
Sachant que cette formule fait dérouler "sans accoups" une image en SCREEN 10 de 4 pixels vers la gauche:
VDP(27)=(N+7)/8:VDP(28)=-NAND7:N=N+4
Ou encore celle ci par 2 pixels:
VDP(27)=(N+7)/8:VDP(28)=-NAND7:N=N+2
Je vais donc trifouiller en espérant trouver les bons paramètres
Edit: @Eric: Je travaille sur MSX2+ virtuel. Le Turbo-R c'est juste pour faire les vidéos
Edité par
igal
Le 05/12/2015 à 13h26
a mon avis c'est juste n=n-4 ou n=n-2
N étant la valeur qui est codée sur les 2 octets du registre 26 vdp(27) bits 8, 7, 6, 5, 4, 3 et du registre 27 vdp(28) bits 2 ,1 ,0
pour rappel en basic la valeur vdp( ) est celle du registre additionnée de 1
exemple le registre 9 est le VDP(10) en basic
N étant la valeur qui est codée sur les 2 octets du registre 26 vdp(27) bits 8, 7, 6, 5, 4, 3 et du registre 27 vdp(28) bits 2 ,1 ,0
pour rappel en basic la valeur vdp( ) est celle du registre additionnée de 1
exemple le registre 9 est le VDP(10) en basic
Merci pour ces infos Jipe.
Les déroulements fonctionnent bien dans les deux sens mais il y a un soucis.
Scroling qui glisse vers la gauche: (direction du héro =>
lorsque je charge mes bribes larges de 2, 4 ou 8 pixels de largeur tout est OK.
Scroling qui glisse vers la Droite: (Direction du héro <=)
Lorsque je charge mes bribes larges de 4 et 8 pixels de largeur tout est OK.
Par contre, lorsqu'il s'agit de charger les bribes larges de 2 pixels qui glisse vers la droite, (le héro va vers la gauche <= ), il y a un soucis avec la teinte de l'image.
En effet, l'image affichée présente un tramage vertical sur le fond.
Concrètement, cela se traduit par une teinte contrasté puis décolorée formant des colonnes verticales.
Nb: cela n'a absolument rien a voir avec VDP (27) ou (28) ou encore SET SCROLL, j'ai fais des essais sans aucun scroll et le problème se présente du moment que les Bribes sont chargées en commençant par la Droite pour afficher la derniere bribe à Gauche.
Nb: Aucun soucis en affichant ses mêmes bribes en commençant de Gauche vers la Droite.
Si je me trompe pas, certaines données de couleurs en SCREEN 10,11 et 12 sont contenus dans les Pixels "SUIVANT" "PRÉCÉDENTS" autrement dit, dans les Pixels affichés à gauche, il y a des données nécessaires aux pixels affichés à leurs droite.
Si c'est bien la source du Problème, alors le déroulement du Scroll vers la Droite [Héro se dirige à Gauche] par PAS de 2 pixels ne sera donc pas disponible
Je récapitule:
1a) => par PAS de 2 OK.
1b) <= par PAS de 2 KO. (bug créant un tramage de fond)
2a) => par PAS de 4 OK.
2b) <= par PAS de 4 OK.
3a) => par PAS de 8 OK.
3b) <= par PAS de 8 OK.
Si vous avez une idée
Edité par
igal
Le 05/12/2015 à 19h39
Les déroulements fonctionnent bien dans les deux sens mais il y a un soucis.
Scroling qui glisse vers la gauche: (direction du héro =>
lorsque je charge mes bribes larges de 2, 4 ou 8 pixels de largeur tout est OK.
Scroling qui glisse vers la Droite: (Direction du héro <=)
Lorsque je charge mes bribes larges de 4 et 8 pixels de largeur tout est OK.
Par contre, lorsqu'il s'agit de charger les bribes larges de 2 pixels qui glisse vers la droite, (le héro va vers la gauche <= ), il y a un soucis avec la teinte de l'image.
En effet, l'image affichée présente un tramage vertical sur le fond.
Concrètement, cela se traduit par une teinte contrasté puis décolorée formant des colonnes verticales.
Nb: cela n'a absolument rien a voir avec VDP (27) ou (28) ou encore SET SCROLL, j'ai fais des essais sans aucun scroll et le problème se présente du moment que les Bribes sont chargées en commençant par la Droite pour afficher la derniere bribe à Gauche.
Nb: Aucun soucis en affichant ses mêmes bribes en commençant de Gauche vers la Droite.
Si je me trompe pas, certaines données de couleurs en SCREEN 10,11 et 12 sont contenus dans les Pixels "
Si c'est bien la source du Problème, alors le déroulement du Scroll vers la Droite [Héro se dirige à Gauche] par PAS de 2 pixels ne sera donc pas disponible
Je récapitule:
1a) => par PAS de 2 OK.
1b) <= par PAS de 2 KO. (bug créant un tramage de fond)
2a) => par PAS de 4 OK.
2b) <= par PAS de 4 OK.
3a) => par PAS de 8 OK.
3b) <= par PAS de 8 OK.
Si vous avez une idée
Edité par
igal
Le 05/12/2015 à 19h39
Eh eh...
Ben justement la subtilité est la:
ON peut sroller par 2 à condition de scroller par pair qui se suivent
La première paire de gauche contient des infos qui vont compléter la paire de droite.
Par contre si on commence par la paire de droite, celle qui va à sa gauche sera correctement colorée mais pas sa première de droite
Bref on en parle demain)
Enfin...la paire de gauche contient des données complémentaires à la.paires de droite.
En commençant à afficher la paire de droite avant la gauche, on a donc des couleurs erronées sur la paire de droite mais pas sur la paire de gauche lol Edité par igal Le 05/12/2015 à 21h08
Ben justement la subtilité est la:
ON peut sroller par 2 à condition de scroller par pair qui se suivent
La première paire de gauche contient des infos qui vont compléter la paire de droite.
Par contre si on commence par la paire de droite, celle qui va à sa gauche sera correctement colorée mais pas sa première de droite
Bref on en parle demain
)Enfin...la paire de gauche contient des données complémentaires à la.paires de droite.
En commençant à afficher la paire de droite avant la gauche, on a donc des couleurs erronées sur la paire de droite mais pas sur la paire de gauche lol Edité par igal Le 05/12/2015 à 21h08
Si des données se "mélange", problème de couleur, c'est peut-être un problème de "cache" mémoire de couleurs a réinitialiser.
En gros le copy se fait dans un sens ou l'autre mais que ce "copy" utilise les données memoire de la couleurs dans un seul sens logique.
P'tet une histoire de PILE memoire a effacé
(edit : comme je ne comprend pas ce que je dis, ca vat p'tet parlé a Igal
, je cherche seulement une piste )
En gros le copy se fait dans un sens ou l'autre mais que ce "copy" utilise les données memoire de la couleurs dans un seul sens logique.
P'tet une histoire de PILE memoire a effacé
(edit : comme je ne comprend pas ce que je dis, ca vat p'tet parlé a Igal
, je cherche seulement une piste )
MSX 1&2 + Moniteurs+divers (environ 0.70Tonnes)
Salut TurboSeb:
En SCREEN 12, les [2 Pixels de Gauches] contiennent des paramètre sur la couleur des [2 Pixels de Droite].
Disons que pour afficher une images par bandes verticales larges de [2 Pixels], Il faut procéder comme suit:
1) Considérons une image allant de 0 à 255 Pixles.
2) Les Pixels 0/1, 4/5, 8/9, 12/13, 16/17 etc sont les Pixels des "GROUPES DE LIGNES PAIRES".
3) Les Pixels 2/3, 6/7, 10/11, 14/15, 18/19 etc sont les Pixels des "GROUPES DE LIGNES IMPAIRES".
4) Les Pixels des [GROUPES DE LIGNES PAIRES] contiennent des données complémentaires aux [GROUPES DE LIGNES IMPAIRES].
Nb: Tans que l'on affiche les [GROUPES PAIRES] avant les [GROUPES IMPAIRES], la "magie" s'opère puisque le "mécanisme" veut que le [GROUPE IMPAIRES] se complète des données des [2 Pixels précédents].
Donc...
Scroll vers la Droite par PAS de 2 Pxiels OK.
Scroll vers la Gauche par PAS de 2 Pixles KO.
Voici en Images:
https://youtu.be/ERLhMcSpr48
En SCREEN 12, les [2 Pixels de Gauches] contiennent des paramètre sur la couleur des [2 Pixels de Droite].
Disons que pour afficher une images par bandes verticales larges de [2 Pixels], Il faut procéder comme suit:
1) Considérons une image allant de 0 à 255 Pixles.
2) Les Pixels 0/1, 4/5, 8/9, 12/13, 16/17 etc sont les Pixels des "GROUPES DE LIGNES PAIRES".
3) Les Pixels 2/3, 6/7, 10/11, 14/15, 18/19 etc sont les Pixels des "GROUPES DE LIGNES IMPAIRES".
4) Les Pixels des [GROUPES DE LIGNES PAIRES] contiennent des données complémentaires aux [GROUPES DE LIGNES IMPAIRES].
Nb: Tans que l'on affiche les [GROUPES PAIRES] avant les [GROUPES IMPAIRES], la "magie" s'opère puisque le "mécanisme" veut que le [GROUPE IMPAIRES] se complète des données des [2 Pixels précédents].
Donc...
Scroll vers la Droite par PAS de 2 Pxiels OK.
Scroll vers la Gauche par PAS de 2 Pixles KO.
Voici en Images:
https://youtu.be/ERLhMcSpr48
explication du SCREEN 12 et du scrolling horizontal :
tout vient de la particularité du codage YJK
les 4 pixels qui se suivent sont codés dans un mode YJK
seul le Y de chaque pixel est indépendant , il est codé par les bits B7 a B3 de chaque octet
le K est codé par les bit B2 a b0 des 2 premiers pixels , pixel 1 poids faible pixel 2 poids fort
le J est codé par les bit B2 a b0 des pixels 3 et 4 , pixel 3 poids faible pixel 4 poids fort
il les 4 octets qui se suivent sont donc liés par J et K
en scrollant de 2 en 2 horizontalement on vient mélanger le codage ce qui donne des barres verticales
seul le scrolling multiple de 4 peut être appliqué en horizontal
par contre en vertical on peut scroller de 1 par 1 sans soucis
parenthése :
pour dessiner en screen 12 il ne faut changer que le Y de chaque pixel pour ne pas avoir des parties qui bavent
le mieux est d'essayer Graphsaurus II pour mettre en pratique
tout vient de la particularité du codage YJK
les 4 pixels qui se suivent sont codés dans un mode YJK
seul le Y de chaque pixel est indépendant , il est codé par les bits B7 a B3 de chaque octet
le K est codé par les bit B2 a b0 des 2 premiers pixels , pixel 1 poids faible pixel 2 poids fort
le J est codé par les bit B2 a b0 des pixels 3 et 4 , pixel 3 poids faible pixel 4 poids fort
il les 4 octets qui se suivent sont donc liés par J et K
en scrollant de 2 en 2 horizontalement on vient mélanger le codage ce qui donne des barres verticales
seul le scrolling multiple de 4 peut être appliqué en horizontal
par contre en vertical on peut scroller de 1 par 1 sans soucis
parenthése :
pour dessiner en screen 12 il ne faut changer que le Y de chaque pixel pour ne pas avoir des parties qui bavent
le mieux est d'essayer Graphsaurus II pour mettre en pratique
Merci pour vos réactions.
@eric: oui j'ai lancé sur turbo-r.
A ce sujet, pourquoi est ce plus rapide sur turbo-r que sur msx2/2+?
Je sais pas si ce sont les accès à la cf ou l'exécution des commandes qui sont plus rapides.
Je suis étonné parce que cela signifie qu'un programme sur msx2 risque de ne pas être cohérent sur un turbo-r!?!
@jipe: effectivement c'est exactement le problème qui se pose.
Cependant, c'est pas dramatique puisque mon idée est que le hero dans ses déplacements fasse scroller par 2 pixels sur 2 pixels seulement puis par PAS de 4 pixels pour le reste du scroll.(et encore. ..Le scroll par PAS de 4 semble être un bon compromis)
Le scroll par PAS de 8 peut être intéressant pour les sauts.
Cela donnerait un certain dynamisme à l'action
@eric: oui j'ai lancé sur turbo-r.
A ce sujet, pourquoi est ce plus rapide sur turbo-r que sur msx2/2+?
Je sais pas si ce sont les accès à la cf ou l'exécution des commandes qui sont plus rapides.
Je suis étonné parce que cela signifie qu'un programme sur msx2 risque de ne pas être cohérent sur un turbo-r!?!
@jipe: effectivement c'est exactement le problème qui se pose.
Cependant, c'est pas dramatique puisque mon idée est que le hero dans ses déplacements fasse scroller par 2 pixels sur 2 pixels seulement puis par PAS de 4 pixels pour le reste du scroll.(et encore. ..Le scroll par PAS de 4 semble être un bon compromis)
Le scroll par PAS de 8 peut être intéressant pour les sauts.
Cela donnerait un certain dynamisme à l'action
en screen 12 ça va être dur de déplacer le heros en conservant le décor sans bavure
en plus je ne sais pas si les fonctions logiques genre TPSET sont supportées par le screen 12
cela permet afin de faire un contour transparent ainsi le heros se superpose au décor
en plus je ne sais pas si les fonctions logiques genre TPSET sont supportées par le screen 12
cela permet afin de faire un contour transparent ainsi le heros se superpose au décor
igal :
Merci pour vos réactions.
@eric: oui j'ai lancé sur turbo-r.
A ce sujet, pourquoi est ce plus rapide sur turbo-r que sur msx2/2+?
Je sais pas si ce sont les accès à la cf ou l'exécution des commandes qui sont plus rapides.
@eric: oui j'ai lancé sur turbo-r.
A ce sujet, pourquoi est ce plus rapide sur turbo-r que sur msx2/2+?
Je sais pas si ce sont les accès à la cf ou l'exécution des commandes qui sont plus rapides.
Les 2 mon capitaine !
Les commandes sont plus rapides et les accès disque aussi...
Effectivement un programme basic qui tournera sur TR ira beaucoup plus vite... Si c'est un jeu et qu'il a été programmé sans en tenir compte, cela peut être problématique !
Il faut temporiser avec des valeurs uniques sur les 2 machines... Soit le VBLANK, mais pas facile en Basic, soit faire des temporisation avec TIME
par exemple ce programme s'execute à la même vitesse sur MSX2 (NTSC) et TR
Code TEXT :
Edité par
ericb59
Le 06/12/2015 à 19h18
100 print "Bonjour... J'attends une seconde" 110 wt=60:time=0 120 if time<wt then 120 130 print "Au revoir"
@ jipe: le scrool horizontal laisse libre lez réservées aux Sprites et je pense travailler à la solution suivante:
1) sur un logiciel pc, je créer tous les Sprites que je souhaite.
2) je génère les datas des Sprites sur pc.
3) je créer le fichier .ASC dans lequel j'intègre tous les datas.
4) sur msx, je créer un programme qui fait ce qui suit:
A) je créer les sprite en les alimentant par les datas.
B) je BSAVE la zone des Sprites contenant les Sprites.
C) après redémarrage, je BLOAD le fichier sauvé précédemment sur sur la zone de Sprite.
D) j'anime un Sprite pour voir si il s'est "alimenté" des données que je viens de BLOAD sur la zone réservée.
Si cela fontionnel, alors on peut envisager de charger facilement par un simple bload des Sprites divers et variés tout au long du déroulement du jeu
1) sur un logiciel pc, je créer tous les Sprites que je souhaite.
2) je génère les datas des Sprites sur pc.
3) je créer le fichier .ASC dans lequel j'intègre tous les datas.
4) sur msx, je créer un programme qui fait ce qui suit:
A) je créer les sprite en les alimentant par les datas.
B) je BSAVE la zone des Sprites contenant les Sprites.
C) après redémarrage, je BLOAD le fichier sauvé précédemment sur sur la zone de Sprite.
D) j'anime un Sprite pour voir si il s'est "alimenté" des données que je viens de BLOAD sur la zone réservée.
Si cela fontionnel, alors on peut envisager de charger facilement par un simple bload des Sprites divers et variés tout au long du déroulement du jeu
@jipe : oui Tpset donctionne en screen12
@Igal : bsave/bload de sprites , bien sur que ça fonctionne ! je le fait sur mes projets en cours.
@Igal : bsave/bload de sprites , bien sur que ça fonctionne ! je le fait sur mes projets en cours.
Salut Eric.
Je parle de BSAVE "la Zone réservée" qui contient les Sprites dans l'état ou elle se trouve une fois que l'on l'a préalablement chargée avec des DATAS.
Une fois "l'état" de cette "Zone réservée" chargée, il suffirait de la BSAVE pour avoir "L'instantané" de cette zone.
Un BLOAD de cet "instantané" permettrait de "rempllir" cette zone avec les données telles qu'elle sont compréhensibles par le VDP lorsqu'elle sont présentes "Là" précisément et pas ailleurs.
Un sorte de "procédé inverse" qui permettrait de renouveler la variété des Sprites par un simple BLOAD!
Si tu l'as déjà fait alors tu commences à me plaire sérieusement parce que jusqu'à présent, toutes les approches un peu tordu ont trouvé un écho négatif au village
Fait toi entendre Barde! poste quelque chose pour voir comment tu t'y prends
Je parle de BSAVE "la Zone réservée" qui contient les Sprites dans l'état ou elle se trouve une fois que l'on l'a préalablement chargée avec des DATAS.
Une fois "l'état" de cette "Zone réservée" chargée, il suffirait de la BSAVE pour avoir "L'instantané" de cette zone.
Un BLOAD de cet "instantané" permettrait de "rempllir" cette zone avec les données telles qu'elle sont compréhensibles par le VDP lorsqu'elle sont présentes "Là" précisément et pas ailleurs.
Un sorte de "procédé inverse" qui permettrait de renouveler la variété des Sprites par un simple BLOAD!
Si tu l'as déjà fait alors tu commences à me plaire sérieusement parce que jusqu'à présent, toutes les approches un peu tordu ont trouvé un écho négatif au village
Fait toi entendre Barde! poste quelque chose pour voir comment tu t'y prends
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie