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
Comme l'a déjà suggéré Jipe, le plus raisonnable serait de charger des (bribes de) pattern. Celle_ci +une carto prennent moins de place et peuvent être stockée en RAM ou vram.Puis être moins gourmand en utilisant un mode écran plus léger.
Par contre je ne sais pas comment opérer avec la commande copy et le scroll.
Le MSXien le plus à l'ouest ... ou presque
ericb59
Membre non connecté
Conseiller Municipal
Metalion :
Bonsoir Eric,
Bonne idée, le Nestor Basic
Et particulièrement à la gestion des segments de RAM, et des transferts en VRAM !
Après ça dépend de ce que Igal veut faire ...
Bonne idée, le Nestor Basic
Et particulièrement à la gestion des segments de RAM, et des transferts en VRAM !
Après ça dépend de ce que Igal veut faire ...
Le seul soucis avec les transfert RAM > VRAM c'est qu'on ne peut faire que des transferts linéaire…
C'est à un dire un certain nombre de pixels qui se trouvent à la suite les uns des autres.
On ne peut pas utiliser des patterns avec cette technique, (en tout cas pas directement).
Si Igal veut continuer à utiliser sa technique des brides, cela peut fonctionner par contre.
La différence est que les brides seront stockées en Ram plutôt que sur le support physique.
MSXosaure :
Comme l'a déjà suggéré Jipe, le plus raisonnable serait de charger des (bribes de) pattern. Celle_ci +une carto prennent moins de place et peuvent être stockée en RAM ou VRAM.
On est bien d'accord
C'est comme ça que font la majorité des jeux : le décor est en fait constitué de "tuiles" (tiles) de 8x8 ou 16x16, avec donc un certain degré de répétivité, mais qui peuvent être habilement gérées pour donner l'illusion d'un décor varié.
MSXosaure :
Puis être moins gourmand en utilisant un mode écran plus léger.
On est d'accord aussi
MSXosaure :
Par contre je ne sais pas comment opérer avec la commande copy et le scroll.
Il suffit d'alimenter régulièrement le segment graphique qui va apparaître lors du scrolling, sachant que celui ci fait glisser en boucle la première partie 256x256 de la VRAM
Prenons par exemple :
- la hauteur de l'écran à 192
- la valeur du registre 24 à 32
- un scrolling du bas vers le haut
Le segment caché à cet instant précis est celui pour lequel Y=32+192 soit 224.
Tu copies donc le nouveau segment de ton décor à Y=224.
Autre exemple :
- la hauteur de l'écran à 192
- la valeur du registre 24 à 96
- un scrolling du bas vers le haut
Le segment caché à cet instant précis est celui pour lequel Y=96+192 soit 288. On boucle après 256, c'est donc 32 (288-256).
Tu copies donc le nouveau segment de ton décor à Y=32.
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)
igal
Membre non connecté
Conseiller Municipal
Salut à tous
@Metalion: Pardon si j'ai pas précisé, mais dès le départ, l'idée est de travailler sur CF avec un nombre quasi illimité de "Bribes" à charger pour un scroll aussi long que nécessaire. (Un support CF ou SD est le minimum requis de nos jours )
J'avais pensé à stocker en RAM pour un éventuel gain de rapidité, mais cela éliminerait d'emblée un grand nombre d'utilisateurs.
Jipe explique que l'on peut utiliser ces commandes sous BASIC:
*******************************************
Le basic a des commandes pour le dos 2
call chdir ("xx") change de directory
call chdrv ("a:") change de disque
copy "a:word/mike"to "b:ltrs/tama" copy dans les répertoires
*****************************************************************
Sachant que le DOS2 est intégré à la CF, normalement ca devrait fonctionner non?
Si OUI, alors on peut remplir des paquets de 64 Bribes par Répertoire différents et voir si ça facilite les temps d'accès au fichier.
@Eric: Pour le moment, j'essais de voir ce que je peux tirer du BASIC natif. Par la suite pourquoi pas.
@MsxOsaure: (Content de te lire )
L'idée est d'éviter d'avoir à stocker en RAM ou VRAM si c'est possible.
Là, j'ai surtout besoin d'aide pour automatiser les commandes que je répète lignes après lignes
Dans un moment, je posterai un générateur de Bribes par [4X256].
@Metalion: Pardon si j'ai pas précisé, mais dès le départ, l'idée est de travailler sur CF avec un nombre quasi illimité de "Bribes" à charger pour un scroll aussi long que nécessaire. (Un support CF ou SD est le minimum requis de nos jours )
J'avais pensé à stocker en RAM pour un éventuel gain de rapidité, mais cela éliminerait d'emblée un grand nombre d'utilisateurs.
Jipe explique que l'on peut utiliser ces commandes sous BASIC:
*******************************************
Le basic a des commandes pour le dos 2
call chdir ("xx") change de directory
call chdrv ("a:") change de disque
copy "a:word/mike"to "b:ltrs/tama" copy dans les répertoires
*****************************************************************
Sachant que le DOS2 est intégré à la CF, normalement ca devrait fonctionner non?
Si OUI, alors on peut remplir des paquets de 64 Bribes par Répertoire différents et voir si ça facilite les temps d'accès au fichier.
@Eric: Pour le moment, j'essais de voir ce que je peux tirer du BASIC natif. Par la suite pourquoi pas.
@MsxOsaure: (Content de te lire )
L'idée est d'éviter d'avoir à stocker en RAM ou VRAM si c'est possible.
Là, j'ai surtout besoin d'aide pour automatiser les commandes que je répète lignes après lignes
Dans un moment, je posterai un générateur de Bribes par [4X256].
igal :
....
Sachant que le DOS2 est intégré à la CF, normalement ca devrait fonctionner non?
Sachant que le DOS2 est intégré à la CF, normalement ca devrait fonctionner non?
Je ne connais pas suffisamment le DOS et les appels éventuels depuis le BASIC pour pouvoir programmer ça.
Désolé.
igal :
Dans un moment, je posterai un générateur de Bribes par [4X256].
J'ai déjà fait un générateur de "bribes" 4px ...
Il est sur la disquette Toaplan4.dsk, dans mon post précédent.
A ce stade là, je te laisse continuer seul.
Je reste convaincu que l'accès disque pour charger les segments graphiques d'un scrolling n'est pas une bonne solution.
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)
igal
Membre non connecté
Conseiller Municipal
Ok ok...
Mais dans la pratique, ranger les 64 Bribes (de 0 à 63) apporte un réel gain comme on peut le voir ci dessous
http://youtu.be/vpKvtU5B4yc
Maintenant que les temps d'accès semblent acceptables, je voudrais essayer la chose suivante:
Tout d'abord, nous sommes d'accord que les Bribes chargés sont "hautes" de 4 pixels.
Plutot que d'incrémenter VDP(24)=vdp(24)+4and255, je voudrais essayer d'intercaler dans la "latence" qu'a le MSX à rechercher le bon fichier à faire dérouler le SCROLL pixel par pixel.
De la sorte, le temps perdu à recherché le fichier serait occupé par l'incrémentation de VDP(24)!
La grande question est de savoir si [l'incrémentation en cours] empêche la [recherche du fichier suivant]?
Savez vous comment le peut remplacer simplement VDP(24)=VDP(24)+4 par une autre formule (pixel par pixel) qui ne "bloque" pas le MSX dans le même temps?
J'avais pour idée d'utiliser une formule rapporté par Magoo pour le VDP 27 => VDP(27)=(N+7)8: VDP(28)=-N AND 7
Si vous avez une idée!
Mais dans la pratique, ranger les 64 Bribes (de 0 à 63) apporte un réel gain comme on peut le voir ci dessous
http://youtu.be/vpKvtU5B4yc
Maintenant que les temps d'accès semblent acceptables, je voudrais essayer la chose suivante:
Tout d'abord, nous sommes d'accord que les Bribes chargés sont "hautes" de 4 pixels.
Plutot que d'incrémenter VDP(24)=vdp(24)+4and255, je voudrais essayer d'intercaler dans la "latence" qu'a le MSX à rechercher le bon fichier à faire dérouler le SCROLL pixel par pixel.
De la sorte, le temps perdu à recherché le fichier serait occupé par l'incrémentation de VDP(24)!
La grande question est de savoir si [l'incrémentation en cours] empêche la [recherche du fichier suivant]?
Savez vous comment le peut remplacer simplement VDP(24)=VDP(24)+4 par une autre formule (pixel par pixel) qui ne "bloque" pas le MSX dans le même temps?
J'avais pour idée d'utiliser une formule rapporté par Magoo pour le VDP 27 => VDP(27)=(N+7)8: VDP(28)=-N AND 7
Si vous avez une idée!
igal :
Plutot que d'incrémenter VDP(24)=vdp(24)+4and255, je voudrais essayer d'intercaler dans la "latence" qu'a le MSX à rechercher le bon fichier à faire dérouler le SCROLL pixel par pixel.
Cela ne marche pas, j'ai essayé.
Pour la simple raison que, comme je l'ai déjà écris plus haut, l'accès disque ne se fait pas en tâche parallèle, mais en tâche principale. Le MSX n'est pas multitâche. Pendant que le MSX cherche et charge le fichier, toute autre exécution est suspendue.
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)
igal
Membre non connecté
Conseiller Municipal
@Métalion:
Il est possible de séquencer la commande:
[VDP(24)=VDP(24)+4AND255] en Deux => [VDP(24)=VDP(24)+2AND255......VDP(24)=VDP(24)+2AND255]
Et même en Quatre => [VDP(24)=VDP(24)+1AND255......VDP(24)=VDP(24)+1AND255.....VDP(24)=VDP(24)+1AND255......VDP(24)=VDP(24)+1AND255]
En avancant par PAS de 2 (2 séquences de 2) , cela rend les déroulement plus agréable à voir.
Par contre, en voulant tester par PAS de 1 (4 séquences de 1), la déroulement reste identique. La limite semble bien être des pas de 2 pixels vers le haut.
Peut être est ce du au SCREEN 12 mais....
Voici une formuloe qu'avait rapporté Magoo pour une deroulement horizontal pixel par pixel:
VDP(27)=(N+7)8: VDP(28)=-N AND 7
voici du scrolling multidirectionnel sous BASIC lol:
http://youtu.be/JSlij_wGrY4
A suivre
Il est possible de séquencer la commande:
[VDP(24)=VDP(24)+4AND255] en Deux => [VDP(24)=VDP(24)+2AND255......VDP(24)=VDP(24)+2AND255]
Et même en Quatre => [VDP(24)=VDP(24)+1AND255......VDP(24)=VDP(24)+1AND255.....VDP(24)=VDP(24)+1AND255......VDP(24)=VDP(24)+1AND255]
En avancant par PAS de 2 (2 séquences de 2) , cela rend les déroulement plus agréable à voir.
Par contre, en voulant tester par PAS de 1 (4 séquences de 1), la déroulement reste identique. La limite semble bien être des pas de 2 pixels vers le haut.
Peut être est ce du au SCREEN 12 mais....
Voici une formuloe qu'avait rapporté Magoo pour une deroulement horizontal pixel par pixel:
VDP(27)=(N+7)8: VDP(28)=-N AND 7
voici du scrolling multidirectionnel sous BASIC lol:
http://youtu.be/JSlij_wGrY4
A suivre
ericb59
Membre non connecté
Conseiller Municipal
Ca c'était facile !
Maintenant tu fais comment pour mettre un sprite de soldat qui tire sur tout ce qui bouge ?
PS : Le scroll normalement il devrait être inversé ... du haut vers le bas...
Maintenant tu fais comment pour mettre un sprite de soldat qui tire sur tout ce qui bouge ?
PS : Le scroll normalement il devrait être inversé ... du haut vers le bas...
igal
Membre non connecté
Conseiller Municipal
Justement à propos des spirites, je vais ouvrir un post concernant la commande BASE qui permet de déplacer la zone des Sprite sur la page SET PAGE 1.
Pour ce qui est du déplacement du/des SPRITES, j'ai pensé intercaler entre chaque "bribes" un bout de code permettant de commander les déplacements.
L'idée est de trouver le meilleur compromis entre "le temps" de recherche du fichier à charger et l'insertion d'un certain nombre de commandes "juste avant" ou "juste apres" la recherche du fichier.
Concernant le déroulement du décors dans l'autre sens, il faut inverser l'ordre des Bribes à charger.
Soit en modifiant le moteur soit en segmentation l'image source dans l'ordre inverse.
J'avais remarqué ça des le départ mais ça n'empêche pas de mettre en oeuvre le concept.
Pour ce qui est du déplacement du/des SPRITES, j'ai pensé intercaler entre chaque "bribes" un bout de code permettant de commander les déplacements.
L'idée est de trouver le meilleur compromis entre "le temps" de recherche du fichier à charger et l'insertion d'un certain nombre de commandes "juste avant" ou "juste apres" la recherche du fichier.
Concernant le déroulement du décors dans l'autre sens, il faut inverser l'ordre des Bribes à charger.
Soit en modifiant le moteur soit en segmentation l'image source dans l'ordre inverse.
J'avais remarqué ça des le départ mais ça n'empêche pas de mettre en oeuvre le concept.
Igal,
Je t'admire pour ta persévérance (bien qu'elle tourne parfois à l'entêtement ... ) car au final, il faut bien avouer que ta dernière itération du programme donne un résultat plutôt pas mal, avec un défilement qui tient la route .
Cependant, il faut quand même bien reconnaître une impasse quand on en a une en face de soi. Et là, tu es bien face à une impasse ... Le réglage fin du scrolling par rapport au chargement des "bribes" (ce que tu viens de faire) est probablement, à peu de choses près, la dernière chose que tu peux modifier au programme en gardant le défilement tel quel. Le reste ne fera que ralentir toute l'opération.
PS: Pour une raison que j'ignore, la commande BASE ne fonctionne pas avec le SCREEN12. Du moins, je n'arrive pas à trouver les paramètres de la commande qui correspondent à la TAS et la TGS pour le SCREEN12. Comme je te l'avais écrit, par déduction, je pensais qu'il s'agissait de BASE(63) et BASE(64), mais ces commandes donnent un message d'erreur (je n'ai pas de référentiel pour le BASIC du MSX2+, et je ne sais pas si il existe). J'ai donc finalement déplacé la TAS et la TGS en modifiant les registres avec la commande VDP (voir dans mes programmes GEN et SCROLL sur les disquettes précédentes).
PS2 : Etant donné que les modes graphiques 10 et 11 sont en fait identiques du point de vue du VDP, peut être que c'est en fait BASE(58) et BASE(59). A essayer ... Edité par Metalion Le 17/09/2014 à 11h20
Je t'admire pour ta persévérance (bien qu'elle tourne parfois à l'entêtement ... ) car au final, il faut bien avouer que ta dernière itération du programme donne un résultat plutôt pas mal, avec un défilement qui tient la route .
Cependant, il faut quand même bien reconnaître une impasse quand on en a une en face de soi. Et là, tu es bien face à une impasse ... Le réglage fin du scrolling par rapport au chargement des "bribes" (ce que tu viens de faire) est probablement, à peu de choses près, la dernière chose que tu peux modifier au programme en gardant le défilement tel quel. Le reste ne fera que ralentir toute l'opération.
PS: Pour une raison que j'ignore, la commande BASE ne fonctionne pas avec le SCREEN12. Du moins, je n'arrive pas à trouver les paramètres de la commande qui correspondent à la TAS et la TGS pour le SCREEN12. Comme je te l'avais écrit, par déduction, je pensais qu'il s'agissait de BASE(63) et BASE(64), mais ces commandes donnent un message d'erreur (je n'ai pas de référentiel pour le BASIC du MSX2+, et je ne sais pas si il existe). J'ai donc finalement déplacé la TAS et la TGS en modifiant les registres avec la commande VDP (voir dans mes programmes GEN et SCROLL sur les disquettes précédentes).
PS2 : Etant donné que les modes graphiques 10 et 11 sont en fait identiques du point de vue du VDP, peut être que c'est en fait BASE(58) et BASE(59). A essayer ... Edité par Metalion Le 17/09/2014 à 11h20
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)
igal
Membre non connecté
Conseiller Municipal
GDX :
T'inquiètes pas Metalion, il en faut plus pour décourager igal.
voici l'idée tordue qui a germée dans ma tête
Les directions ci dessous "devraient" fonctionner au vu de mes testes précédents.
Haut => Répertoire contenant les bribes HAUT
Bas => Répertoire contenant les Bribes BAS
Diagonal Droit/Haut => Répertoire contenant les Bribes Haut
Diagonal Gauche/Haut => Répertoire contenant les Bribes Haut
Diagonal Droite/Bas => Répertoire contenant les Bribes Bas
Diagonal Gauche/Bas => Répertoire contenant les Bribes Bas
Les directions ci dessous doivent être testés:
Droite => Répertoire contenant les Bribes Droites
Gauche => Répertoire contenant les Bribes Gauches
Bon c'est juste une idée, mais on est positif lol
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie