La Place des Développeurs [RESOLU] VDP(27) le Scrolling hardware Horizontal Comment alimenter de nouveaux décors VDP (27)?
igal
Membre non connecté
Conseiller Municipal
Reprise du message précédent
Voici la matrice telle que je l'explique plus haut.BMP2MSX n'étant pas capable (a ma connaissance) de traiter des images en 256 X 256, il faut donc créer deux images différentes telles que:
A) Image contenant les Graphismes des pixels destinés aux lignes -44 à -1.
B) Image contenant les graphismes des pixels destinées aux lignes 0 à 212.
voici l'idée mise en pratique pour la création d'un Scrool d'une Map world de n'importe quel jeu
1) Je découpe des tranches alternativement de 44 pixels de Haut puis 212 pixels de haut.
Afin de les reconnaître aisément, je les nomme:
Page 0 -44 à -1
Page 0 1 à 255
Page 1 -44 à -1
Page 1 1 à 255
Page 2 -44 à -1
Page 2 1 à 255
Etc etc...
Voici l'image PAGE 0 -44 À -1
Voici l'image PAGE 0 0 A 212
Je tranche dans la mappe World comme dans un Gateau
2) Il ne reste plus qu'à traiter les images découpées avec BMP2MSX pour en faire des IMAGE.SCC en SCREEN12
3) Traiter les IMAGES.SCC de 256X212 pour en faire des Bribes d'images d'une superficie de 8 X 212.
(La bribe est en fait le résulta d'une soustraction d'une grande partie de l'image pour n'en laisser que "le bandeau qui nous interresse".
Le gros avantage de cette méthode étant qu'elle ne nécessite aucune coordonnée de COPIER ni de COLLER puisque seule la Bribe est visible et le reste est transparent.
Voici en gros ce que le BASIC applique à l'image:
Etc etc.....
(La partie banche est en réalité "Anéantie" une fois traitée sous Basic )
@Eric: J'attends vos idées pour la "génération automatique" des noms de fichiers à charger
De mon coté,je me demande si une simple boucle du genre:
Code TEXT :
10 BLOAD"A"+"B"+"C"+"D"+"E"+"F"+"G".SCC",S 20 G=G+1 and 10: F=G/10: E=F/10: D=E/10: C=D/10: B=C/10: A=B/10
C'est juste une idée
Voici les commandes qui couvrent la zone des lignes -44 à -1
Edité par igal Le 08/09/2014 à 20h53
igal
Membre non connecté
Conseiller Municipal
Voici le contenu du générateur de Bribes sous Basic:
Les lignes 94 à 99 vont charger la Page nommée 00000000.SCC et la fractionner en 5 bribes de 8X256 et 1 bribe de 4 X 256.
Ces 6 Bribes seront chargées chronologiquement une à une avec les commandes:
10 BLOAD"00000000.SCC",S,0-44
20 BLOAD"00000001.SCC",S,0-36
30 BLOAD"00000002.SCC",S,0-28
Etc etc...
Evidemment pour donner l'illusion d'un Scrolling, après chaque Bribe affichée, il faut faire suivre par la commande Suivante:
........... VDP (24) = VDP(24) + 8 AND 255
Encore un peu plus de détailles.
Les pages sont donc des successions de Pages de 44 X 256 suivi d'une page de 212 X 256.
Voici l'image PAGE 0 -44 À -1
Voici l'image PAGE 0 0 A 212
Le problème est que si l'addition des deux Pages fait bien un total de 256 X 256, le VDP ne peut ingérer que:
44 X 256 sur la partie originellement réservée aux Sprites à savoir les lignes 0-44 (Lisez Zéro moins 44) à 0-1 (Lisez Zéro Moins 1).
Donc...sachant que les Bribes ont la (mauvaise) taille de 8 Pixels de haut, on doit donc décomposer tel que...
44 = 8 X 5 Bribes normales + 1 Bribes de 4 Pixels seulement! (la sixième et dernière bribe créée par le générateur fait bien 4 pixel de haut!)
Pour la page "Normale" puisqu'elle fait 212 Pixels de haut et les bribes faisant la aussi la (mauvaise) taille de 8 Pixels de haut, il faut aussi décomposer tel que:
212 = 8 X 25 Bribes normales + 1 Bribe de 4 Pixels seulement ( La vingt sixième bribe créée par le générateur fait bien 4 Pixels de Haut!)
Notez au passage qu'une bribe (ou image quelconque) qui prend naissance dans la zone située entre -44 à -1 ne peut pas "s'étaler" sur la zone allant de la ligne 0 à 255.
De la même façon, un bribe (ou image quelconque) qui prend naissance dans la zone entre 0 et 255 ne peut pas "s'étaler" sur la zonne allant de la ligne -1 à -44.
Comme vous pouvez le voir sur cette vidéo, la solution Simple mais radicale permet de consiste à COPIER / COLLER un partie de l'image visible à l'écran.
Vous remarquerez qu'en empiétant qu'en partie seulement de la Zone réservée (-0 à -44), on peut continuer à utiliser des "Sprtites"
http://youtu.be/UXV-3OdZI8c
Rien n’empêche d'y intégrer d'autre graphismes en réalité
GDX quant à lui avait donné la solution suivante pour contourner pour afficher des graphismes sur cette zone:
http://youtu.be/O0FxC7Kc1as
Code TEXT :
15 'generateur de 24 strates (0 a 23) de 8*256 pixels 20 SCREEN 12 30 'BLOAD"00000000.scc",S 35 'GOTO 35 94 BLOAD"00000000.scc",S: BSAVE"10000000.scc",256*0,256*8-1,S 95 BLOAD"00000000.scc",S: BSAVE"10000001.scc",256*8,256*16-1,S 96 BLOAD"00000000.scc",S: BSAVE"10000002.scc",256*16,256*24-1,S 97 BLOAD"00000000.scc",S: BSAVE"10000003.scc",256*24,256*32-1,S 98 BLOAD"00000000.scc",S: BSAVE"10000004.scc",256*32,256*40-1,S 99 BLOAD"00000000.scc",S: BSAVE"10000005.scc",256*40,256*44-1,S 100 BLOAD"00000001.scc",S: BSAVE"10000006.scc",256*0,256*8-1,S 101 BLOAD"00000001.scc",S: BSAVE"10000007.scc",256*8,256*16-1,S 102 BLOAD"00000001.scc",S: BSAVE"10000008.scc",256*16,256*24-1,S 103 BLOAD"00000001.scc",S: BSAVE"10000009.scc",256*24,256*32-1,S 104 BLOAD"00000001.scc",S: BSAVE"10000010.scc",256*32,256*40-1,S 105 BLOAD"00000001.scc",S: BSAVE"10000011.scc",256*40,256*48-1,S 106 BLOAD"00000001.scc",S: BSAVE"10000012.scc",256*48,256*56-1,S 107 BLOAD"00000001.scc",S: BSAVE"10000013.scc",256*56,256*64-1,S 108 BLOAD"00000001.scc",S: BSAVE"10000014.scc",256*64,256*72-1,S 109 BLOAD"00000001.scc",S: BSAVE"10000015.scc",256*72,256*80-1,S 110 BLOAD"00000001.scc",S: BSAVE"10000016.scc",256*80,256*88-1,S 111 BLOAD"00000001.scc",S: BSAVE"10000017.scc",256*88,256*96-1,S 112 BLOAD"00000001.scc",S: BSAVE"10000018.scc",256*96,256*104-1,S 113 BLOAD"00000001.scc",S: BSAVE"10000019.scc",256*104,256*112-1,S 114 BLOAD"00000001.scc",S: BSAVE"10000020.scc",256*112,256*120-1,S 115 BLOAD"00000001.scc",S: BSAVE"10000021.scc",256*120,256*128-1,S 116 BLOAD"00000001.scc",S: BSAVE"10000022.scc",256*128,256*136-1,S 117 BLOAD"00000001.scc",S: BSAVE"10000023.scc",256*136,256*144-1,S 118 BLOAD"00000001.scc",S: BSAVE"10000024.scc",256*144,256*152-1,S 119 BLOAD"00000001.scc",S: BSAVE"10000025.scc",256*152,256*160-1,S 120 BLOAD"00000001.scc",S: BSAVE"10000026.scc",256*160,256*168-1,S 121 BLOAD"00000001.scc",S: BSAVE"10000027.scc",256*168,256*176-1,S 122 BLOAD"00000001.scc",S: BSAVE"10000028.scc",256*176,256*184-1,S 123 BLOAD"00000001.scc",S: BSAVE"10000029.scc",256*184,256*192-1,S 124 BLOAD"00000001.scc",S: BSAVE"10000030.scc",256*192,256*200-1,S 125 BLOAD"00000001.scc",S: BSAVE"10000031.scc",256*200,256*208-1,S 126 BLOAD"00000001.scc",S: BSAVE"10000032.scc",256*208,256*212-1,S
Les lignes 94 à 99 vont charger la Page nommée 00000000.SCC et la fractionner en 5 bribes de 8X256 et 1 bribe de 4 X 256.
Ces 6 Bribes seront chargées chronologiquement une à une avec les commandes:
10 BLOAD"00000000.SCC",S,0-44
20 BLOAD"00000001.SCC",S,0-36
30 BLOAD"00000002.SCC",S,0-28
Etc etc...
Evidemment pour donner l'illusion d'un Scrolling, après chaque Bribe affichée, il faut faire suivre par la commande Suivante:
........... VDP (24) = VDP(24) + 8 AND 255
Encore un peu plus de détailles.
Les pages sont donc des successions de Pages de 44 X 256 suivi d'une page de 212 X 256.
Voici l'image PAGE 0 -44 À -1
Voici l'image PAGE 0 0 A 212
Le problème est que si l'addition des deux Pages fait bien un total de 256 X 256, le VDP ne peut ingérer que:
44 X 256 sur la partie originellement réservée aux Sprites à savoir les lignes 0-44 (Lisez Zéro moins 44) à 0-1 (Lisez Zéro Moins 1).
Donc...sachant que les Bribes ont la (mauvaise) taille de 8 Pixels de haut, on doit donc décomposer tel que...
44 = 8 X 5 Bribes normales + 1 Bribes de 4 Pixels seulement! (la sixième et dernière bribe créée par le générateur fait bien 4 pixel de haut!)
Pour la page "Normale" puisqu'elle fait 212 Pixels de haut et les bribes faisant la aussi la (mauvaise) taille de 8 Pixels de haut, il faut aussi décomposer tel que:
212 = 8 X 25 Bribes normales + 1 Bribe de 4 Pixels seulement ( La vingt sixième bribe créée par le générateur fait bien 4 Pixels de Haut!)
Notez au passage qu'une bribe (ou image quelconque) qui prend naissance dans la zone située entre -44 à -1 ne peut pas "s'étaler" sur la zone allant de la ligne 0 à 255.
De la même façon, un bribe (ou image quelconque) qui prend naissance dans la zone entre 0 et 255 ne peut pas "s'étaler" sur la zonne allant de la ligne -1 à -44.
Comme vous pouvez le voir sur cette vidéo, la solution Simple mais radicale permet de consiste à COPIER / COLLER un partie de l'image visible à l'écran.
Vous remarquerez qu'en empiétant qu'en partie seulement de la Zone réservée (-0 à -44), on peut continuer à utiliser des "Sprtites"
http://youtu.be/UXV-3OdZI8c
Rien n’empêche d'y intégrer d'autre graphismes en réalité
GDX quant à lui avait donné la solution suivante pour contourner pour afficher des graphismes sur cette zone:
http://youtu.be/O0FxC7Kc1as
Code TEXT :
Edité par
igal
Le 09/09/2014 à 13h39
10 SCREEN8:I=0 20 VDP(9)=VDP(9)OR2 'sprites OFF 30 GOSUB120:GOSUB110 40 YD=212 50 IF VDP(-2)AND 1 THEN50 60 VDP(35)=Y:VDP(36)=1:VDP(37)=0:VDP(38)=0:VDP(39)=YD:VDP(40)=0:VDP(41)=255:VDP(42)=1:VDP(43)=1:VDP(44)=0:VDP(46)=0:VDP(47)=&HE0 70 VDP(24)=VDP(24)+1 AND255:Y=Y+1:YD=YD+1 AND255 80 IF Y=212 THEN GOSUB110 90 IF STRIG(0)THEN END 100 GOTO50 110 SETPAGE,1:CLS:Y=0 120 FORI=1TO10:CIRCLE(127,105),12*RND(1)*I,I:NEXT 130 'BLOAD"IMAGE"+RIGHT$(STR$(I),LEN(STR$(I))-1)+".SC8",S:I=(I+1)mod17 140 SETPAGE,0:RETURN
MSXlegend
Membre non connecté
Conseiller Municipal
igal
Membre non connecté
Conseiller Municipal
Voici ce que cela donne avec les graphismes de Battle Backraid.
http://youtu.be/KZ27ggIED34
Comme vous pouvez le voir, à mesure que le Chiffres qui détermine le fichier à charger augmente, les temps sont de plus en plus long!
Pour bien montrer que le ralentissement ne vient pas de la somme des graphismes à charger mais bien de "l'appellation du fichier avec un grand nombre", j'ai fais un GOTO pour reprendre le chargement depuis le premier fichier et on voit bien que le processus accélère!
Je dois donc trouver la meilleur solution pour "Appeler" les fichier le plus rapidement possible de de manière constante!
J'ai pensé qu'en donnant un nom d'une seule et unique longueur à tous les fichiers à savoir 12345678.SCC tous les fichiers mettraient un temps identique à être retrouvés/chargés..
A suivre...
Merde alors!
La vidéo est trop courte, on voit pas le scrolling
Demain je ré posterai ça si j'ai le temps Edité par igal Le 09/09/2014 à 19h43
http://youtu.be/KZ27ggIED34
Comme vous pouvez le voir, à mesure que le Chiffres qui détermine le fichier à charger augmente, les temps sont de plus en plus long!
Pour bien montrer que le ralentissement ne vient pas de la somme des graphismes à charger mais bien de "l'appellation du fichier avec un grand nombre", j'ai fais un GOTO pour reprendre le chargement depuis le premier fichier et on voit bien que le processus accélère!
Je dois donc trouver la meilleur solution pour "Appeler" les fichier le plus rapidement possible de de manière constante!
J'ai pensé qu'en donnant un nom d'une seule et unique longueur à tous les fichiers à savoir 12345678.SCC tous les fichiers mettraient un temps identique à être retrouvés/chargés..
A suivre...
Merde alors!
La vidéo est trop courte, on voit pas le scrolling
Demain je ré posterai ça si j'ai le temps Edité par igal Le 09/09/2014 à 19h43
igal :
Vous remarquerez qu'en empiétant qu'en partie seulement de la Zone réservée (-0 à -44), on peut continuer à utiliser des "Sprtites"
Tu peux aussi tout simplement déplacer la zone des sprites ailleurs dans la VRAM pour pouvoir travailler dans TOUTE la zone 256x256. Il suffit d'utiliser la commande BASE.
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
Je savais pas du tout que l'on pouvait "deplacer" la zone réservée aux spirites. Si on peut la mettre sur la page 1 au lieu de la page zéro ce serait le summum.
A ce sujet, je me suis toujours demandé si l'on pouvait dessiner simplement le héros sur la zone de Sprite pour le créer le plus simplement du monde.
Pour ce qui est du scrool, je vais essayer de renommer les fichiers en hexadécimal et voir si c'est plus rapide.
Une fois que le résulta sera satisfaisant, je passerai à des Bribes de 4×256 au lieu de 8 X 256.
Cela devrait simplifier la boucle principale puisque cette fois, toutes les bribes auront la même taille.
A ce sujet, je me suis toujours demandé si l'on pouvait dessiner simplement le héros sur la zone de Sprite pour le créer le plus simplement du monde.
Pour ce qui est du scrool, je vais essayer de renommer les fichiers en hexadécimal et voir si c'est plus rapide.
Une fois que le résulta sera satisfaisant, je passerai à des Bribes de 4×256 au lieu de 8 X 256.
Cela devrait simplifier la boucle principale puisque cette fois, toutes les bribes auront la même taille.
ericb59
Membre non connecté
Conseiller Municipal
Igal j'ai toujours pas vu ce que ça donnait... La video du dessus ne montre que le listing !
Sinon, ajoute au début de ton programme DEFINT A-Z
pour forcer à n'utiliser que des nombre entiers dans les calculs. Ca peut accélérer le process
Sinon, ajoute au début de ton programme DEFINT A-Z
pour forcer à n'utiliser que des nombre entiers dans les calculs. Ca peut accélérer le process
igal
Membre non connecté
Conseiller Municipal
Désolé, mon PC est au magasin. Du coup entre les courgettes, les poireaux et autres Cucurbitaceae, j'ai pas bcp de temps à y consacrer. J'ai pas eu le temps de vérifier la vidéo
Il s'agit en fait du défilement de la map du stage 2 ou 3 du jeu Battle Backraid.
Le scrool est composé de 164 bribes de 8×256 pixels.
Les premiers fichiers sont lus assez rapidement mais après une vingtaines de bribes chargées, le temps de lecture/trouvaille? Des fichiers est de plus en plus long.
Avoir créer une ligne basic par fichier à charger nous permet de savoir que la lenteur n'est pas dans la "creation/génération du nom" qui ralentie le processus, mais plutôt le temps que met le msx à retrouver/chercher le fichier à charger!
On peut donc penser que ce n'est pas la complexité de la formule permettant de créer le nom de fichier qui prend du temps mais plutôt le format utilisé pour nommer le fichier.
Vais voir ça avec la méthode de GDX!
Il s'agit en fait du défilement de la map du stage 2 ou 3 du jeu Battle Backraid.
Le scrool est composé de 164 bribes de 8×256 pixels.
Les premiers fichiers sont lus assez rapidement mais après une vingtaines de bribes chargées, le temps de lecture/trouvaille? Des fichiers est de plus en plus long.
Avoir créer une ligne basic par fichier à charger nous permet de savoir que la lenteur n'est pas dans la "creation/génération du nom" qui ralentie le processus, mais plutôt le temps que met le msx à retrouver/chercher le fichier à charger!
On peut donc penser que ce n'est pas la complexité de la formule permettant de créer le nom de fichier qui prend du temps mais plutôt le format utilisé pour nommer le fichier.
Vais voir ça avec la méthode de GDX!
igal :
Désolé, mon PC est au magasin. Du coup entre les courgettes, les poireaux et autres Cucurbitaceae, j'ai pas bcp de temps à y consacrer. J'ai pas eu le temps de vérifier la vidéo
Il s'agit en fait du défilement de la map du stage 2 ou 3 du jeu Battle Backraid.
Le scrool est composé de 164 bribes de 8×256 pixels.
Les premiers fichiers sont lus assez rapidement mais après une vingtaines de bribes chargées, le temps de lecture/trouvaille? Des fichiers est de plus en plus long.
Avoir créer une ligne basic par fichier à charger nous permet de savoir que la lenteur n'est pas dans la "creation/génération du nom" qui ralentie le processus, mais plutôt le temps que met le msx à retrouver/chercher le fichier à charger!
On peut donc penser que ce n'est pas la complexité de la formule permettant de créer le nom de fichier qui prend du temps mais plutôt le format utilisé pour nommer le fichier.
Vais voir ça avec la méthode de GDX!
Il s'agit en fait du défilement de la map du stage 2 ou 3 du jeu Battle Backraid.
Le scrool est composé de 164 bribes de 8×256 pixels.
Les premiers fichiers sont lus assez rapidement mais après une vingtaines de bribes chargées, le temps de lecture/trouvaille? Des fichiers est de plus en plus long.
Avoir créer une ligne basic par fichier à charger nous permet de savoir que la lenteur n'est pas dans la "creation/génération du nom" qui ralentie le processus, mais plutôt le temps que met le msx à retrouver/chercher le fichier à charger!
On peut donc penser que ce n'est pas la complexité de la formule permettant de créer le nom de fichier qui prend du temps mais plutôt le format utilisé pour nommer le fichier.
Vais voir ça avec la méthode de GDX!
D’où l’intérêt de n'ouvrir qu'un fichier et de se balader dedans à l'aide d'un index.... c'est ce que j'expliquais dans mon précédant post...
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
igal :
Je savais pas du tout que l'on pouvait "deplacer" la zone réservée aux sprites. Si on peut la mettre sur la page 1 au lieu de la page zéro ce serait le summum.
Il te suffit d'utiliser la commande BASE.
Comme tu utilises le SCREEN12, je suppose donc que tu es en MSX2+.
Il faudrait voir quels sont les paramètres de la commande pour le SCREEN12, je ne les connais que pour le MSX2.
igal :
A ce sujet, je me suis toujours demandé si l'on pouvait dessiner simplement le héros sur la zone de Sprite pour le créer le plus simplement du monde.
Absolument pas.
Pour la simple raison que l'encodage des sprites dans la VRAM est différent de celui des pixels affichés.
igal :
Pour ce qui est du scrool, je vais essayer de renommer les fichiers en hexadécimal et voir si c'est plus rapide.
Non. Il y a probablement une différence avec la longueur du nom, mais les caractères utilisés n'ont strictement aucune influence.
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 :
Il te suffit d'utiliser la commande BASE.
Comme tu utilises le SCREEN12, je suppose donc que tu es en MSX2+.
Il faudrait voir quels sont les paramètres de la commande pour le SCREEN12, je ne les connais que pour le MSX2.
igal :
Je savais pas du tout que l'on pouvait "deplacer" la zone réservée aux sprites. Si on peut la mettre sur la page 1 au lieu de la page zéro ce serait le summum.
Il te suffit d'utiliser la commande BASE.
Comme tu utilises le SCREEN12, je suppose donc que tu es en MSX2+.
Il faudrait voir quels sont les paramètres de la commande pour le SCREEN12, je ne les connais que pour le MSX2.
Cela doit être certainement BASE(63) pour la localisation de la TAS et BASE(64) pour celle de la TGS.
Essaie BASE(63)=&h10000 et BASE(64)=&h10000+2048 pour placer les deux tables de sprites en page 1.
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...
J'entend bien vos remarques les amis et je garde ça sous le coude pour plus tard
(J'ai bien noté Z80 )
J'ai besoin de votre aide pour le problème suivant.
Pour la conversion du stage 1 de OutZone de Toaplan, j'ai besoin de générer 594 Bribes d'images.
Voici la map originale:
Mon générateur de Bribes est extrêmement rudimentaire au point ou j'utilise une ligne par chaque bribe d'image à créer.
Il est tellement grands en octets (40Ko env) que lorsque je souhaite le charger sur MSX, j'obtiens un OUT OF MEMORY!
Pouvez vous m'aider à créer les boucles nécessaires afin de réduire la taille du programme?
Attention: Pour qu'il reste très malléable à mes expérimentations futurs, je ne veux surtout pas trop le réduire.
Voici le générateur de bribes (très simple et répétitif) GENERAT.ASC
Edité par igal Le 11/09/2014 à 14h30
J'entend bien vos remarques les amis et je garde ça sous le coude pour plus tard
(J'ai bien noté Z80 )
J'ai besoin de votre aide pour le problème suivant.
Pour la conversion du stage 1 de OutZone de Toaplan, j'ai besoin de générer 594 Bribes d'images.
Voici la map originale:
Mon générateur de Bribes est extrêmement rudimentaire au point ou j'utilise une ligne par chaque bribe d'image à créer.
Il est tellement grands en octets (40Ko env) que lorsque je souhaite le charger sur MSX, j'obtiens un OUT OF MEMORY!
Pouvez vous m'aider à créer les boucles nécessaires afin de réduire la taille du programme?
Attention: Pour qu'il reste très malléable à mes expérimentations futurs, je ne veux surtout pas trop le réduire.
Voici le générateur de bribes (très simple et répétitif) GENERAT.ASC
Edité par igal Le 11/09/2014 à 14h30
igal :
Pouvez vous m'aider à créer les boucles nécessaires afin de réduire la taille du programme?
594 lignes de BASIC pour créer 594 fichiers, tu as fait fort igal
(et en plus tu charges l'image source à chaque ligne, ce qui n'est vraiment pas nécessaire ...)
Code :
10 'SAVE"generat.asc",A
15 'generateur de bribes d'images [(8x256x5)+(4x256x1)]+[(8x256x26)+(4x256x1)]
20 SCREEN 12
30 'BLOAD"00000000.scc",S
35 'GOTO 35
40 DEFINT B,C,I,Y:C=0
45 FOR I=0TO17
50 IF (IAND1)=0 THEN B=4 ELSE B=25
55 SOURCE$=STRING$(9-LEN(STR$(I)),"0")+MID$(STR$(I),2):BLOAD SOURCE$,S
60 FOR Y=0 TO B*8 STEP 8
65 DEST$="1"+STRING$(8-LEN(STR$(C),"0")+MID$(STR$(C),2):BSAVE DEST$,256*Y,256*(Y+8)-1,S
70 C=C+1:NEXT Y
75 DEST$="1"+STRING$(8-LEN(STR$(C),"0")+MID$(STR$(C),2):BSAVE DEST$,256*Y,256*(Y+4)-1,S
80 C=C+1:NEXT I
Et voilà Edité par Metalion Le 11/09/2014 à 15h50
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)
d'aprés pratique du MSX2 on peut déplacer les sprites en haut de la mémoire
le registre 5 ou vdp(6) combiné a 2 bits du registre 11 permet de reloger la TAS entre 0 et 1F800
le registre 6 ou vdp(7) permet de reloger la TGS entre 0 et 1F800
pour les détails pages 136 137 de pratique du MSX2
le registre 5 ou vdp(6) combiné a 2 bits du registre 11 permet de reloger la TAS entre 0 et 1F800
le registre 6 ou vdp(7) permet de reloger la TGS entre 0 et 1F800
pour les détails pages 136 137 de pratique du MSX2
igal
Membre non connecté
Conseiller Municipal
Les Copier Coller m'ont filé un gros mal de tronche lol
Bref...Voici une petite vidéo de OUTZONE:
(J'ai créé les Bribes sans les programme de Métalion!)
http://youtu.be/dF28oYovr9E
Forcément, comme j'ai découpé mon programme GENRAT.ASC (de 40 ko), le scrool est incomplet pour le moment
@Z80: Pour rappel:
Les bribes d'images sont affichées sans avoir besoin de déterminer de coordonnées.
Par de coordonnées au chargement, ni de coordonnées à l'affichage.
Le but de la manoeuvre était de trouver une solution à l'affichage de graphismes en continue sans avoir bsoin de localiser de Zones à aucun moment!
Le principe de la "Bribe d'image" permet cela grâce au "Néant" contenu dans l'image qui en fait une "bribe".
Au final, je souhaiterai faire des "bribes" de 4 pixels pour les raisons suivantes:
1) En partant d'un Point ZERO, on peut afficher autant de bribes que l'on souhaite sans se soucier de tomber "à cheval" entre une zone [-1 à -44] et la zone [0 à 255]
2) En ayant à charger une "bribe" de 4X256", le Bus MSX sera sollicité 2 fois plus mais "rendra la main" 2 fois plus souvent qu'avec des bribes de 8X256 pixels.
3) L'idée au final est de déplacer un SPRITE de 4 en 4 en utilisant comme boucle Principale VDP(24)=VDP(24)-4AND255
Pour faire simple, j'espère faire quelque chose un peu comme cela, mais avec les graphisme quasi illimités en SCREEN12 avec un SCROOL vertical et des SPRITES qui font PAN PAN lol
http://youtu.be/UXV-3OdZI8c
Est ce qu'en créant le "Méga-fichier" dont tu parles, on pourra profiter des "vides" qui font parties intégrante des "Bribes" et ainsi ne pas avoir à donner d'adresse de départ et arrivée?
Peux tu nous en dire plus? Edité par igal Le 11/09/2014 à 17h08
Bref...Voici une petite vidéo de OUTZONE:
(J'ai créé les Bribes sans les programme de Métalion!)
http://youtu.be/dF28oYovr9E
Forcément, comme j'ai découpé mon programme GENRAT.ASC (de 40 ko), le scrool est incomplet pour le moment
@Z80: Pour rappel:
Les bribes d'images sont affichées sans avoir besoin de déterminer de coordonnées.
Par de coordonnées au chargement, ni de coordonnées à l'affichage.
Le but de la manoeuvre était de trouver une solution à l'affichage de graphismes en continue sans avoir bsoin de localiser de Zones à aucun moment!
Le principe de la "Bribe d'image" permet cela grâce au "Néant" contenu dans l'image qui en fait une "bribe".
Au final, je souhaiterai faire des "bribes" de 4 pixels pour les raisons suivantes:
1) En partant d'un Point ZERO, on peut afficher autant de bribes que l'on souhaite sans se soucier de tomber "à cheval" entre une zone [-1 à -44] et la zone [0 à 255]
2) En ayant à charger une "bribe" de 4X256", le Bus MSX sera sollicité 2 fois plus mais "rendra la main" 2 fois plus souvent qu'avec des bribes de 8X256 pixels.
3) L'idée au final est de déplacer un SPRITE de 4 en 4 en utilisant comme boucle Principale VDP(24)=VDP(24)-4AND255
Pour faire simple, j'espère faire quelque chose un peu comme cela, mais avec les graphisme quasi illimités en SCREEN12 avec un SCROOL vertical et des SPRITES qui font PAN PAN lol
http://youtu.be/UXV-3OdZI8c
Est ce qu'en créant le "Méga-fichier" dont tu parles, on pourra profiter des "vides" qui font parties intégrante des "Bribes" et ainsi ne pas avoir à donner d'adresse de départ et arrivée?
Peux tu nous en dire plus? Edité par igal Le 11/09/2014 à 17h08
igal :
Est ce qu'en créant le "Méga-fichier" dont tu parles, on pourra profiter des "vides" qui font parties intégrante des "Bribes" et ainsi ne pas avoir à donner d'adresse de départ et arrivée?
On ne comprends pas toujours ce que tu veux dire ou ce que tu veux faire, igal ...
Je pense que ce que voulais expliquer z80, c'est qu'au lieu de créer 594 fichiers, tu peux aussi charger directement dans le fichier d'origine les morceaux dont tu as besoin. Le principe est de dire au BASIC : j'ouvre le fichier untel et une fois qu'il est ouvert en lecture, je charge uniquement la partie de Y à Y+7, puis uniquement la partie Y+8 à Y+15, etc ...
Par contre, je ne suis pas sur que ce soit plus rapide ... C'est même probablement plus lent, car chaque commande BASIC ne charge qu'un octet à la fois.
Tu peux m'envoyer la disquette par MP ? Edité par Metalion Le 12/09/2014 à 10h43
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)
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie