La Place des Développeurs moteur de jeu en basic création, optimisation
Reprise du message précédent
Encore une optimisation ? Ok, si c'est un ORDRE...
Etudions les 3 lignes suivantes :
340 COPY(X,Y)-(X+34,Y+45),2TO(0,0),3
350 COPY(D,A)-(D+25,A+37),1TO(4,4),3,TPSET
360 COPY(0,0)-(34,45),3TO(X,Y),0
L'instruction COPY est utilisée 3 fois. Comment fonctionne-t-elle ? Et bien l'interpréteur basic calcule une série de valeurs à placer dans les registres du VDP et lance la copie. C'est le VDP et non le Z80 qui réalise cette copie. Et dès que c'est lancé, l'interpréteur passe à l'instruction suivante sans attendre que le VDP ait terminé (j'ai fait des tests de vitesse qui l'ont confirmé). C'est un très bon point pour le basic MSX !
Mais que ce passe-t-il si l'instruction suivante est un COPY (ou une autre instruction qui sera exécutée par le VDP, comme LINE ou PSET) ? N'y a-t-il pas risque de gener le VDP en accédant à ces registres alors qu'il est en train de travailler ? Ou est-ce que le traitement que le VDP était en train de faire est interrompu ?
Heureusement rien de tout ça. Et pour l'eviter c'est très simple : à chaque instruction qui fait appel au VDP, l'interpréteur attend que la commande en cours soit terminée (s'il y en a une) pour envoyer la suivante.
Donc, quand on enchaine 2 COPY, il y a des moments ou le Z80 ne fait rien du tout. Dommage de perdre du temps comme ça... Alors que c'est facilement évitable : il suffit de glisser des instructions entre les COPY ! Avec un COPY qui traiterait tout l'écran, on aurait le temps d'en faire plusieurs. Mais avec ces 3 COPY, une seule suffira.
J'ai donc réagencé la boucle principale ainsi :
Code :
310 NX=X+DX(STICK(0)):NY=Y+DY(STICK(0))
320 IFCO(NX/4+6,(NY+34)/16)THENX=NX:Y=NY
330 COPY(X,Y)-(X+34,Y+45),1TO(0,0),3:A=VA(STICK(0))
340 COPY(D,A)-(D+25,A+37),2TO(4,4),3,TPSET:D=(D+32)AND255
350 COPY(0,0)-(34,45),3TO(X,Y),0
360 ONAC((X+12)/16,Y/16+1)GOTO310,510,610,710,710,710,810
Cette fois la valeur de A est déterminé juste avant qu'on l'utilise et la valeur de D... juste après ! mais ce n'est pas grave : D est une variable qui boucle sur une série de valeur, donc ça ne change rien. A la limite c'est même plus cohérent : la première valeur de D qui sera utilisée est 0 alors qu'avant c'était 32. Mais visuellement ça ne change rien (si ça avait été le cas, il aurait suffit d'initialiser D à 32 en début de programme).
On a donc gagné du temps juste en changeant l'ordre des instructions....
Et après ? Peut-on encore optimiser ? Et bien oui, mais il va falloir changer le système d'affichage de Mario. C'est ce qu'on verra au prochain post...
Merci beaucoup Stapha pour tes lumières 
Je découvre à peine tes (lumineuses) explications. D'ailleurs, j'en profite pour remercier tous ceux qui donnent de leur temps de façon complètement désintéressée, et qui nous apportent tant.
Un coup de chapeau aussi à toute l'équipe de Msxvillage, je pense entre autres à Obélix, Jipe, Msxosaure et les autres ainsi qu'aux habitués que sont MsxLégend, Galine et bien d'autres, qui ont tous quelque chose à nous offrir que ce soit leurs expériences personnelle, ou leur savoir faire patiemment acquis.
Une bien bonne et heureuse année à vous tous
Un peu plus technique maintenant
@ Stapha:
Ton astuce concernant les [cycles CPU] "perdus" en attendant la "Digestion du COPY par le VDP" est un point que je trouve très intéressant et vais m'empresser de mettre en application.
Comme tu peux le voir ci dessous, j'avais modestement tenté et réussi à réduire le nombre de lignes en "éparpillant" les GOSUB sur la boucle Principale de WINNIE. Le résulta s'est bien fait sentir sur le gain de vitesse quant à l'animation du Héros.
J'ai eu beaucoup de mal à trouver "cet équilibre". J'ai toujours pensé que RETURN permettait le retour [Juste après] le GOSUB sur la même ligne, à tort puisqu'il renvoie à la ligne suivante.
Cette ligne par exemple est COMPLETEMENT interprété:
Alors que cette ligne ne sera PAS COMPLETEMENT interprété, puisque IFX..... étant après le GOSUB, il ne sera jamais lu.
C'est peut être évident pour vous, mais j'ai pas pour moi
Tu remarqueras que S=STICK est devenu Z=STICK. Ceci est due à ma tentative de greffon de ton code concernant ( N=N+1 ) que voici:
Mon intention étant de créer un SCROOLING en plein écran, tout en permettant l'interactivité de WINNIE, j'avais donc modifié de la sorte:
Ce code est fait de mémoire, j'ai malheureusement jeté le code qui fonctionnait. (fonctionnait mal, mais fonctionnait quand même lol)
Le problème principal venait de FORI = 0 TO 240 STEP 16 qui déplace donc des bloc de 16 et que j'ai réduit en FORI = 0 TO 240 STEP 1 qui déplace la page Pixel par Pixel, mais qui bloquait tout autres interactivité dans le même temps!
J'ai donc réduit à la plus simple expression à savoir => FOR I = 0 TO 1 STEP 1 qui déplace la page complète de [Deux Fois Un Pixel "ZERO et UN" et Rend La Main].
N'arrivant pas à mieux faire, j'ai jeté le code exacte
J'y reviendrais un prochaine fois...
J'ai bien compris que FOR I = 0 TO 255 STEP 1: NEXT I fait glisser une page Pixel par Pixel avec COPY sans traîne du bas de page très disgracieux. Malheureusement, il est impossible de bouger WINNIE dans le même temps!
J'ai bien compris que I = I + 1: IF I = 255 THEN I = 0 fait flisser la page Pixel par Pixel avec COPY mais créer un phénomène escalier disgracieux. Par contre, WINNIE reste accessible à tout moment!
J'aime beaucoup AND, j'ai déjà vu ça dans des Démo du genre F.A.C etc, sans avoir jamais compris le but! Aujourd'hui je sais
Il faut comprendre que AND est le Semi-additionneur logique comme en électronique!
On demande donc simplement à l'interpréteur de soumettre une comparaison [AND] de 32, 64, etc à 255! et que puisque le semi-addiitionneur ne retient que 1+1 = 1 et que tout le reste vaut 0, le tour est joué! lorsque l'ajout des 32 dépasse les 255, il revient donc à Zéro puisqu'il ne peut être logiquement comparé à plus grand que le comparateur lui même.
C'est juste???
C'est bizarre comme approche, mais ça marche
Je met tout ça en application et je soumettrai des exemples en images
Je découvre à peine tes (lumineuses) explications. D'ailleurs, j'en profite pour remercier tous ceux qui donnent de leur temps de façon complètement désintéressée, et qui nous apportent tant.
Un coup de chapeau aussi à toute l'équipe de Msxvillage, je pense entre autres à Obélix, Jipe, Msxosaure et les autres ainsi qu'aux habitués que sont MsxLégend, Galine et bien d'autres, qui ont tous quelque chose à nous offrir que ce soit leurs expériences personnelle, ou leur savoir faire patiemment acquis.
Une bien bonne et heureuse année à vous tous
Un peu plus technique maintenant
@ Stapha:
Ton astuce concernant les [cycles CPU] "perdus" en attendant la "Digestion du COPY par le VDP" est un point que je trouve très intéressant et vais m'empresser de mettre en application.
Comme tu peux le voir ci dessous, j'avais modestement tenté et réussi à réduire le nombre de lignes en "éparpillant" les GOSUB sur la boucle Principale de WINNIE. Le résulta s'est bien fait sentir sur le gain de vitesse quant à l'animation du Héros.
Code TEXT :
310 D=D+26:IFD=208THEND=52 320 Z=STICK(0):ONZ+1GOSUB1500,2000,2030,2500,2750,3000,3250,3500,3750:IFX=224THENX=4:N=N+1:GOSUB10000 330 COPY(X,Y)-(X+34,Y+50),2TO(0,0),3:COPY(D,A)-(D+25,A+37),1TO(4,4),3,TPSET:COPY(0,0)-(34,50),3TO(X,Y),0:P=POINT(INT((X+15)/16),202+INT((Y+4)/16)):IFP<11THENGOSUB5000 340 IFX=0THENX=220:N=N-1:GOSUB10000 350 GOTO 310
J'ai eu beaucoup de mal à trouver "cet équilibre". J'ai toujours pensé que RETURN permettait le retour [Juste après] le GOSUB sur la même ligne, à tort puisqu'il renvoie à la ligne suivante.
Cette ligne par exemple est COMPLETEMENT interprété:
Code TEXT :
340 IFX=0THENX=220:N=N-1:GOSUB10000
Alors que cette ligne ne sera PAS COMPLETEMENT interprété, puisque IFX..... étant après le GOSUB, il ne sera jamais lu.
Code TEXT :
340 GOSUB10000:IFX=0THENX=220:N=N-1:
C'est peut être évident pour vous, mais j'ai pas pour moi
Tu remarqueras que S=STICK est devenu Z=STICK. Ceci est due à ma tentative de greffon de ton code concernant ( N=N+1 ) que voici:
Code TEXT :
610 N=N+1:X=6:GOSUB910 620 S=2:FORI=0TO240STEP16:COPY(16,20)-(255,211),2-STO(0,20),S 630 COPY(I,0)-(I+15,191),3TO(240,20),S:SETPAGES:S=2-S 640 NEXT:COPY(0,20)-(255,211),0TO(0,20),2:SETPAGE0,0:GOTO310
Mon intention étant de créer un SCROOLING en plein écran, tout en permettant l'interactivité de WINNIE, j'avais donc modifié de la sorte:
Code TEXT :
309 S=2 310 D=D+26:IFD=208THEND=52 320 Z=STICK(0):ONZ+1GOSUB1500,2000,2030,2500,2750,3000,3250,3500,3750:IFX=224THENX=4:N=N+1:GOSUB10000 321 FORI=0TO1STEP1:COPY(2,20)-(255,211),2-STO(0,20),S:COPY(I,0)-(I+15,191),3TO(240,20),S:SETPAGES:S=2-S:COPY(0,20)-(255,211),0TO(0,20),2:SETPAGE0,0:NEXTI 330 COPY(X,Y)-(X+34,Y+50),2TO(0,0),3:COPY(D,A)-(D+25,A+37),1TO(4,4),3,TPSET:COPY(0,0)-(34,50),3TO(X,Y),0:P=POINT(INT((X+15)/16),202+INT((Y+4)/16)):IFP<11THENGOSUB5000 340 IFX=0THENX=220:N=N-1:GOSUB10000 350 GOTO 310
Ce code est fait de mémoire, j'ai malheureusement jeté le code qui fonctionnait. (fonctionnait mal, mais fonctionnait quand même lol)
Le problème principal venait de FORI = 0 TO 240 STEP 16 qui déplace donc des bloc de 16 et que j'ai réduit en FORI = 0 TO 240 STEP 1 qui déplace la page Pixel par Pixel, mais qui bloquait tout autres interactivité dans le même temps!
J'ai donc réduit à la plus simple expression à savoir => FOR I = 0 TO 1 STEP 1 qui déplace la page complète de [Deux Fois Un Pixel "ZERO et UN" et Rend La Main].
N'arrivant pas à mieux faire, j'ai jeté le code exacte
J'y reviendrais un prochaine fois...J'ai bien compris que FOR I = 0 TO 255 STEP 1: NEXT I fait glisser une page Pixel par Pixel avec COPY sans traîne du bas de page très disgracieux. Malheureusement, il est impossible de bouger WINNIE dans le même temps!
J'ai bien compris que I = I + 1: IF I = 255 THEN I = 0 fait flisser la page Pixel par Pixel avec COPY mais créer un phénomène escalier disgracieux. Par contre, WINNIE reste accessible à tout moment!
J'aime beaucoup AND, j'ai déjà vu ça dans des Démo du genre F.A.C etc, sans avoir jamais compris le but! Aujourd'hui je sais
Il faut comprendre que AND est le Semi-additionneur logique comme en électronique!
On demande donc simplement à l'interpréteur de soumettre une comparaison [AND] de 32, 64, etc à 255! et que puisque le semi-addiitionneur ne retient que 1+1 = 1 et que tout le reste vaut 0, le tour est joué! lorsque l'ajout des 32 dépasse les 255, il revient donc à Zéro puisqu'il ne peut être logiquement comparé à plus grand que le comparateur lui même.
C'est juste???
C'est bizarre comme approche, mais ça marche
Je met tout ça en application et je soumettrai des exemples en images
igal :
J'ai toujours pensé que RETURN permettait le retour [Juste après] le GOSUB sur la même ligne, à tort puisqu'il renvoie à la ligne suivante.
C'est faux !!
Le retour après une routine appelée par GOSUB se fait bien juste après l'instruction et non pas à la ligne suivante.
C'est facilement vérifiable avec ce petit programme, qui donne bien dans l'ordre : HELLO, GOSUB, RETOUR et STOP.
Code TEXT :
10 PRINT"HELLO" 20 GOSUB100:PRINT"RETOUR" 30 PRINT"STOP" 40 END 100 PRINT"GOSUB" 110 RETURN
Si les instructions après ton GOSUB ne s'exécutent pas, c'est que tu as un problème quelque part, mais ce n'est pas le GOSUB qui est en cause ...
Pour l'instruction AND, il agit effectivement comme la porte logique électronique du même nom. Mais je considère plutôt que c'est un filtre plutôt qu'un "semi-additionneur" : l'opérateur AND ne retient d'un nombre que les bits qui sont en face de ses propres bits mis à 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)
Metalion :
C'est exactement ça : le AND "nettoie"(c'est à dire qu'il remet à 0) les 8 bits de gauche et préserve les 8 de droite. Ce qui ne change rien dans tous les cas sauf quand D atteint 256. 256 en binaire s'écrit 0000 0001 0000 0000, ce qui devient 0000 0000 0000 0000 après le nettoyage.Pour l'instruction AND, il agit effectivement comme la porte logique électronique du même nom. Mais je considère plutôt que c'est un filtre plutôt qu'un "semi-additionneur" : l'opérateur AND ne retient d'un nombre que les bits qui sont en face de ses propres bits mis à 1.
Ton terme de "filtre" convient très bien. Tandis que celui de semi-additionneur pas du tout... Désolé Igal...
Edité par
Stapha
Le 15/01/2011 à 14h06
Metalion :
C'est faux !!
Le retour après une routine appelée par GOSUB se fait bien juste après l'instruction et non pas à la ligne suivante.
C'est facilement vérifiable avec ce petit programme, qui donne bien dans l'ordre : HELLO, GOSUB, RETOUR et STOP.
Si les instructions après ton GOSUB ne s'exécutent pas, c'est que tu as un problème quelque part, mais ce n'est pas le GOSUB qui est en cause ...
Pour l'instruction AND, il agit effectivement comme la porte logique électronique du même nom. Mais je considère plutôt que c'est un filtre plutôt qu'un "semi-additionneur" : l'opérateur AND ne retient d'un nombre que les bits qui sont en face de ses propres bits mis à 1.
igal :
J'ai toujours pensé que RETURN permettait le retour [Juste après] le GOSUB sur la même ligne, à tort puisqu'il renvoie à la ligne suivante.
C'est faux !!
Le retour après une routine appelée par GOSUB se fait bien juste après l'instruction et non pas à la ligne suivante.
C'est facilement vérifiable avec ce petit programme, qui donne bien dans l'ordre : HELLO, GOSUB, RETOUR et STOP.
Code TEXT :
10 PRINT"HELLO" 20 GOSUB100:PRINT"RETOUR" 30 PRINT"STOP" 40 END 100 PRINT"GOSUB" 110 RETURN
Si les instructions après ton GOSUB ne s'exécutent pas, c'est que tu as un problème quelque part, mais ce n'est pas le GOSUB qui est en cause ...
Pour l'instruction AND, il agit effectivement comme la porte logique électronique du même nom. Mais je considère plutôt que c'est un filtre plutôt qu'un "semi-additionneur" : l'opérateur AND ne retient d'un nombre que les bits qui sont en face de ses propres bits mis à 1.
Lut à tous, je dépoussière WINNIE en espérant un peu d'aide...
En effet, j'ai tjrs Su que Gosub a pour qualité de permettre une lecture à la suite de son instruction (à l'instar de GOTO), sous condition d'une rencontre avec Gosub.
En extrapolant comme je l'ai fait, j'en attendais plus une aide quant à solutionner ce problème redondant tout au long du programme!
En effet, tout au long du programme, certaines instruction sont éparpillées sur plusieurs lignes sans quoi, elle ne sont pas interprétés!
J'ai eu beaucoup de mal à le comprendre puisque pas logique!
Je vais reprendre pour exemple le point suivant:
301 ' Boucle Principale:variable D pour animation du heros
302 '
310 D=D+26:IFD=208THEND=52
420 S=STICK(0):ONS+1GOSUB1500,2000,2030,2500,2750,3000,3250,3500,3750
500 COPY(X,Y)-(X+34,Y+50),2TO(0,0),3:COPY(D,A)-(D+25,A+37),1TO(4,4),3,TPSET:COPY(0,0)-(34,50),3TO(X,Y),0:P=POINT(INT((X+15)/16),202+INT((Y+4)/16))
710 IFP<11THEN5000:' INVULNERABLE SI ELUDE
800 IFX=224THENX=4:N=N+1:GOSUB10000
810 IF X=0THENX=220:N=N-1:GOSUB10000
900 GOTO 310
Si je devais fusionner les lignes 800 et 810, le contenu de 810 se trouvant derrière GOSUB ne sera pas lu!
voici la disquette => ZELDAG.zip
Le programme est ZELDAVE.ASC
Pour le moment, les escaliers ne sont pas fonctionnels (un gros problème en perspective toujours à cause des GOSUB lol)! Je voudrais résoudre le pb des Gosub en premier!
Merci pour votre aide
Edité par
igal
Le 14/02/2011 à 17h30
igal :
Si je devais fusionner les lignes 800 et 810, le contenu de 810 se trouvant derrière GOSUB ne sera pas lu!
Code :
800 IFX=224THENX=4:N=N+1:GOSUB10000
810 IF X=0THENX=220:N=N-1:GOSUB10000
900 GOTO 310
Si je devais fusionner les lignes 800 et 810, le contenu de 810 se trouvant derrière GOSUB ne sera pas lu!
Sauf erreur de ma part (car mon BASIC est très rouillé
), si une condition IF ... THEN est remplie, le code se trouvant derrière le THEN est exécuté ... TOUT le code. Ce qui signifie que si tu fusionnes 800 et 810, le test IF X=0 ne sera pas exécuté si la condition précédente (IF X=224) est fausse.Su tu veux fusionner, tu devrais plutôt écrire :
Code :
800 IF X=224 THEN X=4:N=N+1:GOSUB10000 ELSE IF X=0 THEN X=220:N=N-1:GOSUB10000
900 GOTO 310
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)
Le problème du Gosub n'en est pas un en effet, Metalion t'a apporté la solution, attention aux instructions qui suivent les IF...THEN...ELSE... c'est un piège dans lequel on tombe facilement , surtout quand ils se multiplient sur une même ligne 
Pour le moteur je prépare quelque chose sous X-basic avec éditeur de carte, etc... Mais je manque de temps actuellement et je n'est pas trop étudier le projet aux départ ce qui provoque beaucoup de retour en arrière, donc ça va doucement ,d'ailleurs le problème des escaliers y est géré, Patience...
Pour le moteur je prépare quelque chose sous X-basic avec éditeur de carte, etc... Mais je manque de temps actuellement et je n'est pas trop étudier le projet aux départ ce qui provoque beaucoup de retour en arrière, donc ça va doucement
,d'ailleurs le problème des escaliers y est géré, Patience...
Le MSXien le plus à l'ouest
... ou presque 
Bonjour à tous,
Je viens de voir que ce topic n'était pas mort...
Bon, Igal, il est temps d'attaquer le double buffer...
Pour ceux qui ne le connaissent pas, c'est un système très simple :
on utilise 2 écrans de façon alternative : pendant qu'on dessine dans l'écran 1 on affiche l'écran 2. Quand le dessin est terminé, on affiche l'écran 1 et on dessine dans l'écran 2 et ainsi de suite...
Appliqué à Mario, ça donne :
- On efface le sprite de mario qui se trouve dans la page 1
- On calcule les nouvelles coordonnées de mario
- On affiche le sprite de mario à ces coordonnées dans la page 1
- On affiche la page 1
- On effectue une action spéciale s'il y a lieu (chute, objet, ..)
- On efface le sprite de mario qui se trouve dans la page 0
- On calcule les nouvelles coordonnées de mario
- On affiche le sprite de mario à ces coordonnées dans la page 0
- On affiche la page 0
- On effectue une action spéciale s'il y a lieu (chute, objet, ..)
- On retourne au début
Effacer le sprite de Mario consitera à redessiner le décor par dessus Mario. En assembleur, on pourrait redessiner les tiles qui sont sous Mario. Le problème est que nous sommes en BASIC et que cela prendrait trop de temps. La solution ? Très simple : on va utiliser une 3eme page. Cette page contiendra une copie complète du tableau affiché (y compris l'écran des scores). Ainsi il suffira de faire une copie depuis cette 3eme page vers l'écran en cours de dessin en prenant dans les 2 cas (source et destination) les coordonnées de Mario (pas les coordonnées actuelles, ce serait trop simple...)
Pour les coordonnées, on ne peut plus se contenter de les gérer avec 2 variables : il faut les coordonnées de Mario dans chaque page, donc 4 variables. Pour l'explication, on va appeler X0 et Y0 les coordonnées de Mario en page 0 et X1 et Y1 celles de la page 1. (heureusement qu'on efface le sprite AVANT de calculer les nouvelles coordonnées, sinon il faudrait 8 variables...).
Attention ! Lorsqu'on va calculer les coordonnées dans une page, il faudrait partir de celles de l'autre page. C'est simple à comprendre : Mario se trouve en (0,0) dans la page 0 et avance vers la droite, il va falloir le placer en (4,0) dans la page 1 puis en (8,0) dans la page 0 et ainsi de suite...
Reprenons la séquence :
- On copie depuis la page 3 vers la page 1 un rectangle qui se trouve aux coordonnées X1,Y1
- On ajoute à X0 et Y0 les valeurs qui correspondent au déplacement demandé et on met les résultats dans X1 et Y1.
- Si X1 et Y1 correspondent à une position que Mario ne peut pas occuper, on remplace leur valeur par celles de X0 et Y0.
- On copie le sprite de Mario dans la page 1 à la position X1,Y1
- On affiche la page 1
- On dirige vers la suite ou vers la gestion des actions spéciales s'il y en a
- On copie depuis la page 3 vers la page 0 un rectangle qui se trouve aux coordonnées X0,Y0
- On ajoute à X1 et Y1 les valeurs qui correspondent au déplacement demandé et on met les résultats dans X0 et Y0.
- Si X0 et Y0 correspondent à une position que Mario ne peut pas occuper, on remplace leur valeur par celles de X1 et Y1.
- On copie le sprite de Mario dans la page 0 à la position X0,Y0
- On affiche la page 0
- On retourne au début ou vers la gestion des actions spéciales s'il y en a
Evidemment, cette séquence fait 2 fois la même chose : il n'y a que la page et les variables qui changent. Encore une fois, en assembleur, on pourrait faire un traitement unique pour les 2 pages alors qu'en BASIC, il est beaucoup plus rentable que la boucle contienne 1 traitement pour chaque page.
On en profite pour regrouper le maximum d'instruction sur une même ligne. On ira pas jusqu'à la capacité maximum mais on s'arretera sur les "IF" ou les "ON GOTO" puisqu'il n'est pas possible de continuer un traitement après ce genre d'instruction sans passer à la ligne suivante.
On va également nommer les variables dédiées aux coordonnées différemment : ça sera X et X pour la page 0 et V et W pour la page 1.
Dernier point : le changement de page.
Logiquement, on devrait utiliser l'instruction SETPAGE. Le problème est que cette dernière est beaucoup trop longue (elle fait bien plus que le simple changement de page dont on a besoin). On va donc modifier nous même le registre du VDP qui permet d'obtenir ce changement.
Il s'agit du registre R2. Ce dernier permet d'indiquer l'adresse de départ de la TNP. Cette adresse est stockée sur 17 bits, ce qui permet d'accéder à 2 puissance 17 = 128 Ko de VRAM. Cependant ce registre ne contient que les 7 bits de poids fort de cette adresse, ce qui signifie qu'on ne peut indiquer qu'une adresse multiple de 1024. Tout se passe comme si on indiquait les 17 bits avec les 10 premiers toujours à 0.
Mais ça c'est pour la plupart des modes... Mais pas pour celui qu'on utilise ! En effet dans notre cas, on est obligé de mettre les 5 premiers bits à 1. Il nous reste donc 2 bits utilisables sur les 17 de l'adresse. 2 bits = 4 possibilités et comme il y a 4 pages disponibles, ça signifie qu'en SCREEN 5 les 4 pages sont fixes (et c'est vraiment dommage, car sinon ça aurait pu aider à faire des scrollings verticaux fluides très facilement...).
Donc quand on veut afficher la page 0, il faut écrire la valeur 00011111 (=31) dans R2 tandis que pour la page 1, il faut écrire 00111111 (=63).
Donc notre boucle principale devient
Il y a encore quelques optimisations (comme le calcul de l'élement du tableau C à récupérer qui s'est simplifié) mais rien qui n'est besoin d'être détaillé.
Notez que pour dessiner Mario, on n'utilise plus que 2 copy et que l'un d'eux est plus petit puisqu'il n'y a plus besoin de créer une marge de 4 pixel pour être certains d'effacer l'ancien sprite (ce qui réduit les problèmes de clipping). ça signifie aussi que si on augmente le pas de déplacement, il n'y a plus de problème (avec l'ancien système, il faut que la marge soit égale à ce pas).
Cette boucle ne sert à rien toute seule, voici donc une disquette avec le programme complet, l'image des sprite modifiée comme je l'avais expliqué précédemment et la portion d'image qui contient le panneau des scores.
MARIO FAT.zip
Pour les escaliers, il faut :
- Modifier l'initialisation du tableau K à la ligne 100 en mettant K(n) = 8 ou n est le numéro du tile qui représente les escaliers.
- Ajouter un numéro de ligne dans les 2 ON GOTO. Numéro de ligne qui contiendra le code qui modifiera les coordonnées de Mario.
Et c'est tout ! Il n'y aura pas besoin de gérer l'affichage de Mario puisqu'il n'y a plus d'obligation que 2 positions consécutives de Mario soient proches, contrairement à l'ancien système.
Et la boucle principale ne sera donc pas du tout ralentie... Edité par Stapha Le 18/03/2011 à 11h18
Je viens de voir que ce topic n'était pas mort...
Bon, Igal, il est temps d'attaquer le double buffer...
Pour ceux qui ne le connaissent pas, c'est un système très simple :
on utilise 2 écrans de façon alternative : pendant qu'on dessine dans l'écran 1 on affiche l'écran 2. Quand le dessin est terminé, on affiche l'écran 1 et on dessine dans l'écran 2 et ainsi de suite...
Appliqué à Mario, ça donne :
- On efface le sprite de mario qui se trouve dans la page 1
- On calcule les nouvelles coordonnées de mario
- On affiche le sprite de mario à ces coordonnées dans la page 1
- On affiche la page 1
- On effectue une action spéciale s'il y a lieu (chute, objet, ..)
- On efface le sprite de mario qui se trouve dans la page 0
- On calcule les nouvelles coordonnées de mario
- On affiche le sprite de mario à ces coordonnées dans la page 0
- On affiche la page 0
- On effectue une action spéciale s'il y a lieu (chute, objet, ..)
- On retourne au début
Effacer le sprite de Mario consitera à redessiner le décor par dessus Mario. En assembleur, on pourrait redessiner les tiles qui sont sous Mario. Le problème est que nous sommes en BASIC et que cela prendrait trop de temps. La solution ? Très simple : on va utiliser une 3eme page. Cette page contiendra une copie complète du tableau affiché (y compris l'écran des scores). Ainsi il suffira de faire une copie depuis cette 3eme page vers l'écran en cours de dessin en prenant dans les 2 cas (source et destination) les coordonnées de Mario (pas les coordonnées actuelles, ce serait trop simple...)
Pour les coordonnées, on ne peut plus se contenter de les gérer avec 2 variables : il faut les coordonnées de Mario dans chaque page, donc 4 variables. Pour l'explication, on va appeler X0 et Y0 les coordonnées de Mario en page 0 et X1 et Y1 celles de la page 1. (heureusement qu'on efface le sprite AVANT de calculer les nouvelles coordonnées, sinon il faudrait 8 variables...).
Attention ! Lorsqu'on va calculer les coordonnées dans une page, il faudrait partir de celles de l'autre page. C'est simple à comprendre : Mario se trouve en (0,0) dans la page 0 et avance vers la droite, il va falloir le placer en (4,0) dans la page 1 puis en (8,0) dans la page 0 et ainsi de suite...
Reprenons la séquence :
- On copie depuis la page 3 vers la page 1 un rectangle qui se trouve aux coordonnées X1,Y1
- On ajoute à X0 et Y0 les valeurs qui correspondent au déplacement demandé et on met les résultats dans X1 et Y1.
- Si X1 et Y1 correspondent à une position que Mario ne peut pas occuper, on remplace leur valeur par celles de X0 et Y0.
- On copie le sprite de Mario dans la page 1 à la position X1,Y1
- On affiche la page 1
- On dirige vers la suite ou vers la gestion des actions spéciales s'il y en a
- On copie depuis la page 3 vers la page 0 un rectangle qui se trouve aux coordonnées X0,Y0
- On ajoute à X1 et Y1 les valeurs qui correspondent au déplacement demandé et on met les résultats dans X0 et Y0.
- Si X0 et Y0 correspondent à une position que Mario ne peut pas occuper, on remplace leur valeur par celles de X1 et Y1.
- On copie le sprite de Mario dans la page 0 à la position X0,Y0
- On affiche la page 0
- On retourne au début ou vers la gestion des actions spéciales s'il y en a
Evidemment, cette séquence fait 2 fois la même chose : il n'y a que la page et les variables qui changent. Encore une fois, en assembleur, on pourrait faire un traitement unique pour les 2 pages alors qu'en BASIC, il est beaucoup plus rentable que la boucle contienne 1 traitement pour chaque page.
On en profite pour regrouper le maximum d'instruction sur une même ligne. On ira pas jusqu'à la capacité maximum mais on s'arretera sur les "IF" ou les "ON GOTO" puisqu'il n'est pas possible de continuer un traitement après ce genre d'instruction sans passer à la ligne suivante.
On va également nommer les variables dédiées aux coordonnées différemment : ça sera X et X pour la page 0 et V et W pour la page 1.
Dernier point : le changement de page.
Logiquement, on devrait utiliser l'instruction SETPAGE. Le problème est que cette dernière est beaucoup trop longue (elle fait bien plus que le simple changement de page dont on a besoin). On va donc modifier nous même le registre du VDP qui permet d'obtenir ce changement.
Il s'agit du registre R2. Ce dernier permet d'indiquer l'adresse de départ de la TNP. Cette adresse est stockée sur 17 bits, ce qui permet d'accéder à 2 puissance 17 = 128 Ko de VRAM. Cependant ce registre ne contient que les 7 bits de poids fort de cette adresse, ce qui signifie qu'on ne peut indiquer qu'une adresse multiple de 1024. Tout se passe comme si on indiquait les 17 bits avec les 10 premiers toujours à 0.
Mais ça c'est pour la plupart des modes... Mais pas pour celui qu'on utilise ! En effet dans notre cas, on est obligé de mettre les 5 premiers bits à 1. Il nous reste donc 2 bits utilisables sur les 17 de l'adresse. 2 bits = 4 possibilités et comme il y a 4 pages disponibles, ça signifie qu'en SCREEN 5 les 4 pages sont fixes (et c'est vraiment dommage, car sinon ça aurait pu aider à faire des scrollings verticaux fluides très facilement...).
Donc quand on veut afficher la page 0, il faut écrire la valeur 00011111 (=31) dans R2 tandis que pour la page 1, il faut écrire 00111111 (=63).
Donc notre boucle principale devient
Code :
310 COPY(V,W)-(V+25,W+35),3TO(V,W),1:A=VA(STICK(0)):V=X+DX(STICK(0)):W=Y+DY(STICK(0)):IFCO(V/4,(W+10)/16)THENV=X:W=Y
320 COPY(D,A)-(D+25,A+35),2TO(V,W),1,TPSET:D=(D+32)AND255:VDP(2)=63:ONAC((V+8)/16,(W+8)/16)GOTO330,510,610,710,710,710,810
330 COPY(X,Y)-(X+25,Y+35),3TO(X,Y),0:A=VA(STICK(0)):X=V+DX(STICK(0)):Y=W+DY(STICK(0)):IFCO(X/4,(Y+10)/16)THENX=V:Y=W
340 COPY(D,A)-(D+25,A+35),2TO(X,Y),0,TPSET:D=(D+32)AND255:VDP(2)=31:ONAC((X+8)/16,(Y+8)/16)GOTO310,510,610,710,710,710,810
Il y a encore quelques optimisations (comme le calcul de l'élement du tableau C à récupérer qui s'est simplifié) mais rien qui n'est besoin d'être détaillé.
Notez que pour dessiner Mario, on n'utilise plus que 2 copy et que l'un d'eux est plus petit puisqu'il n'y a plus besoin de créer une marge de 4 pixel pour être certains d'effacer l'ancien sprite (ce qui réduit les problèmes de clipping). ça signifie aussi que si on augmente le pas de déplacement, il n'y a plus de problème (avec l'ancien système, il faut que la marge soit égale à ce pas).
Cette boucle ne sert à rien toute seule, voici donc une disquette avec le programme complet, l'image des sprite modifiée comme je l'avais expliqué précédemment et la portion d'image qui contient le panneau des scores.
MARIO FAT.zip
Pour les escaliers, il faut :
- Modifier l'initialisation du tableau K à la ligne 100 en mettant K(n) = 8 ou n est le numéro du tile qui représente les escaliers.
- Ajouter un numéro de ligne dans les 2 ON GOTO. Numéro de ligne qui contiendra le code qui modifiera les coordonnées de Mario.
Et c'est tout ! Il n'y aura pas besoin de gérer l'affichage de Mario puisqu'il n'y a plus d'obligation que 2 positions consécutives de Mario soient proches, contrairement à l'ancien système.
Et la boucle principale ne sera donc pas du tout ralentie... Edité par Stapha Le 18/03/2011 à 11h18
Salut Stapha.
Cela fait très plaisir de lire tes posts si riches d'enseignement!
Avec un peu de temps je devrais assimiler et visualiser le mode de fonctionnement et ses subtilités.
J'avais travaillé sur quelques graphismes, que je voudrais implanter au moteur, mais j'ai besoin de tes sources graphiques de sorte à m'en servir comme gabarit.
Peux tu les poster s'il te plait!
Un petit détail mais de taille.
Est ce que MARIO se déplace de toutes parts parallèlement sur les pages non visibles? Ou alors, il reste confiné dans un coin de la page ou il est traité?
En d'autres mots, est ce que l'on peut utiliser en partie au moins, les pages non visibles de sorte à y stocker d'autres graphismes?
Merci.
Cela fait très plaisir de lire tes posts si riches d'enseignement!
Avec un peu de temps je devrais assimiler et visualiser le mode de fonctionnement et ses subtilités.
J'avais travaillé sur quelques graphismes, que je voudrais implanter au moteur, mais j'ai besoin de tes sources graphiques de sorte à m'en servir comme gabarit.
Peux tu les poster s'il te plait!
Un petit détail mais de taille.
Est ce que MARIO se déplace de toutes parts parallèlement sur les pages non visibles? Ou alors, il reste confiné dans un coin de la page ou il est traité?
En d'autres mots, est ce que l'on peut utiliser en partie au moins, les pages non visibles de sorte à y stocker d'autres graphismes?
Merci.
Hello.
@ Stapha: J'ai pu convertir la Matrice WINNIE.SC5 en WINNIE.BMP grâce au logiciel VIEWMSX
(Comme vous pouvez le voir, la palette graphique de FONDW et de WINNIE sont complètement différentes!)
Avec la bonne palette, ca devrait aller!
Malheureusement, étant donné que FONDW.SC5 (détails des niveaux) à été fusionné avec WINNIE.SC5, Il est m'impossible de reconvertir la matrice WINNIE.BMP en WINNIE.SC5 sans altérer la palette graphique.
J'ai donc besoin de la palette que tu as certainement enregistré dans => BMP2MSX/BMP2MSX.BM2 et BMP2MSX.CFG.
Actuellement, tous mes essais se soldent par un décor complètement incohérent!
Merci de poster les sources (si tu le veux bien )
Edité par
igal
Le 22/03/2011 à 09h41
@ Stapha: J'ai pu convertir la Matrice WINNIE.SC5 en WINNIE.BMP grâce au logiciel VIEWMSX
(Comme vous pouvez le voir, la palette graphique de FONDW et de WINNIE sont complètement différentes!)
Avec la bonne palette, ca devrait aller!
Malheureusement, étant donné que FONDW.SC5 (détails des niveaux) à été fusionné avec WINNIE.SC5, Il est m'impossible de reconvertir la matrice WINNIE.BMP en WINNIE.SC5 sans altérer la palette graphique.
J'ai donc besoin de la palette que tu as certainement enregistré dans => BMP2MSX/BMP2MSX.BM2 et BMP2MSX.CFG.
Actuellement, tous mes essais se soldent par un décor complètement incohérent!
Merci de poster les sources (si tu le veux bien
)
Edité par
igal
Le 22/03/2011 à 09h41
En fait, je n'ai pas de palette : j'ai créé MARIO.SC5 directement depuis le basic MSX...
j'ai essayé de l'ouvrir avec viewmsx et j'ai l'impression que la palette est correcte sauf pour la couleur 0 : elle devrait être identique à la couleur 4 (bzarre ça d'ailleurs...). A mon avis, tu n'as que celle là à modifier pour que tout rentre dans l'ordre.
Par contre, comme je l'ai expliqué, j'ai changé l'ordre des tiles afin de regrouper ceux qui entrainaient une action et j'ai adapté le détail des niveau avec un code du genre (de mémoire car je ne l'ai pas gardé...) :
Pour ta question précédente relative aux pages non visibles : hélas non, il n'en reste plus. Les pages 0 et 1 sont utilisées pour le double buffer, la page 2 pour les sprites et les décors et la page 3 pour stocker le tableau sans mario.
Mais tout espoir n'est pas perdu, il y a des alternatives :
- effacer Mario en redescinant les tiles 1 par 1. Dans ce cas on n'a plus besoin de la page 3. Avec un double buffer, l'effacement ne sera pas visble mais un problème demeure : il ralentira la boucle principale. A tester avec un basic compilé...
- réduire la taille de Mario à 16 pixels de large : ça nous fait récupérer près de la moitié de la page 2.
- réduire le nombre de dessins pour chaque animation de Mario et le faire passer de 8 à 4 : on gagne aussi près de la moitié de la page 2.
A mon avis, la 3eme solution est la meilleure. En effet, ça ne changerait pas grand chose à l'animation de Mario car les étapes sont souvent répétées.
Pour mettre en place cette solution, il faut définir les étapes sur les 4 premières colonne de Winnie et, dans la boucle principale, rempacer D=(D+32)AND255 par D=(D+32)AND127.
N'hésites pas à me solliciter si tu veux que j'adapte le code à tes besoins (escalier, chute, moins d'étapes d'animation, changement de largeur de Mario...) Edité par Stapha Le 28/03/2011 à 11h03
j'ai essayé de l'ouvrir avec viewmsx et j'ai l'impression que la palette est correcte sauf pour la couleur 0 : elle devrait être identique à la couleur 4 (bzarre ça d'ailleurs...). A mon avis, tu n'as que celle là à modifier pour que tout rentre dans l'ordre.
Par contre, comme je l'ai expliqué, j'ai changé l'ordre des tiles afin de regrouper ceux qui entrainaient une action et j'ai adapté le détail des niveau avec un code du genre (de mémoire car je ne l'ai pas gardé...) :
Code BASIC :
10 FORI=0TO255:FORJ=184TO195:P=POINT(I,J) 20 IFP>6THENIFP>10THENP=P-4ELSEP=P+5 30 PSET(I,J),P:NEXT:NEXT 40 BSAVE"Mario.sc5",0,30367,S
Pour ta question précédente relative aux pages non visibles : hélas non, il n'en reste plus. Les pages 0 et 1 sont utilisées pour le double buffer, la page 2 pour les sprites et les décors et la page 3 pour stocker le tableau sans mario.
Mais tout espoir n'est pas perdu, il y a des alternatives :
- effacer Mario en redescinant les tiles 1 par 1. Dans ce cas on n'a plus besoin de la page 3. Avec un double buffer, l'effacement ne sera pas visble mais un problème demeure : il ralentira la boucle principale. A tester avec un basic compilé...
- réduire la taille de Mario à 16 pixels de large : ça nous fait récupérer près de la moitié de la page 2.
- réduire le nombre de dessins pour chaque animation de Mario et le faire passer de 8 à 4 : on gagne aussi près de la moitié de la page 2.
A mon avis, la 3eme solution est la meilleure. En effet, ça ne changerait pas grand chose à l'animation de Mario car les étapes sont souvent répétées.
Pour mettre en place cette solution, il faut définir les étapes sur les 4 premières colonne de Winnie et, dans la boucle principale, rempacer D=(D+32)AND255 par D=(D+32)AND127.
N'hésites pas à me solliciter si tu veux que j'adapte le code à tes besoins (escalier, chute, moins d'étapes d'animation, changement de largeur de Mario...) Edité par Stapha Le 28/03/2011 à 11h03
Salut Stapha.
Alors voila. Je me suis penché sur le problème de la palette de MARIO FAT. Il semblerait qu'il ne soit plus possible de modifier la PALETTE GRAPHIQUE sous peine de voir l'ORDRE des COULEURS se MELANGER n'importe comment! Ce qui oblige à se limiter aux couleurs déjà existantes!
Logiquement, il devrait être possible de modifier les Valeurs R,G,B des couleurs, sans en changer leurs NUMEROS, mais je sais pas comment!
@ Msxosaure => Si tu sais tu si il est possible de forcer BMP2MSX à ne pas modifier la NUMEROTATION des couleurs, mais seulement leurs valeurs ?
J'ai pu retrouver la palette IMPOSEE qui est cependant valide. Voila ce que cela donne:
Il est donc possible de se servir de toutes ces couleurs sans altérer les tableaux de création des décors du fond.
Ps: L'ordre des couleurs doit être impérativement respecté sous peine de générer des tableaux incohérents!
Une solution provisoire serait de faire un tableau avec les correspondances [No de COULEURS] => [TILES].
Puis dessiner en dernier lieu le tableau des décors tout en tenant compte de la numérotation des couleurs qui se balade au grès de BMP2MSX!
Voici le tableau:
Pour ce qui est de l'économie de place, j'ai mis en pratique la troisième solution comme tu l'as expliqué. Cela donne ceci.
Du coup, cela laisse la place à un second SPRITE comme ci dessous:
Questions! (Merci d'avance )
1) Est il possible de gérer un mode DEUX joueurs en BASIC?
2) Est il possible de faire accéder le personnage au DECORS 1, lorsqu'il a franchit le DECORS 16 ?
Voici ce que donne le franchissement de la page 16 =>
3) Est il possible de gérer des SAUTS? (Cela implique la création d'une PESANTEUR!)
4) Comment dois je m'y prendre pour implanter de nouveaux décors en lieu et place des colonnes libres 5, 6, 7, 8 ?
Des ELEMENTS en 16X16, de Gauche a droite? Haut en bas? peux tu me donner les charges à respecter!
Pour ce qui est des escaliers, j'envisage un introduction dans des TUBES (à la Mario).
Je dois travailler dessus!
J'ai commencé à retravailler en 16X16 des décors importés du projet MARIO WARS qui est un Hombrew existant sur 360,Wii et Ps3...
Malheureusement, pour le moment trop de difficultés à gérer la Palette Graphique !!!!
Voici la disquette contenant MARIO ou WARIO en 4 COLONNES!
MARIO WARIO FAT.zip
Voici les sources graphiques:
PALETTE STAPHA.zip
Je continues mes petits travaux, et je vous tiens au courant
Edité par
igal
Le 29/03/2011 à 18h31
Alors voila. Je me suis penché sur le problème de la palette de MARIO FAT. Il semblerait qu'il ne soit plus possible de modifier la PALETTE GRAPHIQUE sous peine de voir l'ORDRE des COULEURS se MELANGER n'importe comment! Ce qui oblige à se limiter aux couleurs déjà existantes!
Logiquement, il devrait être possible de modifier les Valeurs R,G,B des couleurs, sans en changer leurs NUMEROS, mais je sais pas comment!
@ Msxosaure => Si tu sais tu si il est possible de forcer BMP2MSX à ne pas modifier la NUMEROTATION des couleurs, mais seulement leurs valeurs ?
J'ai pu retrouver la palette IMPOSEE qui est cependant valide. Voila ce que cela donne:
Il est donc possible de se servir de toutes ces couleurs sans altérer les tableaux de création des décors du fond.
Ps: L'ordre des couleurs doit être impérativement respecté sous peine de générer des tableaux incohérents!
Une solution provisoire serait de faire un tableau avec les correspondances [No de COULEURS] => [TILES].
Puis dessiner en dernier lieu le tableau des décors tout en tenant compte de la numérotation des couleurs qui se balade au grès de BMP2MSX!
Voici le tableau:
Pour ce qui est de l'économie de place, j'ai mis en pratique la troisième solution comme tu l'as expliqué. Cela donne ceci.
Du coup, cela laisse la place à un second SPRITE comme ci dessous:
Questions! (Merci d'avance
)1) Est il possible de gérer un mode DEUX joueurs en BASIC?
2) Est il possible de faire accéder le personnage au DECORS 1, lorsqu'il a franchit le DECORS 16 ?
Voici ce que donne le franchissement de la page 16 =>
3) Est il possible de gérer des SAUTS? (Cela implique la création d'une PESANTEUR!)
4) Comment dois je m'y prendre pour implanter de nouveaux décors en lieu et place des colonnes libres 5, 6, 7, 8 ?
Des ELEMENTS en 16X16, de Gauche a droite? Haut en bas? peux tu me donner les charges à respecter!
Pour ce qui est des escaliers, j'envisage un introduction dans des TUBES (à la Mario).
Je dois travailler dessus!
J'ai commencé à retravailler en 16X16 des décors importés du projet MARIO WARS qui est un Hombrew existant sur 360,Wii et Ps3...
Malheureusement, pour le moment trop de difficultés à gérer la Palette Graphique !!!!
Voici la disquette contenant MARIO ou WARIO en 4 COLONNES!
MARIO WARIO FAT.zip
Voici les sources graphiques:
PALETTE STAPHA.zip
Je continues mes petits travaux, et je vous tiens au courant
Edité par
igal
Le 29/03/2011 à 18h31
Igal,
Concernant ton problème de palette de couleurs, si j'ai bien compris, tu veux pouvoir modifier une couleur dans ton .bmp d'origine, et que celle ci soit à la même place que l'ancienne dans la palette après traitement par BMP2MSX ?
D'après moi, il suffit de charger la palette dédiée dans BMP2MSX, modifier la couleur correspondante (avec les curseurs), faire un HOLD et reconvertir le fichier d'origine ...
Concernant ton problème de palette de couleurs, si j'ai bien compris, tu veux pouvoir modifier une couleur dans ton .bmp d'origine, et que celle ci soit à la même place que l'ancienne dans la palette après traitement par BMP2MSX ?
D'après moi, il suffit de charger la palette dédiée dans BMP2MSX, modifier la couleur correspondante (avec les curseurs), faire un HOLD et reconvertir le fichier d'origine ...
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 à Tous.
@ Métalion: Je comprends ta manipulation, le problème c'est que du coup, il n'y à pas de valorisation automatique des couleurs. Ce qui est fort dommage parce que très pratique et vraiment un outil génial.
L'idéal étant d'empêcher juste le "SWAP" des No identifiant les couleurs! Pour le reste, tout est très bien pensé.
Il me semble avoir un jour activé une fonction que je ne retrouve pas et qui permet grâce à une sorte de petit stylo virtuel d'appliquer telle ou telle Couleur du .BMP à tel ou tel élément graphique du SC5!
Ca pourrait être une solution intermédiaire puisque cela permet de trouver en quelques secondes la bonne valeur R,G,B de l'élément voulu sans modifier l'ordre des couleurs!
@ Stapha: J'ai retravaillé quelques graphismes, et disposé de nouveaux éléments comme présentés ci dessous.
Merci de me dire comment disposer les nouveaux décors! (Est ce que des blocs de 32 X 32 sont gérables ou alors il faut envisager la chose avec 4 Blocs de 16 ?
Veux tu que je dispose les éléments en fonction de leurs caractéristiques? (Les éléments de FOND sur une ligne, les éléments représentant un VOLUME sur une autre ligne?)
Je peux remplir toutes les lignes?
J'en profite pour te signaler un petit bug suite à la commande D=(D+32)AND127 au lieu de D=(D+32)AND255
Le bug se produit lors de la transition d'une page à une autre. Le Sprite de WARIO affiche le contenu graphique de la matrice qui se trouve juste àgauche droite de la quatrième colonne!
Pour les curieux, voici une image InGame:
Si vous avez de l'imagination et que le coeur vous en dit, je vous propose d'apporter votre contribution avec un mini scénario, un concept apportant de l’intérêt au jeu, et la création des niveaux! (j'ai pas du tout d'imagination )
N'hésitez pas à vous lancer
Edité par
igal
Le 31/03/2011 à 09h14
@ Métalion: Je comprends ta manipulation, le problème c'est que du coup, il n'y à pas de valorisation automatique des couleurs. Ce qui est fort dommage parce que très pratique et vraiment un outil génial.
L'idéal étant d'empêcher juste le "SWAP" des No identifiant les couleurs! Pour le reste, tout est très bien pensé.
Il me semble avoir un jour activé une fonction que je ne retrouve pas et qui permet grâce à une sorte de petit stylo virtuel d'appliquer telle ou telle Couleur du .BMP à tel ou tel élément graphique du SC5!
Ca pourrait être une solution intermédiaire puisque cela permet de trouver en quelques secondes la bonne valeur R,G,B de l'élément voulu sans modifier l'ordre des couleurs!
@ Stapha: J'ai retravaillé quelques graphismes, et disposé de nouveaux éléments comme présentés ci dessous.
Merci de me dire comment disposer les nouveaux décors! (Est ce que des blocs de 32 X 32 sont gérables ou alors il faut envisager la chose avec 4 Blocs de 16 ?
Veux tu que je dispose les éléments en fonction de leurs caractéristiques? (Les éléments de FOND sur une ligne, les éléments représentant un VOLUME sur une autre ligne?)
Je peux remplir toutes les lignes?
J'en profite pour te signaler un petit bug suite à la commande D=(D+32)AND127 au lieu de D=(D+32)AND255
Le bug se produit lors de la transition d'une page à une autre. Le Sprite de WARIO affiche le contenu graphique de la matrice qui se trouve juste à
Pour les curieux, voici une image InGame:
Si vous avez de l'imagination et que le coeur vous en dit, je vous propose d'apporter votre contribution avec un mini scénario, un concept apportant de l’intérêt au jeu, et la création des niveaux! (j'ai pas du tout d'imagination
)N'hésitez pas à vous lancer
Edité par
igal
Le 31/03/2011 à 09h14
je vais essayer de répondre aux questions de Igal
1) à 2 ça risque de ramer... Mais en X-basic, pourquoi pas
2) Pour revenir au premier niveau (zéro) quand on dépasse le dernier niveau (15), il suffit d'appliquer la solution déjà citée c'est à dire remettre à zéro par un AND bien ajusté à chaque passage de niveau: N=(N+1)AND15.
3) Toujours le problème de ramage mais mins que pour le 1
4) pour celui là à toi de voir ce que tu veux en faire après....
Pour conserver l'agencement des tableaux il suffit de charger le fichier de tableaux de création des décors du fond sur une page libre et de faire le COPY ad hoc
1) à 2 ça risque de ramer... Mais en X-basic, pourquoi pas
2) Pour revenir au premier niveau (zéro) quand on dépasse le dernier niveau (15), il suffit d'appliquer la solution déjà citée c'est à dire remettre à zéro par un AND bien ajusté à chaque passage de niveau: N=(N+1)AND15.
3) Toujours le problème de ramage mais mins que pour le 1
4) pour celui là à toi de voir ce que tu veux en faire après....
Pour conserver l'agencement des tableaux il suffit de charger le fichier de tableaux de création des décors du fond sur une page libre et de faire le COPY ad hoc
Le MSXien le plus à l'ouest
... ou presque
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie