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
ericb59 :
j'ai pas cette version... tu peux me la filer ?
j'ai essayé avec NestorBasic qui inclu un xbasic. sans doute pas la derniere version vu que ça me fait un syntax errot
Maggoo :
Au fait, Set scroll fonctionne avec le XBasic. Il faut juste utiliser la version Kun Basic Plus (specifique au 2+)
ericb59 :
non, tu te trompes.
Set scroll NE PEUX PAS être utilisé avec xbasic.
Set scroll NE PEUX PAS être utilisé avec xbasic.
Au fait, Set scroll fonctionne avec le XBasic. Il faut juste utiliser la version Kun Basic Plus (specifique au 2+)
j'ai pas cette version... tu peux me la filer ?
j'ai essayé avec NestorBasic qui inclu un xbasic. sans doute pas la derniere version vu que ça me fait un syntax errot
Et hop
http://www.romnation.net/srv/roms/26885/msx2/MSX-Basic-Kun-Plus-1988-Ascii-J.html
Merci !
J'ai testé, effectivement la commande set scroll ne produit plus de syntax error.
Par contre elle n'est pas plus rapide avec le XBASIC que sans...
Sans doute les limites du VDP ?
Toute fois pouvoir intégrer set scroll dans une procédure en TURBO peut se révéler utile....
J'ai testé, effectivement la commande set scroll ne produit plus de syntax error.
Par contre elle n'est pas plus rapide avec le XBASIC que sans...
Sans doute les limites du VDP ?
Toute fois pouvoir intégrer set scroll dans une procédure en TURBO peut se révéler utile....
z80 :
Tu dois commencer par définir le mode d'écran (screen 4, screen 5, ...)
La taille des blocs (8*8, 16*16), la taille des map en blocs. Exemple une map d'un écran de haut et 4 écrans de large en blocs de 16*16 en screen 5:
(4*256)/16=64 blocs
(1*212)/16=13,25 -> 14 blocs
Il te faudra une table de 896 octets pour stocker toute ta map en blocs de 16*16.
Sur une page de screen 5 tu dessines tes blocs de base (ta bibliothèque de blocs de décor pour construire ton décor. En screen 5 tu peux stocker 208 blocs sur une page.
Donc par exemple tu charges tes blocs de base en page 1 et tu fera ton scrolling en page 0.
Pour initialiser ton écran en page 0. Tu fait deux boucle for/next imbriquées la première va de 0 à 13 (14 -1) et à l'intérieur de cette première boucle tu en fait une autre qui compte de 0 à 15 (16-1)
Soit un écran de 14 lignes de 16 blocs 16x16.
Boucle "L" de 0à 14
Boucle "C" de 0 à 15
Tu lis dans ta table le code du bloc b=table(l*16+c)
X1=(b and 15)*16:Y1=b and &hF0: copy (X1,Y1)-(X1+15,Y1+15),1to(c*16,l*16),0
Voilà un bon début.
La suite quand tu auras codé cette petite ébauche
igal :
@Z80: Un moteur (malléable) de jeu qui soit en Basic ou pas serait top 
MsxOsaure à fait un super moteur qui ne scroll pas les décors, mais qui convient parfaitement à un jeu d'aventure.
La petite vidéo que t'as posté donne vraiment envie
MsxOsaure à fait un super moteur qui ne scroll pas les décors, mais qui convient parfaitement à un jeu d'aventure.
La petite vidéo que t'as posté donne vraiment envie
Tu dois commencer par définir le mode d'écran (screen 4, screen 5, ...)
La taille des blocs (8*8, 16*16), la taille des map en blocs. Exemple une map d'un écran de haut et 4 écrans de large en blocs de 16*16 en screen 5:
(4*256)/16=64 blocs
(1*212)/16=13,25 -> 14 blocs
Il te faudra une table de 896 octets pour stocker toute ta map en blocs de 16*16.
Sur une page de screen 5 tu dessines tes blocs de base (ta bibliothèque de blocs de décor pour construire ton décor. En screen 5 tu peux stocker 208 blocs sur une page.
Donc par exemple tu charges tes blocs de base en page 1 et tu fera ton scrolling en page 0.
Pour initialiser ton écran en page 0. Tu fait deux boucle for/next imbriquées la première va de 0 à 13 (14 -1) et à l'intérieur de cette première boucle tu en fait une autre qui compte de 0 à 15 (16-1)
Soit un écran de 14 lignes de 16 blocs 16x16.
Boucle "L" de 0à 14
Boucle "C" de 0 à 15
Tu lis dans ta table le code du bloc b=table(l*16+c)
X1=(b and 15)*16:Y1=b and &hF0: copy (X1,Y1)-(X1+15,Y1+15),1to(c*16,l*16),0
Voilà un bon début.
La suite quand tu auras codé cette petite ébauche
J'ai pensé à une autre approche.
0 screen 12
10 set page ,0
20 bload"image.scc",s (Les 16 premières lignes seulement)
30 vdp (24)=vdp(24)-1 and 256.
40 goto 20
Comment limiter le bload dîné image.scc aux 16 premières lignes seulement?
Merci de votre aide.
Demain j'essaie de poster un vidéo entre deux kg de tomates lol Edité par igal Le 30/08/2014 à 23h30
Tout simplement en faisant un bsave que des 16 premières lignes !
Bsave"xxxx.yyy",A,B
A=adresse de début si mes souvenirs sont bons
B=longueur à enregistré
Longueur c'est le nombre d'octets par ligne multiplié par le nombre de lignes
En screen 12: 256*16
Bsave"xxxx.yyy",A,B
A=adresse de début si mes souvenirs sont bons
B=longueur à enregistré
Longueur c'est le nombre d'octets par ligne multiplié par le nombre de lignes
En screen 12: 256*16
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,...
BSAVE j'y ai pensé aussi mais je me demande si l'on peut obtenir une "fraction d'image" identique mais en traitant des centaines d'images par paquet avec bmp2msx.
Autrement il faut que j'automatise l'opération sous basic.
Avant cela, je dois procéder à quelques testés afin de voir si la bride d'image.scc faisant 16 lignes seulement ne va pas malgré tout écraser l'image déjà construite à l'écran sur les lignes 17 à 212!
Si c'est le cas (j'espère pas) alors c'est foutu!
Le but de la manoeuvre est de charger flux de bribes d'images épaisse de 16 pixels seulement.
Le nombre restreint de pixels contenus dans les 16 lignes de la bride d'image à charger devrait laisser suffise ment de bande passante sur le bus msx pour envisager jouer une musique et même des copies d'écran de la page 1 à la page 0 pour créer des faut spirites.
Si ça tient la route alors on pourra faire défiler des scrool magnifiques en screen 12
Ce matin j'ai créé les 13 segments d'images converties avec bmp2msx . Il me reste à BSAVE chaque image.ssc en bribes et voir si ça tient la route.
Autrement il faut que j'automatise l'opération sous basic.
Avant cela, je dois procéder à quelques testés afin de voir si la bride d'image.scc faisant 16 lignes seulement ne va pas malgré tout écraser l'image déjà construite à l'écran sur les lignes 17 à 212!
Si c'est le cas (j'espère pas) alors c'est foutu!
Le but de la manoeuvre est de charger flux de bribes d'images épaisse de 16 pixels seulement.
Le nombre restreint de pixels contenus dans les 16 lignes de la bride d'image à charger devrait laisser suffise ment de bande passante sur le bus msx pour envisager jouer une musique et même des copies d'écran de la page 1 à la page 0 pour créer des faut spirites.
Si ça tient la route alors on pourra faire défiler des scrool magnifiques en screen 12
Ce matin j'ai créé les 13 segments d'images converties avec bmp2msx . Il me reste à BSAVE chaque image.ssc en bribes et voir si ça tient la route.
Je veux charger un flux d'image en screen 12 mais dont la taille fait 16 pixels de haut et 256 pixels de longs.
Le problème c'est que pour faire un BLOAD ultra rapide, il faut charger un tout petit fichier. Ici le fichier est une fraction d'image en screen12 a savoir 16 x 256.
Pour creer une fraction dimage il faut faire un BSAVE"image.scc", (debut de la zone vram a sauver), nombre d'octets à sauver.
Une fois les segments d'images créés il suffit de les bload en les empilant les un au es sus des autres et de scrooler le tout avec vdp (24)=vdp (24)-1 AND 255.
J'essaie de faire une vidéo pour la fin de la semaine
Edité par
igal
Le 31/08/2014 à 20h51
Le problème c'est que pour faire un BLOAD ultra rapide, il faut charger un tout petit fichier. Ici le fichier est une fraction d'image en screen12 a savoir 16 x 256.
Pour creer une fraction dimage il faut faire un BSAVE"image.scc", (debut de la zone vram a sauver), nombre d'octets à sauver.
Une fois les segments d'images créés il suffit de les bload en les empilant les un au es sus des autres et de scrooler le tout avec vdp (24)=vdp (24)-1 AND 255.
J'essaie de faire une vidéo pour la fin de la semaine
Edité par
igal
Le 31/08/2014 à 20h51
si je comprend bien tu veux faire une page écran avec des bandes de 16x256 pixel les uns en dessous des autres ?
BANDE 1
------------
BANDE 2
-------------
BDAN 3
--------------
etc ...........
----------------
pourquoi tu ne fais pas ça avec des COPY ?
BANDE 1
------------
BANDE 2
-------------
BDAN 3
--------------
etc ...........
----------------
pourquoi tu ne fais pas ça avec des COPY ?
Un copy signifie que tu as prechargé une page entière (donc long).
Copy occupe le vdp de la zone de départ + coordonnées vers zone d'arrivée + coordonnées.
Une page prechargé limite la variété du décors à la superficie de la page mise en mémoire.
Alors que ma methode (si elle fonctionne) permet de charger une infinité de décors.
Un simple bload d'une page qui ne pèse et ne mesure que bribes de page (16 x 256)
Ça reste qu'une idée mais on verra bien.
Copy occupe le vdp de la zone de départ + coordonnées vers zone d'arrivée + coordonnées.
Une page prechargé limite la variété du décors à la superficie de la page mise en mémoire.
Alors que ma methode (si elle fonctionne) permet de charger une infinité de décors.
Un simple bload d'une page qui ne pèse et ne mesure que bribes de page
(16 x 256)Ça reste qu'une idée mais on verra bien.
je sais pas expérience que tout ce qui touche au loading depuis le lecteur de disquette occupe pas mal le processeur... En tout cas ça provoque toujours (d'après mon expérience) des ralentissements, (inclus la musique !). Je pense qu'il vaut mieux précharger en mémoire ce dont tu as besoin.
Il s'agit de charger des centaines des bribes donc sur compact flash au moins
Pour ce qui est de BLOAD ou COPY, je verrai dans la pratique ce qui convient le mieux.
Peut être même un mix des deux commandes si ça fluidifie les temps d'occupation du BUS
Si tu cherches dans mes vidéos, tu trouveras une expérimentation
Voici une vidéo ou je charge [1 x 256 x 212 en screen 12 + musique opl4 FM+Wav] par seconde simultanément en basic!
http://youtu.be/UigcyoFEre8
Edité par igal Le 01/09/2014 à 09h25
Pour ce qui est de BLOAD ou COPY, je verrai dans la pratique ce qui convient le mieux.
Peut être même un mix des deux commandes si ça fluidifie les temps d'occupation du BUS
Voici une vidéo ou je charge [1 x 256 x 212 en screen 12 + musique opl4 FM+Wav] par seconde simultanément en basic!
http://youtu.be/UigcyoFEre8
Edité par igal Le 01/09/2014 à 09h25
voila..
J'ai commencé gentiment, j'ai donc procédé comme suit:
1) J'ai découpé une image en screen 12 par blocs horizontaux de 16 lignes avec BMP2MSX
2) j'ai LOAD puis BSAVE les Images avec la formule suivante: BSAVE"IMAGE.SCC",0,255X16,S de sorte à créer des Bribes d'images de 16 lignes en SCREEN12
3) J'ai créer le loader que voici:
J'arrive à charger les images nommées:
10000001.SCC
10000002.SCC
10000003.SCC
10000004.SCC
10000005.SCC
10000006.SCC
10000007.SCC
10000008.SCC
10000009.SCC
Par contre, pas moyen des charger les fichiers suivants:
10000010.SCC
10000011.SCC
10000012.SCC
10000013.SCC
J'avais déjà rencontré ce problème avec la méthode de Jipe..
Il avait fallut nommé les fichier avec CINQ caractères seulement et cela créé une forte latence dans la recherche des fichiers à charger automatiquement!
Avec la méhode de Jipe, les 10 ou premières images étaient très longues a charger alors que la 11ième et plus allaient bcp plus vite
si quelqu’un a une solution
http://youtu.be/CdBTtwSujSE
J'ai commencé gentiment, j'ai donc procédé comme suit:
1) J'ai découpé une image en screen 12 par blocs horizontaux de 16 lignes avec BMP2MSX
2) j'ai LOAD puis BSAVE les Images avec la formule suivante: BSAVE"IMAGE.SCC",0,255X16,S de sorte à créer des Bribes d'images de 16 lignes en SCREEN12
3) J'ai créer le loader que voici:
J'arrive à charger les images nommées:
10000001.SCC
10000002.SCC
10000003.SCC
10000004.SCC
10000005.SCC
10000006.SCC
10000007.SCC
10000008.SCC
10000009.SCC
Par contre, pas moyen des charger les fichiers suivants:
10000010.SCC
10000011.SCC
10000012.SCC
10000013.SCC
J'avais déjà rencontré ce problème avec la méthode de Jipe..
Il avait fallut nommé les fichier avec CINQ caractères seulement et cela créé une forte latence dans la recherche des fichiers à charger automatiquement!
Avec la méhode de Jipe, les 10 ou premières images étaient très longues a charger alors que la 11ième et plus allaient bcp plus vite
si quelqu’un a une solution
http://youtu.be/CdBTtwSujSE
- 1 renome tes fichiers en hexa
1xxxxxx1.scc
1xxxxxx2.scc
...
1xxxxxxA.scc
1xxxxxxB.scc
2- utilise cette formule
LD$="1xxxxxx"+MID$(hex$(N),2,1):BLOAD LD$,S,0
Autre solution, tu mets les noms des fichiers à charger dans une ligne de DATA
et tu lis les data Edité par ericb59 Le 02/09/2014 à 20h46
1xxxxxx1.scc
1xxxxxx2.scc
...
1xxxxxxA.scc
1xxxxxxB.scc
2- utilise cette formule
LD$="1xxxxxx"+MID$(hex$(N),2,1):BLOAD LD$,S,0
Autre solution, tu mets les noms des fichiers à charger dans une ligne de DATA
et tu lis les data Edité par ericb59 Le 02/09/2014 à 20h46
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie