La Place des Développeurs [En cours] Scroll d'une map sur deux axes. Scroller une map MSX en utilisant deux techniques.
Reprise du message précédent
Voici un pack contenant les images et répertoires de sorte à tester.RACINE DU DISQUE E.zip
Nb: Le programme se nomme METAL022.ASC.
Pour le charger il suffit de faire LOAD"METAL022.ASC
Pour le sauvegarder il suffit de faire SAVE"METAL022.ASC",A
L'avantage du format ASC (ascii) est de pouvoir l'ouvrir sur PC et le modifier avec un logiciel tel que Notepad!
Si vous voulez un dessin sur la nomenclature du programme, je peux faire ça...Ca sera peut être plus clair à comprendre dans son ensemble
Je vais faire un petit dessin qui explique l'approche que je veux essayer pour scroller en diagonal Ce sera un peu plus clair dans ma tête
Edité par
igal
Le 28/04/2017 à 14h38
l'inconvénient de sauvegarder en ASCII c'est que le programme prends énormément plus de place
c'est bien pour le develloper ainsi mais il faut le sauvegarder en SAVE pour gagner de la place
c'est bien pour le develloper ainsi mais il faut le sauvegarder en SAVE pour gagner de la place
igal:
Je réponds à la place de Jipe qui est aux toilettes (
), : Non. Seulement moins lourd sur le disk, car le listing est compressé.
@jipe: tu veux dire que si je sauvegarde en .BAS (dans un mode non ascii), le même programme pèsera moins lourd dans la Ram?
Je réponds à la place de Jipe qui est aux toilettes (
), : Non. Seulement moins lourd sur le disk, car le listing est compressé.
Ok ok...
Me reste plus cas bûcher sur un nouveau programme qui intègre les deux axes dès le départ
La prochaine mouture permettra des déplacements par pas de 4 pixels.
Il faut savoir qu'un déplacement par pas de 4 élude le problème posé par la répartition "naturelle" imposée par le basic natif du msx.
En effet, lorsqu'on souhaite afficher une succession de bribes horizontales (pour un scroll vertical donc) épaisses de 8 pixels, on tombe systématiquement avec une demie bribes affichée sur la zone d'affichage "normale". La raison en est la suivante:
212/8= 26,5
Le problème reste le même lorsqu'on affiche des bribes épaisses de 8 pixels sur la zone "non habituelle" qui est haute de 44 pixels.
En effet si l'on divise 44/8= 5,5
Il y a bien une solution radicale qui consiste à basculer sur un affichage en 192 pixels (avec une zone non visible de 64 pixels).
Cela solutionne effectivement le problème des épaisseurs de 8 pixels de haut de chaque bribes.
Malgré tout, je pour d'autres raisons, je souhaite travailler avec des bribes de 4 pixels qui s'afficheront avec plus de fluidité que des bribes de 8.
J'essaie de finir quelques dessins d'ici ce soir, ce sera plus parlant
Me reste plus cas bûcher sur un nouveau programme qui intègre les deux axes dès le départ
La prochaine mouture permettra des déplacements par pas de 4 pixels.
Il faut savoir qu'un déplacement par pas de 4 élude le problème posé par la répartition "naturelle" imposée par le basic natif du msx.
En effet, lorsqu'on souhaite afficher une succession de bribes horizontales (pour un scroll vertical donc) épaisses de 8 pixels, on tombe systématiquement avec une demie bribes affichée sur la zone d'affichage "normale". La raison en est la suivante:
212/8= 26,5
Le problème reste le même lorsqu'on affiche des bribes épaisses de 8 pixels sur la zone "non habituelle" qui est haute de 44 pixels.
En effet si l'on divise 44/8= 5,5
Il y a bien une solution radicale qui consiste à basculer sur un affichage en 192 pixels (avec une zone non visible de 64 pixels).
Cela solutionne effectivement le problème des épaisseurs de 8 pixels de haut de chaque bribes.
Malgré tout, je pour d'autres raisons, je souhaite travailler avec des bribes de 4 pixels qui s'afficheront avec plus de fluidité que des bribes de 8.
J'essaie de finir quelques dessins d'ici ce soir, ce sera plus parlant
Oui et non
Pour scroller verticalement, j'utilise juste la commande vdp (24) puis je cache la bribe obsolète en y affichant la nouvelle bribes adéquate.
A partir de la, je suis condamné à couvrir l'intégralité des surface 212 + 44 ou encore 192 + 64.
Par contre je me demande si l'on peut appliquer le 60hz sur un screen matricé en 192 sans pour autant basculer sur un affichage matricé en 212!
L'avantage d'un screen matricé 192 en 60hz devrait être intéressant pour le petit gain de vitesse dans le défilement du scroll mais aussi dans l'utilisation de la "zone non visible" avec des commandes utilisant des multuples de 8 (à condition d'un scroll horizontal exclusivement) et ça c'est cool
Edité par
igal
Le 30/04/2017 à 14h34
Pour scroller verticalement, j'utilise juste la commande vdp (24) puis je cache la bribe obsolète en y affichant la nouvelle bribes adéquate.
A partir de la, je suis condamné à couvrir l'intégralité des surface 212 + 44 ou encore 192 + 64.
Par contre je me demande si l'on peut appliquer le 60hz sur un screen matricé en 192 sans pour autant basculer sur un affichage matricé en 212!
L'avantage d'un screen matricé 192 en 60hz devrait être intéressant pour le petit gain de vitesse dans le défilement du scroll mais aussi dans l'utilisation de la "zone non visible" avec des commandes utilisant des multuples de 8 (à condition d'un scroll horizontal exclusivement) et ça c'est cool
Edité par
igal
Le 30/04/2017 à 14h34
Voici 3 dessins qui vont me permettre de travailler sur un moteur de scroll par "PAS" de 4 pixels.
Voici comment j'envisage la chose
La mappe doit être découpée de la façon suivante:
1) Superficie de la mappe / (256*4) = nombre de bribes Horizontale permettant le scrolling vertical.
2) Superficie de la mappe / (256*4) = nombre de bribes Verticales permettant le scrolling Horizontal.
3) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Verticale du Scrolling Diagonal Gauche.
4) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Horizontale du scrolling diagonal Gauche.
5) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Verticale du scrolling Diagonal Droite.
6) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher le barre Horizontale du scrolling Diagonal Droite.
En définitive, chaque mappe doit être hachurée 6 fois pour pouvoir être exploité sur toute sa superficie par pas de 4 pixels dans 8 sens différents.
Soit 512 Bribes par axe pour une mappe faisant 1024X1024 Pixels
Soit 512 X 6 = 3072 Bribes au total. Edité par igal Le 30/04/2017 à 19h47
Voici comment j'envisage la chose
La mappe doit être découpée de la façon suivante:
1) Superficie de la mappe / (256*4) = nombre de bribes Horizontale permettant le scrolling vertical.
2) Superficie de la mappe / (256*4) = nombre de bribes Verticales permettant le scrolling Horizontal.
3) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Verticale du Scrolling Diagonal Gauche.
4) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Horizontale du scrolling diagonal Gauche.
5) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Verticale du scrolling Diagonal Droite.
6) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher le barre Horizontale du scrolling Diagonal Droite.
En définitive, chaque mappe doit être hachurée 6 fois pour pouvoir être exploité sur toute sa superficie par pas de 4 pixels dans 8 sens différents.
Soit 512 Bribes par axe pour une mappe faisant 1024X1024 Pixels
Soit 512 X 6 = 3072 Bribes au total. Edité par igal Le 30/04/2017 à 19h47
Si tu regardes le moteur de bribes en lui même, il est répétitif et répond à des règles simples et répétitives.
Je pense que le moteur de bribes peut être réduit à une ou deux lignes en réalité par AXE (12 lignes pour les 6 axes) mais j'ai pas les connaissances nécessaires pour faire ce que je veux et expliquer par écrit relève presque de l'impossible
Je pense que le moteur de bribes peut être réduit à une ou deux lignes en réalité par AXE (12 lignes pour les 6 axes) mais j'ai pas les connaissances nécessaires pour faire ce que je veux et expliquer par écrit relève presque de l'impossible
igal :
La mappe doit être découpée de la façon suivante:
1) Superficie de la mappe / (256*4) = nombre de bribes Horizontale permettant le scrolling vertical.
2) Superficie de la mappe / (256*4) = nombre de bribes Verticales permettant le scrolling Horizontal.
3) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Verticale du Scrolling Diagonal Gauche.
4) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Horizontale du scrolling diagonal Gauche.
5) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Verticale du scrolling Diagonal Droite.
6) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher le barre Horizontale du scrolling Diagonal Droite.
En définitive, chaque mappe doit être hachurée 6 fois pour pouvoir être exploité sur toute sa superficie par pas de 4 pixels dans 8 sens différents.
Soit 512 Bribes par axe pour une mappe faisant 1024X1024 Pixels.
Soit 512 X 6 = 3072 Bribes au total.
1) Superficie de la mappe / (256*4) = nombre de bribes Horizontale permettant le scrolling vertical.
2) Superficie de la mappe / (256*4) = nombre de bribes Verticales permettant le scrolling Horizontal.
3) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Verticale du Scrolling Diagonal Gauche.
4) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Horizontale du scrolling diagonal Gauche.
5) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher la barre Verticale du scrolling Diagonal Droite.
6) Superficie de la mappe / (256*4) = nombre de bribes permettant d'afficher le barre Horizontale du scrolling Diagonal Droite.
En définitive, chaque mappe doit être hachurée 6 fois pour pouvoir être exploité sur toute sa superficie par pas de 4 pixels dans 8 sens différents.
Soit 512 Bribes par axe pour une mappe faisant 1024X1024 Pixels.
Soit 512 X 6 = 3072 Bribes au total.
Euh ... Non.
C'est beaucoup, beaucoup, beaucoup plus que ça.
Tu dois assurer un scrolling multidirectionnels par pas de 4 pixels, cela veut dire que tu dois avoir, pour chaque coordonnée (x,y) multiple de 4 dans ta map, une bribe horizontale et une bribe verticale pré-calculée. Et il y a 256x256 = 65536 coordonnées multiples de 4 dans ta map. Tu dois donc avoir 2x65536 = 131072 bribes.
Sachant qu'en SC8, une bribe horizontale prend 256x4 = 1024 octets et une bribe verticale prend 4x192 = 768 octets, tu auras donc besoin de 112 Mo de données graphiques ... Edité par Metalion Le 01/05/2017 à 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)
Salut metalion: la multidirectionnalité du scrolling n'est pas "ouverte" tous les 4 pixels mais tous les 256 pixels 
Un seul scroll horizontal par épaisseur de 256 pixels.
Un seul scroll vertical tous les 256 pixels de longueur.
Un seul scroll diagonal gauche tous les 256 pixels de long.
Un seul scroll diagonal droite tous les 256 pixels de long.
Tu vas me dire mais alors, ou est la liberté de "mouvement"?
La réponse est dans "la libération du sprite" depuis le centre de l'écran vers 7 autres directions mise à part la direction prise par le joueur lors de l'apparition du hero!
Nb: le hero venant toujours d'une direction antérieur à son apparition dans un nouvel écran, cette "direction antérieur à sa nouvelle apparition" indique quel scroll unique sera utilisé quel que soit sa nouvelle direction prise!
La seule condition permettant un changement "subite de direction du scrolling" est la suivante.
Quel que soit le scroll de depart, il est impératif que le scroll en soit au centre d'une "page" Horizontale, vertical, diagonal droite", "diagonale gauche" pour permettre le changement de scroll dans n'importe quelle direction
En étant au centre d'une page, quelque soit le scroll initial, tous les autres scroll coïncident
Je suis en train de faire des dessins qui seront plus explicites que mes mots
Un seul scroll horizontal par épaisseur de 256 pixels.
Un seul scroll vertical tous les 256 pixels de longueur.
Un seul scroll diagonal gauche tous les 256 pixels de long.
Un seul scroll diagonal droite tous les 256 pixels de long.
Tu vas me dire mais alors, ou est la liberté de "mouvement"?
La réponse est dans "la libération du sprite" depuis le centre de l'écran vers 7 autres directions mise à part la direction prise par le joueur lors de l'apparition du hero!
Nb: le hero venant toujours d'une direction antérieur à son apparition dans un nouvel écran, cette "direction antérieur à sa nouvelle apparition" indique quel scroll unique sera utilisé quel que soit sa nouvelle direction prise!
La seule condition permettant un changement "subite de direction du scrolling" est la suivante.
Quel que soit le scroll de depart, il est impératif que le scroll en soit au centre d'une "page" Horizontale, vertical, diagonal droite", "diagonale gauche" pour permettre le changement de scroll dans n'importe quelle direction
En étant au centre d'une page, quelque soit le scroll initial, tous les autres scroll coïncident
Je suis en train de faire des dessins qui seront plus explicites que mes mots
OK.
Donc si je compte bien :
1) Un seul scroll horizontal par épaisseur de 256 pixels : 1024/4 x 4 = 1024 bribes
2) Un seul scroll vertical tous les 256 pixels de longueur : 1024/4 x 4 = 1024 bribes
3) Un seul scroll diagonal gauche tous les 256 pixels de long : (256/4 + 256/4) x 16 = 2048 bribes
4) Un seul scroll diagonal droite tous les 256 pixels de long : à mon avis, ce sont les même bribes que l'autre scroll diagonal, mais utilisées différemment.
Soit un total de 4096 bribes de 1024 octets chacune, soit 4 Mo. Edité par Metalion Le 02/05/2017 à 20h29
Donc si je compte bien :
1) Un seul scroll horizontal par épaisseur de 256 pixels : 1024/4 x 4 = 1024 bribes
2) Un seul scroll vertical tous les 256 pixels de longueur : 1024/4 x 4 = 1024 bribes
3) Un seul scroll diagonal gauche tous les 256 pixels de long : (256/4 + 256/4) x 16 = 2048 bribes
4) Un seul scroll diagonal droite tous les 256 pixels de long : à mon avis, ce sont les même bribes que l'autre scroll diagonal, mais utilisées différemment.
Soit un total de 4096 bribes de 1024 octets chacune, soit 4 Mo. Edité par Metalion Le 02/05/2017 à 20h29
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)
@Métalion: Comme promis, voici les dessins qui mettent en évidence la couverture totale de la mappe dans 4 axes (8 directions) possibles avec comme seule restriction de:
Nb: Manque inattention, j'ai bien identifié les bribes par "pas de 4" mais j'ai dessiné le dégradé des bribes par "pas de 8 pixels".
Pas grave...Pour ce coup ci, je continuerai donc à travailler par pas de 8 et j'afficherai la matrice du screen8 en [(192X256) + (64X256)] qui tombe juste avec des bribes épaisses de 8 pixels contrairement à la matrice en [212X256) + (44X256)] qui fait tomber à cheval la bribe devrant s'afficher depuis la ligne 208 à 216. La matrice s’arrêtant à 212, une partie de la bribe est perdue
Voici les dessins démontrant la couverture totale de la mappe quelle que soit l'axe de scroll choisi
Couverture totale de la mappe par pas de 8 pixels permettant le scroll Vertical.
Couverture totale de la mappe par pas de 8 pixels permettant le scroll Horizontal.
Couverture totale de la mappe par pas de 8 pixels permettant le scroll Diagonal Gauche "PARTIE BASSE" (doit être affichée par le moteur avec la "PARTIE DROITE")
Couverture totale de la mappe par pas de 8 pixels permettant le scroll digonal Gauche "PARTIE DROITE" (doit être affichée par le moteur avec la "PARTIE BASSE")
Couverture totale de la mappe par pas de 8 pixels permettant le scroll Diagonal Droite "PARTIE BASSE" (doit être affichée par le moteur avec la "PARTIE GAUCHE")
Couverture totale de la mappe par pas de 8 pixels permettant le scroll digonal Droite "PARTIE GAUCHE" (doit être affichée par le moteur avec la "PARTIE BASSE")
Voila donc pour se faire une idée du travail en amont nécessaire au déroulement des bribes
Nb: Manque inattention, j'ai bien identifié les bribes par "pas de 4" mais j'ai dessiné le dégradé des bribes par "pas de 8 pixels".
Pas grave...Pour ce coup ci, je continuerai donc à travailler par pas de 8 et j'afficherai la matrice du screen8 en [(192X256) + (64X256)] qui tombe juste avec des bribes épaisses de 8 pixels contrairement à la matrice en [212X256) + (44X256)] qui fait tomber à cheval la bribe devrant s'afficher depuis la ligne 208 à 216. La matrice s’arrêtant à 212, une partie de la bribe est perdue
Voici les dessins démontrant la couverture totale de la mappe quelle que soit l'axe de scroll choisi
Couverture totale de la mappe par pas de 8 pixels permettant le scroll Vertical.
Couverture totale de la mappe par pas de 8 pixels permettant le scroll Horizontal.
Couverture totale de la mappe par pas de 8 pixels permettant le scroll Diagonal Gauche "PARTIE BASSE" (doit être affichée par le moteur avec la "PARTIE DROITE")
Couverture totale de la mappe par pas de 8 pixels permettant le scroll digonal Gauche "PARTIE DROITE" (doit être affichée par le moteur avec la "PARTIE BASSE")
Couverture totale de la mappe par pas de 8 pixels permettant le scroll Diagonal Droite "PARTIE BASSE" (doit être affichée par le moteur avec la "PARTIE GAUCHE")
Couverture totale de la mappe par pas de 8 pixels permettant le scroll digonal Droite "PARTIE GAUCHE" (doit être affichée par le moteur avec la "PARTIE BASSE")
Voila donc pour se faire une idée du travail en amont nécessaire au déroulement des bribes
Donc si on additionne toutes tes bribes dessinées :
1) Scroll horizontal : (1024/8) x 4 = 512
2) Scroll vertical : (1024/8) x 4 = 512
3) Scroll diagonal 1 : (1024/8) x 4 = 512
4) Scroll diagonal 2 : (1024/8) x 4 = 512
5) Scroll diagonal 3 : (1024/8) x 4 = 512
6) Scroll diagonal 4 : (1024/8) x 4 = 512
On arrive à 3072 bribes de 2048 octets (256 x 8) chacune, soit un total de 6 Mo. Si tu passes à un scroll par pas de 4 pixels, on double le nombre de bribes, soit 6144, mais comme elles sont 2x moins lourdes, c'est pareil. Edité par Metalion Le 03/05/2017 à 16h26
1) Scroll horizontal : (1024/8) x 4 = 512
2) Scroll vertical : (1024/8) x 4 = 512
3) Scroll diagonal 1 : (1024/8) x 4 = 512
4) Scroll diagonal 2 : (1024/8) x 4 = 512
5) Scroll diagonal 3 : (1024/8) x 4 = 512
6) Scroll diagonal 4 : (1024/8) x 4 = 512
On arrive à 3072 bribes de 2048 octets (256 x 8) chacune, soit un total de 6 Mo. Si tu passes à un scroll par pas de 4 pixels, on double le nombre de bribes, soit 6144, mais comme elles sont 2x moins lourdes, c'est pareil. Edité par Metalion Le 03/05/2017 à 16h26
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)
Justement concernant les tailles des bribes, je suis en train de retravailler sur les "diagonales" épaisses de 4 pixels qui seront plus simples à mettre en oeuvres au moins pour celles à afficher horizontalement.
Concernant les bribes verticales, il y en a deux sortes.
1) celles qui permettent un scroll horizontal renouvelant l'image sur une ligne haute de 256 pixels de haut au totale mais composée en réalité de deux bribes verticales dont l'une mesure idéalement 192 et l'autre 64.
2) l'autre sorte de bribes verticales concerne celles des diagonales qui doivent répondre au même cahier des charges mais en plus, il faut que je trouve une solution pour que dans cette formule, j'ajoute la difficulté d'afficher une partie de la bribe sous la zone réservée, l'autre partie au dessus de la zone réservée et enfin la zone réservée elle même. En définitive pour simplifier la tâche il suffirait de procéder à 3 chargements de bribes pour une seule colonne haute de 256 pixels... pour éviter cela, je vais devoir faire chauffer la boîte à noeuds Rhône
Concernant les bribes verticales, il y en a deux sortes.
1) celles qui permettent un scroll horizontal renouvelant l'image sur une ligne haute de 256 pixels de haut au totale mais composée en réalité de deux bribes verticales dont l'une mesure idéalement 192 et l'autre 64.
2) l'autre sorte de bribes verticales concerne celles des diagonales qui doivent répondre au même cahier des charges mais en plus, il faut que je trouve une solution pour que dans cette formule, j'ajoute la difficulté d'afficher une partie de la bribe sous la zone réservée, l'autre partie au dessus de la zone réservée et enfin la zone réservée elle même. En définitive pour simplifier la tâche il suffirait de procéder à 3 chargements de bribes pour une seule colonne haute de 256 pixels... pour éviter cela, je vais devoir faire chauffer la boîte à noeuds Rhône
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie