La Place des Développeurs [RESOLU] VDP(27) le Scrolling hardware Horizontal Comment alimenter de nouveaux décors VDP (27)?
@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
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
Edité par
z80
Le 14/12/2013 à 21h48
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,...
z80 :
C'est mon téléphone qui a déconné...
ericb59 :
Z80 bégaye 
C'est mon téléphone qui a déconné...
On peut effacer ces propres posts !
z80 :
Tu dois commencer par définir le mode d'écran (screen 4, screen 5, ...)
En screen 4, c'est forcément 8x8. Et puis comme je le dis plus haut le cache du scroll horizontal ne fait que 8 lignes d'épaisseur donc les blocs 16x16 ne sont pas vraiment appropriés.
De toutes façon, tu t'emballes un peux vite.
igal est assez vague sur ce qu'il demande. Il n'indique même pas le sens du scroll désiré. J'ai cru comprendre qu'il veut connaitre le fonctionnement, c'est pour ça que je n'ai fait qu'un scroll de base. Il parle de faire une démo puis après un jeu, c'est pour dire.
igal :
MsxOsaure à fait un super moteur qui ne scroll pas les décors, mais qui convient parfaitement à un jeu d'aventure.
Quelle est la différence avec ce que j'ai proposé ?
Merci de ton offre Z80.
En fait je voudrais avoir une approche différente de ce que l'on rencontre tout le temps a savoir...
1) Je pose un décor.
2) Je copy le décors en le déplaçant d'un pixel.
3) Je pose des sprites. + déplacement des sprites.
5) Je déplace le Sprite du héro selon mes inputs.
Je voudrais essayer plutot ceci:
1) Je pose un décors que je scroll avec VDP(27)=VDP(27)+1AND255
2) Je pose des sprites. + déplacement des sprites. (affitionné d'une baleur contraire au mouvement induit par le VDP (27))
4) Je déplace le Sprite de héro selon mes inputs. (additionné d'une valeur contraire au mouvement induit par VDP(27))
Voici un vidéo qui ne fait que faire "Coulisser" le SCREEN MSX.
Nb: Le sprite n'est pas encore valorisé pour contrecarrer VDP(27) ce qui explique pourquoi il recule en même temps que le décors!
http://youtu.be/OKNXQYbYcAM
Voici la disquette qui contient le programme.
Il s'agit d'une version du moteur Winnie de MsxOsaure retouchée par l'excellent et regrété Stapha. Peut être qu'un jour il reviendra
SPACEMANBOW STAPHA.zip
Le fichier se nomme Winnie.bas
Pour voir si le concept tient la route, il faut que je trouve le moyen de maintenir le Sprite à coutre courant au lieu de le laisser défiler en arrière avec le reste de l'écran. (Faut que je replonge dans les variables )
Edit:
On peut combiner avec VDP(24) avec VDP(27) pour obtenir un scroll multidirectionnel avec trois fois rien
http://youtu.be/nv0rG3fa8Xk
: Edité par igal Le 05/02/2014 à 05h39
En fait je voudrais avoir une approche différente de ce que l'on rencontre tout le temps a savoir...
1) Je pose un décor.
2) Je copy le décors en le déplaçant d'un pixel.
3) Je pose des sprites. + déplacement des sprites.
5) Je déplace le Sprite du héro selon mes inputs.
Je voudrais essayer plutot ceci:
1) Je pose un décors que je scroll avec VDP(27)=VDP(27)+1AND255
2) Je pose des sprites. + déplacement des sprites. (affitionné d'une baleur contraire au mouvement induit par le VDP (27))
4) Je déplace le Sprite de héro selon mes inputs. (additionné d'une valeur contraire au mouvement induit par VDP(27))
Voici un vidéo qui ne fait que faire "Coulisser" le SCREEN MSX.
Nb: Le sprite n'est pas encore valorisé pour contrecarrer VDP(27) ce qui explique pourquoi il recule en même temps que le décors!
http://youtu.be/OKNXQYbYcAM
Voici la disquette qui contient le programme.
Il s'agit d'une version du moteur Winnie de MsxOsaure retouchée par l'excellent et regrété Stapha. Peut être qu'un jour il reviendra
SPACEMANBOW STAPHA.zip
Le fichier se nomme Winnie.bas
Pour voir si le concept tient la route, il faut que je trouve le moyen de maintenir le Sprite à coutre courant au lieu de le laisser défiler en arrière avec le reste de l'écran. (Faut que je replonge dans les variables
)Edit:
On peut combiner avec VDP(24) avec VDP(27) pour obtenir un scroll multidirectionnel avec trois fois rien
http://youtu.be/nv0rG3fa8Xk
: Edité par igal Le 05/02/2014 à 05h39
Je ne suis pas certain que tu puisses compenser le mouvement du scorll pour faire en sorte que ton/tes sprites restent immobiles à l'écran.
En tout cas… pas sans saccade.
En tout cas… pas sans saccade.
C'est bien ce que je pensais. Trop coloré pour un sprite sauf si utilisation du bit OR... Et de mémoire les sprites n'étaient pas impactés par l'utilisation du scrolling hardware...
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,...
ericb59 :
Mais si on ajoute à ça le mouvement généré par un utilisateur sur son joystick… les coordonnées du bout de décors qu'il vas falloir afficher sous le sprite vont être plus compliquées à calculer… Et faire ça en une trame en basic… chapeau à celui qui y arrive… 
Ce n'est pas ça le plus compliqué mais c'est de faire quelque chose d'assez rapide pour rester syncho et de gérer tous les énemies avec les sprites tout en restant assez colorés et avec le moins de clignolement possible. Et puis faut faire ça de A à Z et trouver des musiques et bruitages sympa. Rien que pour les graphismes, sur MSX, c'est comme faire un grand puzzle. Edité par GDX Le 05/02/2014 à 13h47
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie