La Place des Développeurs moteur de jeu en basic création, optimisation
Reprise du message précédent
Stapha :
Dernier point : je n'ai pas remis de musique mais tu maitrises ça très bien : je te laisse faire.
Salut Stapha, hello tout le monde! (Msxlegend, une suggestion pour toi!)
J'ai implanté la musique comme tu me l'a demandé
J'ai choisi le loader Audio de Salamander Démo pour la simple raison que l'on peut appeler aisément toute une batterie d'effets sonores ne demandant qu'à être joués.
Le loader SCC ne supporte pas les commandes BASIC AUDIO.
(Une petite aparté pour MsxLégend => puisque Le turbo Basic ne supporte pas les commandes Basic Audio, et que le loader SCC aussi, Pourquoi ne pas essayer le loader SCC avec le turbo Basic! On sait Jamais lol)
Rien n'empêche de se tourner vers le loader "Jukebox" de Reinaldo Pinto Da Silva qui permet de jouer une grande variété de musiques FM au format .BGM, mais sans effets sonores!
Le Loader BGM supporte néanmoins toutes les commandes BASIC AUDIO en temps réel! et ça, c'est très cool
voici les modifications que j'ai apporté à ton Code:
Code TEXT :
1 'DEFUSR=&HD000:A=USR(0):FORP=0TO10:NEXT:POKE&HFD9F,201:SAVE"winnie.bas Permet de nouveau l'accès au lecteur de disquette. (POKE&HFD9F,201 libère de la mémoire???) 70 GOTO 20000 Renvoie au loader Audio Salamander. 160 X=14:Y=152:N=0:DEFUSR=&HD000:A=USR(0):POKE&HCFFF,32:A=USR2(0):GOSUB910 Les valeurs 14 et 152 étant celle du positionnement de départ ou de résurrection du vaisseau, la musique doit être relancée dans ses mêmes circonstances ;) 540 NEXT:COPY(0,20)-(255,211),0TO(0,20),2:SETPAGE0,0:POKE&HCFFF,69:A=USR2(0):GOTO310 Un son de Bip identique à un sous marin indique que l'endroit est scruté. Le décor va-t-être affiché ^^ 710 POKE&HCFFF,82:A=USR2(0):I=(X+14)/16:J=(Y+1)/16:P=AC(I,J)*16:AC(I,J)=1 Accentue l'interactivité par un son donnant l'impression de "Gober un Item" 810 POKE&HCFFF,39:A=USR2(0):FORI=0TO17 Une explosion brève et violente. 910 POKE&HCFFF,69:A=USR2(0):SETPAGE0,3:FORI=1TO32:FORJ=3TO24:CO(I,J)=-1:NEXT:NEXT Un son de Bip identique à un sous marin indique que l'endroit est scruté. Ca aide à patienter. 20000 '---------DEBUT DE SALAMANDER DEMO MODIFIE---------------- 20010 'POKE&HFBB1,1: 'EMPECHE CONTROL+STOP 20030 BLOAD"1.006":DEFUSR4=&HD600:' CHARGE LE PLAYER ? 20040 BLOAD"1.007":U=USR4(1):' CHARGE SONS ET MUSIQUES 20050 BLOAD"1.008":U=USR4(2):' CHARGE SONS ET MUSIQUES 20060 BLOAD"1.009":U=USR4(3):' CHARGE SONS ET MUSIQUES 20070 BLOAD"1.010":U=USR4(4):' CHARGE SONS ET MUSIQUES 20080 BLOAD"1.011":FORT=0TO2000:NEXT 20090 DEFUSR=&HD000:A=USR(0): 'PREREQUIS ARRET LA MUSIQUE 20100 DEFUSR2=&HD003:' PREREQUIS FONCTION INCONNUE 20101 POKE&HFD9F,201 20105 POKE&HFDA0,&H6:POKE&HFDA1,&HD0:POKE&HFD9F,&HC3 20115 ' LISTE COMPLETE DES MUSIQUES ET SONS DANS POKE SALAMANDER 20117 ' 20120 ' DEFUSR=&HD000:A=USR(0):POKE&HCFFF,32:A=USR2(0):' MUSIQUE STAGE 6 20750 'POKE&HCFFF,67:A=USR2(0):' EXPLOSION D'ENNEMI MOYENNE 20755 ' 20760 'DEFUSR=&HD000:A=USR(0):FORP=0TO10:NEXT:POKE&HFD9F,201:'PERMET ACCES DISK MAIS ARRETER MUSIQUE AVANT 20770 GOTO 100:' RETOUR A L ANIMATION 20800 ' 20810 '---------FIN DE SALAMANDER DEMO MODIFIE------------------- Le loader Audio SCC.
Comme dirait la voix! C'est tout...Pour le moment
Salut à tous,
En fait c'est très simple : il suffit de multiplier par 14 au lieu de 16 à la lecture du point à traiter dans la préparation du tableau. Par contre, à l'apparition du niveau on aura 2 colonnes répétées. Il faudra donc que la boucle de traitement des colonnes ailles de 2 à 15 ou de 0 à 13 selon que l'on passe au niveau suivant ou précédent. Et c'est tout...
Petite astuce toute simple à comprendre : le numéro de la page ou on dessine est stocké dans la variable S. Elle doit donc alterner entre les valeurs 0 et 2.
La façon la plus classique de faire varier une variable A entre les valeurs I et J est de faire :
IF A=I THEN A=J ELSE A=I
Mais on peut faire :
A = (I+J)-A
Evidemment, (I+J) est calculé par le codeur. Pour le cas de winnie, I et J valent 0 et 2 (les numéros de pages), ce qui donne :
S = 2 - S
C'est quand même plus court et plus rapide. Et ça marche dans tous les langages...
Ce week-end je posterai un code avec la pesanteur et la modif sur la taille des niveaux.
Igal :
Et pourquoi pas plutôt le moteur du forum ? ça serait pas plus sympa et plus proche de la réalité ? Si tu veux bien je l’identifierai comme le moteur "MARIO FAT de Stapha"
Igal :
Pour ce qui est des transitions d'une page à l'autre, je trouve que c'est une très bonne idée de conserver les deux derniers tiles et en ajouter 14. J'essaierai de voir ça demain
En fait c'est très simple : il suffit de multiplier par 14 au lieu de 16 à la lecture du point à traiter dans la préparation du tableau. Par contre, à l'apparition du niveau on aura 2 colonnes répétées. Il faudra donc que la boucle de traitement des colonnes ailles de 2 à 15 ou de 0 à 13 selon que l'on passe au niveau suivant ou précédent. Et c'est tout...
Igal :
C'était pour avoir l'occasion d'expliquer le principe du double buffer. Dans ce cas, pendant qu'on affiche la page 2, on déssine dans la page 0 et vice versa. ça supprime également l'obligation de modifier le sens de traitement des pixels par le VDP (ou de copier par colonnes) : dans une copie de zone mémoire, si la source et la destination se chevauchent, il faut traiter les octets dans le bon sens pour ne pas transformer la copie en répétition. En utilisant 2 pages, il n'y a jamais de chevauchement et donc ça fait une chose en moins à gérer. J'étais pret à expliquer tout ça mais il semble que ça n'interesse personne ou que tout le monde maitrise ces concepts.J'ai bien aimé le défilement d'écran tiles après tiles que tu as proposé.
Petite astuce toute simple à comprendre : le numéro de la page ou on dessine est stocké dans la variable S. Elle doit donc alterner entre les valeurs 0 et 2.
La façon la plus classique de faire varier une variable A entre les valeurs I et J est de faire :
IF A=I THEN A=J ELSE A=I
Mais on peut faire :
A = (I+J)-A
Evidemment, (I+J) est calculé par le codeur. Pour le cas de winnie, I et J valent 0 et 2 (les numéros de pages), ce qui donne :
S = 2 - S
C'est quand même plus court et plus rapide. Et ça marche dans tous les langages...
Igal :
En fait j'en n'ai pas... Mais je vais en trouver une !Je suis très curieux de voir ta méthode!
Ce week-end je posterai un code avec la pesanteur et la modif sur la taille des niveaux.
Le plus simple pour échanger 2 variables c'est Swap a,b non ?
Dans ce cas là: S0=0
S=2
Swap S0,S
Mais Stapha, ton expression A = (I+J)-A est géniale je la garde si un jour j'ai pas de swap dispo.
Dans ce cas là: S0=0
S=2
Swap S0,S
Mais Stapha, ton expression A = (I+J)-A est géniale je la garde si un jour j'ai pas de swap dispo.
Visiteur
Vagabond
Message : 0
kirem: ce n'est pas un échange de variables, mais un basculement d'état entre 0 et x (x étant un nombre quelconque).
Ca ne fonctionnera pas avec deux valeurs arbitraires.
edit: la méthode générale A=i+j-A fonctionne bien sûr avec des valeurs arbitraires, à condition qu'au départ "A" ait la valeur de i ou de j.
Sinon pour faire des incrémentations bornées avec remise à zéro, on utilise un modulo le plus souvent.
Ex en pseudo code:
"x" vaudra toujours le reste de la division par 4, soit un nombre entre 0 et 3.
Par contre, il faut que les nombres se suivent.
Pour les procs où le swap vaut cher (valeur intermédiaire nécessaire pour l'opération, donc blocage de trois registres ou pire, écriture en ram), on utilise un "ou exclusif":
Pour échanger r0 et r1 :
le xor est quasiment gratuit , quelle que soit l'archi, et on n'a pas de registre intermédiaire impliqué.
Bien entendu, le swap sur les archis récentes ne nécessite plus de telles contorsions (qui ne sont pas parallélisables). Cette méthode sur des archis récentes sera plus pénalisante qu'autre chose, mais sur le msx, ça peut etre intéressant (voir si le swap est microcodé, et combien de cycles il prend). Edité par Visiteur Le 16/12/2010 à 13h54
Ca ne fonctionnera pas avec deux valeurs arbitraires.
edit: la méthode générale A=i+j-A fonctionne bien sûr avec des valeurs arbitraires, à condition qu'au départ "A" ait la valeur de i ou de j.
Sinon pour faire des incrémentations bornées avec remise à zéro, on utilise un modulo le plus souvent.
Ex en pseudo code:
Code :
x = 0
loop:
buffer_number = x mod 4
x = x+1
goto loop
"x" vaudra toujours le reste de la division par 4, soit un nombre entre 0 et 3.
Par contre, il faut que les nombres se suivent.
Pour les procs où le swap vaut cher (valeur intermédiaire nécessaire pour l'opération, donc blocage de trois registres ou pire, écriture en ram), on utilise un "ou exclusif":
Pour échanger r0 et r1 :
Code :
r0 = r0 xor r1
r1 = r0 xor r1
r0 = r0 xor r1
le xor est quasiment gratuit , quelle que soit l'archi, et on n'a pas de registre intermédiaire impliqué.
Bien entendu, le swap sur les archis récentes ne nécessite plus de telles contorsions (qui ne sont pas parallélisables). Cette méthode sur des archis récentes sera plus pénalisante qu'autre chose, mais sur le msx, ça peut etre intéressant (voir si le swap est microcodé, et combien de cycles il prend). Edité par Visiteur Le 16/12/2010 à 13h54
Salut à tous.
Un Petit correctif pour le Moteur Mrio Fat! (Avec ta permission Stapha
)
La Valeur 37 ajouté à A en ligne 350 est trop grande d'un pixel! Elle chevauche sur la Rangé de Sprite se trouvant juste en dessous.
Voici L'original:
350 COPY(D,A)-(D+25,A+37),1TO(4,4),3,TPSET
Voilà le correctif:
350 COPY(D,A)-(D+25,A+36),1TO(4,4),3,TPSET
Tout autre Chose:
J'ai pu appliquer une pesanteur avec DY(5)+1 sur cette ligne:
Voici l'original:
320 S=STICK(0):NX=X+DX(S):NY=Y+DY(S):A=VA(S)
Voici mes differents testes: (de mémoire)
320 S=STICK(0):NX=X+DX(S):NY=Y+DY(S)+DY(5)+1:A=VA(S)
Me rappel plus trop des autres testes, mais ils portent sur la même ligne 320 avec la même variable DY(5) et la même valeur ajouté +1, mais avec des combinaisons différentes..
Le résulta est resté le même, à savoir:
Le vaisseau subit la pesanteur, il descend, mais n'arrive pas à remonté...
@ Stapha:
Te serait il possible de nous livrer une version décortiquée pas à pas s'il te plait (Des grands pas feront l'affaire lol)
J'adore le cambouis, mais là...J'ai vraiment du mal à trouver la tête de delco, pis les vis platinées
Merci pour vos suggestions
Edité par
igal
Le 16/12/2010 à 17h42
Un Petit correctif pour le Moteur Mrio Fat! (Avec ta permission Stapha
)La Valeur 37 ajouté à A en ligne 350 est trop grande d'un pixel! Elle chevauche sur la Rangé de Sprite se trouvant juste en dessous.
Voici L'original:
350 COPY(D,A)-(D+25,A+37),1TO(4,4),3,TPSET
Voilà le correctif:
350 COPY(D,A)-(D+25,A+36),1TO(4,4),3,TPSET
Tout autre Chose:
J'ai pu appliquer une pesanteur avec DY(5)+1 sur cette ligne:
Voici l'original:
320 S=STICK(0):NX=X+DX(S):NY=Y+DY(S):A=VA(S)
Voici mes differents testes: (de mémoire)
320 S=STICK(0):NX=X+DX(S):NY=Y+DY(S)+DY(5)+1:A=VA(S)
Me rappel plus trop des autres testes, mais ils portent sur la même ligne 320 avec la même variable DY(5) et la même valeur ajouté +1, mais avec des combinaisons différentes..
Le résulta est resté le même, à savoir:
Le vaisseau subit la pesanteur, il descend, mais n'arrive pas à remonté...
@ Stapha:
Te serait il possible de nous livrer une version décortiquée pas à pas s'il te plait
(Des grands pas feront l'affaire lol)J'adore le cambouis, mais là...J'ai vraiment du mal à trouver la tête de delco, pis les vis platinées
Merci pour vos suggestions
Edité par
igal
Le 16/12/2010 à 17h42
Venom,
Le coup du modulo peut poser des problèmes :
- dans un langage de haut niveau, il faut éviter le dépassement de capacité (en basic msx par exemple, ça finira par planter).
- dans les processeurs anciens, la division est ce qui prend le plus de cycle. Sur un 68000 par exemple (je ne connais pas le Z80 mais j'imagine que ça doit être pareil, voire pire), ça prend beaucoup plus de temps que de mettre un compteur et de tester la borne.
Mais, il peut y avoir des cas ou c'est rentable bien sur.
ça me fait penser que j'ai cherché s'il existait une instruction pour shifter sur le msx basic et hélas non. C'est dommage : le code est rempli de /16 et de *16. Personne en assembleur ne ferait une telle opération : un décalage de 4 bits est bien plus rapide. Dommage...
Par contre, le coup du XOR est une astuce qu'il faut connaitre car ça permet d'économiser un registre processeur. Et avec les procs anciens, c'est pas du luxe...
C'est exact : j'avais oublié de dire que A doit être initialisé avec I ou J. Merci d'avoir pris soin de le préciser
Igal,
Bien vu pour la correction du pixel en trop. Bien sur que je peux tout détailler pas à pas. J'espère que je pourrai le faire de façon assez claire pour tous. Et ça c'est bien plus compliqué...
Je le ferai ce week-end.
Par contre, je peux déjà t'expliquer certaines choses pour t'aider dans ta recherche de la gestion du déplacement :
Le déplacement en Y est géré via le tableau DY. Ce dernier contient la valeur de déplacement à appliquer selon la valeur de Stick(0) (qui correspond à la manette). Rappelons comment il est initialisé :
Fort logiquement, les valeurs 0,3,7 restent à 0 car elle correspondent à un déplacement horizontal uniquement ou pas de déplacement du tout.
Supposons maintenant qu'on modifie ce tableau pour mettre un pas de +4 pour ces 3 positions comme ci-dessous.
Que ce passerait-il ? Tu aurais la pesanteur...
Mais ce n'est pas si simple : quand ton perso serait sur un bloc, il ne pourrait pas aller à droite ou à gauche puisque ça reviendrait à aller vers le bas en même temps. Ce que le bloc interdirait...
Supposons maintenant qu'on ait 2 tableaux : un comme l'original et un renseigné avec les 3 valeurs supplémentaires. Il te suffirait alors de tester si ton perso se trouve sur un bloc : si oui, on utiliserait le premier tableau sinon ce serait le deuxième...
C'est une piste pour t'aider. Mais je chercherai une solution plus optimisée ce week-end... (j'ai du boulot qui m'attend ce week-end... )
Kirem,
Content de ta réponse car c'est bien le but : que chacun puisse apporter des méthodes qui pourront être reprise par tous ceux que ça interesse. Comme par exemple le coup du XOR de Venom : ça m'a bien aidé sur l'Amiga pour faire du C2P.
Qu'est-ce que j'aurai pu gagner comme temps si j'étais tombé sur son post il y a 15 ans...
Edité par
Stapha
Le 16/12/2010 à 17h57
Le coup du modulo peut poser des problèmes :
- dans un langage de haut niveau, il faut éviter le dépassement de capacité (en basic msx par exemple, ça finira par planter).
- dans les processeurs anciens, la division est ce qui prend le plus de cycle. Sur un 68000 par exemple (je ne connais pas le Z80 mais j'imagine que ça doit être pareil, voire pire), ça prend beaucoup plus de temps que de mettre un compteur et de tester la borne.
Mais, il peut y avoir des cas ou c'est rentable bien sur.
ça me fait penser que j'ai cherché s'il existait une instruction pour shifter sur le msx basic et hélas non. C'est dommage : le code est rempli de /16 et de *16. Personne en assembleur ne ferait une telle opération : un décalage de 4 bits est bien plus rapide. Dommage...
Par contre, le coup du XOR est une astuce qu'il faut connaitre car ça permet d'économiser un registre processeur. Et avec les procs anciens, c'est pas du luxe...
C'est exact : j'avais oublié de dire que A doit être initialisé avec I ou J. Merci d'avoir pris soin de le préciser
Igal,
Bien vu pour la correction du pixel en trop. Bien sur que je peux tout détailler pas à pas. J'espère que je pourrai le faire de façon assez claire pour tous. Et ça c'est bien plus compliqué...
Je le ferai ce week-end.
Par contre, je peux déjà t'expliquer certaines choses pour t'aider dans ta recherche de la gestion du déplacement :
Le déplacement en Y est géré via le tableau DY. Ce dernier contient la valeur de déplacement à appliquer selon la valeur de Stick(0) (qui correspond à la manette). Rappelons comment il est initialisé :
Code :
130 DY(1)=-4:DY(2)=-4:DY(4)=4:DY(5)=4:DY(6)=4:DY(8)=-4
Fort logiquement, les valeurs 0,3,7 restent à 0 car elle correspondent à un déplacement horizontal uniquement ou pas de déplacement du tout.
Supposons maintenant qu'on modifie ce tableau pour mettre un pas de +4 pour ces 3 positions comme ci-dessous.
Code :
130 DY(0)=4:DY(1)=-4:DY(2)=-4:DY(3)=4:DY(4)=4:DY(5)=4:DY(6)=4:DY(7)=4:DY(8)=-4
Que ce passerait-il ? Tu aurais la pesanteur...
Mais ce n'est pas si simple : quand ton perso serait sur un bloc, il ne pourrait pas aller à droite ou à gauche puisque ça reviendrait à aller vers le bas en même temps. Ce que le bloc interdirait...
Supposons maintenant qu'on ait 2 tableaux : un comme l'original et un renseigné avec les 3 valeurs supplémentaires. Il te suffirait alors de tester si ton perso se trouve sur un bloc : si oui, on utiliserait le premier tableau sinon ce serait le deuxième...
C'est une piste pour t'aider. Mais je chercherai une solution plus optimisée ce week-end... (j'ai du boulot qui m'attend ce week-end...
)Kirem,
Content de ta réponse car c'est bien le but : que chacun puisse apporter des méthodes qui pourront être reprise par tous ceux que ça interesse. Comme par exemple le coup du XOR de Venom : ça m'a bien aidé sur l'Amiga pour faire du C2P.
Qu'est-ce que j'aurai pu gagner comme temps si j'étais tombé sur son post il y a 15 ans...
Edité par
Stapha
Le 16/12/2010 à 17h57
Visiteur
Vagabond
Message : 0
Stapha :
Le coup du modulo peut poser des problèmes :
- dans un langage de haut niveau, il faut éviter le dépassement de capacité (en basic msx par exemple, ça finira par planter).
Le coup du modulo peut poser des problèmes :
- dans un langage de haut niveau, il faut éviter le dépassement de capacité (en basic msx par exemple, ça finira par planter).
Exact en basic msx, ça provoque l'erreur overflow dès qu'on dépasse 16 bits (enfin 15 bits, puisque c'est signé).
Par contre, c'est géré par tous les langages de haut niveau dignes de ce nom. Tu n'as pas à te préoccuper de ces détails d'implémtentation, et heureusement (sinon ça serait difficile de faire du code portable).
Je pense (pas vérifié) qu'au pire, le compteur revient à zéro quand il dépasse sa limite entière (pour le C, ça ne correspond pas forcément à la largeur du bus, mais à une constante définie dans la libc, en général MAXINT. Je pense qu'un mécanisme analogue est mis en place pour les autres langages impératifs, je ne sais pas ce qu'il en est pour les langages fonctionnels.)
Il y a un autre problème auquel j'ai pensé plus tard: si on moment du dépassement et de la remise à zéro, on termine sur une valeur qui ne permette pas de boucler le cycle des modulos.
Par exemple, si tu fais ta division avec un nombre impair, il y a peu de chances pour que la remise à zéro ne provoque pas un décalage du cycle modulo.
Il se trouve qu'avec un modulo de 4, ça ira (puissance de deux, donc on retombera toujours sur 0 au moment du dépassement) mais c'est un coup de bol.
Je n'avais pas pensé au coût de la division. En plus elle est émulée sur le Z80. Quelle punition ce proc
Qu'appelles-tu C2P ? ChunkyToBitplan ? Si c'est ça, pourquoi décomposer en temps réel (à priori, d'après ce que tu as écrit, le temps de traitement avait l'air critique) des pixels en leurs composantes binaires ? (je sais que l'amiga travaillait avec des bitplans, mais justement dans un cas comme ça, je suppose que les données devraient plutot être envoyées plans par plans, plutot que de décomposer un pixel pour le ventiler sur chacun des plans).
Venom :
J'ai toujours cru que le C ne vérifiait pas les dépassement de capacité et je les ai toujours géré moi-même... C'est la philosophie du C en général. Comme pour les tableaux qui ne sont pas vérifiés : on peut accéder à un élément qui n'existe pas. Merci pour l'info sur MAXINT que j'ignorais.Exact en basic msx, ça provoque l'erreur overflow dès qu'on dépasse 16 bits (enfin 15 bits, puisque c'est signé).
Par contre, c'est géré par tous les langages de haut niveau dignes de ce nom. Tu n'as pas à te préoccuper de ces détails d'implémtentation, et heureusement (sinon ça serait difficile de faire du code portable).
Je pense (pas vérifié) qu'au pire, le compteur revient à zéro quand il dépasse sa limite entière (pour le C, ça ne correspond pas forcément à la largeur du bus, mais à une constante définie dans la libc, en général MAXINT. Je pense qu'un mécanisme analogue est mis en place pour les autres langages impératifs, je ne sais pas ce qu'il en est pour les langages fonctionnels.)
Par contre, c'est géré par tous les langages de haut niveau dignes de ce nom. Tu n'as pas à te préoccuper de ces détails d'implémtentation, et heureusement (sinon ça serait difficile de faire du code portable).
Je pense (pas vérifié) qu'au pire, le compteur revient à zéro quand il dépasse sa limite entière (pour le C, ça ne correspond pas forcément à la largeur du bus, mais à une constante définie dans la libc, en général MAXINT. Je pense qu'un mécanisme analogue est mis en place pour les autres langages impératifs, je ne sais pas ce qu'il en est pour les langages fonctionnels.)
Venom :
Peut-être pas un coup de bol avec tous les procs : avec la plupart ton système marcherait puisqu'en cas de dépassement, l'adresse ou le registre ne passe pas à 0 mais aura la bonne valeur pour les bits qu'il contient (par exemple 65535+2 donnera 1 et non 0). Le flag carry ou overflow (ou les 2) sera positionné. Sans ce système, il devient difficile de gérer des nombres plus grand que la capacité du proc.Il y a un autre problème auquel j'ai pensé plus tard: si on moment du dépassement et de la remise à zéro, on termine sur une valeur qui ne permette pas de boucler le cycle des modulos.
Par exemple, si tu fais ta division avec un nombre impair, il y a peu de chances pour que la remise à zéro ne provoque pas un décalage du cycle modulo.
Il se trouve qu'avec un modulo de 4, ça ira (puissance de deux, donc on retombera toujours sur 0 au moment du dépassement) mais c'est un coup de bol.
Par exemple, si tu fais ta division avec un nombre impair, il y a peu de chances pour que la remise à zéro ne provoque pas un décalage du cycle modulo.
Il se trouve qu'avec un modulo de 4, ça ira (puissance de deux, donc on retombera toujours sur 0 au moment du dépassement) mais c'est un coup de bol.
Donc c'est pas qu'un coup de bol : ta méthode tient la route. Surtout avec les procs moderne (qui divisent en 1 cycle)
Sinon lorsqu'on est sur une puissance de 2, le pseudo-code suivant devrait marcher :
Code :
x = 0
loop:
x = (x+1) AND 3
goto loop
Dans cet exemple, X devrait aller de 0 à 3 (si je me trompe pas : pas testé...)
Venom :
ce n'est pas si idiot que ça en fait : sur un 68000 la division prend énormément de temps (entre 100 et 150 cycles si je me souviens bien). Ce qui fait qu'il est pratiquement toujours plus rentable de la décomposer. D'ailleurs, les bon compilos pouvaient s'en charger automatiquement (ce qui apporte de l'eau à ton moulin sur la capacité d'un compilo a générer du code bien optimisé).Je n'avais pas pensé au coût de la division. En plus elle est émulée sur le Z80. Quelle punition ce proc
Venom :
Oui c'est ça (ChunkyToPlanar en fait mais tu as bien compris de quoi il s'agit). C'est plus performant lorsque l'on fait un traitement qui travaille pixel par pixel (zoom, rotation, placage de texture, raycasting, etc...). Prenons le cas d'un zoom par exemple : en bitplans, i faudrait à chaque itération prendre le nieme bit du nieme octet et l'ajouter dans un buffer. Un proc travaille plus lentement avec des bits et le code sera également plus long. A l'inverse, un accès mémoire pour 1 bit prend autant de temps que pour un mot : aucun bénéfice d'un coté et de grosses pertes de l'autre.Qu'appelles-tu C2P ? ChunkyToBitplan ? Si c'est ça, pourquoi décomposer en temps réel (à priori, d'après ce que tu as écrit, le temps de traitement avait l'air critique) des pixels en leurs composantes binaires ? (je sais que l'amiga travaillait avec des bitplans, mais justement dans un cas comme ça, je suppose que les données devraient plutot être envoyées plans par plans, plutot que de décomposer un pixel pour le ventiler sur chacun des plans).
Et quand on fait la conversion vers du planar, on se retrouve à échanger certains bits entre certains registres. C'est dans ce cas que le XOR, en plus d'économiser un registre, est plus rapide.
Cela dit, j'avoue trouver cette conversation très interessante mais je crains que nous soyons en train de polluer le topic...
Edité par
Stapha
Le 17/12/2010 à 14h09
Visiteur
Vagabond
Message : 0
Ok vu.. j'aurais bien quelques pinaillages, mais on ne va pas abuser plus sur le fil 
Merci pour tes réponses (le C2P me rappelle le "mode x" des cartes vga, mais qui lui était détourné pour tracer quatre pixels d'un coup.. et les divisions/multiplications: l'usage détourné de LEA sur 386+ )
Edité par
Visiteur
Le 17/12/2010 à 18h23
Merci pour tes réponses (le C2P me rappelle le "mode x" des cartes vga, mais qui lui était détourné pour tracer quatre pixels d'un coup.. et les divisions/multiplications: l'usage détourné de LEA sur 386+
)
Edité par
Visiteur
Le 17/12/2010 à 18h23
Bonsoir à tous.
Après avoir greffé Salamander Démo Loader SCC au moteur [Winnie (Fixé par Jipe)] et Mario Fat avec succès, je me suis remis à la tâche avec le [SME3 Mini Démo Loader] qui fait des merveilles.
L’intérêt principal de ce loader, est la possibilité de jouer simultanément: [2 SCC + 1 FMPAC + PSG] tout en laissant suffisamment de place au moteur WINNIE et MARIO FAT.
Sans oublier la possibilité de composer soit même ses mélodies grâce à SME3 (traduit en englais) que je vous invite à télécharger => http://www.msxvillage.fr/forum/topic.php?id=460
Voici les conditions requises:
1) Les Musiques doivent être au format .PLY et non .PR3 qui est le format de SME3 (Si vous savez comment les convertir ça m'intéresse
)
2) Le PLY ne doit pas comporter de mélodie [MSX-Audio] (Musique Module)
3) Le PLY doit se nommer PSGSCC-1.PLY (Tout comme le fichier original à SME3 Mini Démo)
Par souci de clarté, J'ai dissocié le [Loader SME3 Mini Démo]du Moteur Winnie et Mario Fat. (Il est néanmoins possible de fusionner les deux!)
La structure est donc la suivante:
AUTOEXEC.BAS => Contient le loader proprement dit.
MARIOFAT.BAS => Contient les Commandes de Démarrage et Stop de la Musique.
Voici le code modifié:
Voici La disquette prête à l'emploi. Un Fichier Zip contient 7 musiques qu'il ne vous reste plus qu'à extraire et faire glisser/écraser l'ancienne.
SME3FAT.zip
Merci à Galine pour son Méga fichier "Chiptune"
Après SME3 Mini Démo, je me suis donc naturellement penché sur le BGM Loader de MsxLegend.
Voici les modifications apportés:
Malheureusement, j'ai droit à un => Out Of Memory In 110.
Peut être la répétition de la commande [DIM] entre les lignes:
30030 DIMA(1):A$="blabla.bgm"
et
110 Dim DX(8),DY(8),VA(8),AC(15,11),CO(66,13)
Si vous avez des idées! Edité par igal Le 18/12/2010 à 12h02
Après avoir greffé Salamander Démo Loader SCC au moteur [Winnie (Fixé par Jipe)] et Mario Fat avec succès, je me suis remis à la tâche avec le [SME3 Mini Démo Loader] qui fait des merveilles.
L’intérêt principal de ce loader, est la possibilité de jouer simultanément: [2 SCC + 1 FMPAC + PSG] tout en laissant suffisamment de place au moteur WINNIE et MARIO FAT.
Sans oublier la possibilité de composer soit même ses mélodies grâce à SME3 (traduit en englais) que je vous invite à télécharger => http://www.msxvillage.fr/forum/topic.php?id=460
Voici les conditions requises:
1) Les Musiques doivent être au format .PLY et non .PR3 qui est le format de SME3 (Si vous savez comment les convertir ça m'intéresse
)2) Le PLY ne doit pas comporter de mélodie [MSX-Audio] (Musique Module)
3) Le PLY doit se nommer PSGSCC-1.PLY (Tout comme le fichier original à SME3 Mini Démo)
Par souci de clarté, J'ai dissocié le [Loader SME3 Mini Démo]du Moteur Winnie et Mario Fat. (Il est néanmoins possible de fusionner les deux!)
La structure est donc la suivante:
AUTOEXEC.BAS => Contient le loader proprement dit.
MARIOFAT.BAS => Contient les Commandes de Démarrage et Stop de la Musique.
Voici le code modifié:
Code TEXT :
1 ' DEFUSR=&HA009:A=USR(0):SAVE"SME3FAT.BAS (Stop la musique et sauvegarde aisément) 70 ' DEFUSR=&HA006:A=USR(0):'Début de la musique 71 ' DEFUSR=&HA009:A=USR(0):'Couper la musique 72 ' DEFUSR=&HA00C:A=USR(0):'Retirez la routine d'interruption (Récapitule les commandes possibles) 160 X=14:Y=152:N=0:DEFUSR=&HA006:A=USR(0):GOTO620 (Démarre la musique lors de l'énumération des variables du Sprite Mario Fat.) 850 NEXT:DEFUSR=&HA009:A=USR(0):GOTO 160 (Stop la musique à la fin de la chute dans le trou)
Voici La disquette prête à l'emploi. Un Fichier Zip contient 7 musiques qu'il ne vous reste plus qu'à extraire et faire glisser/écraser l'ancienne.
SME3FAT.zip
Merci à Galine pour son Méga fichier "Chiptune"
Après SME3 Mini Démo, je me suis donc naturellement penché sur le BGM Loader de MsxLegend.
Voici les modifications apportés:
Code TEXT :
1 ' A=USR2(0):SAVE"LEGENFAT.BAS (Stop la musique et facilite la sauvegarde) 2 CLEAR200,&H9000:BLOAD"bgm.bin" (Nettoie un partie de la mémoire et y stocke le driver BGM.BIN?) 70 GOTO 30000 (Renvoie au chargement du loader .BGM) 71 ' A=USR(0)+USR1(VARPTR(A(0))):'DEMARRE LA MUSIQUE 72 ' A=USR2(0):' STOP LA MUSIQUE (A titre informatif) 160 X=14:Y=152:A=USR(0)+USR1(VARPTR(A(0))):N=0:GOTO620 (Démarre la musique) 850 NEXT:A=USR2(0):GOTO 160 (Stop la musique lors de la chute dans le trou) 30000 '---------DEBUT LOADER BGM PAR MSXLEGEND------------------- 30010 'cLEAR200,&H9000:BLOAD"bgm.bin"GM.BIN" 30020 DEFUSR=&HCE00:DEFUSR1=&HCE03:DEFUSR2=&HCE06:DEFUSR3=&HCE09 30030 DIMA(1):A$="blabla.bgm" 30040 OPENA$FORINPUTAS1:B$=INPUT$(1,1):B$=INPUT$(1,1):C$=INPUT$(1,1):CLOSE 30050 BLOADA$ 30060 B=(ASC(B$)+ASC(C$)*256)-65536! 30070 IFB=0THENBLOADA$,&H9000:B=&H9000 30080 A(0)=0:A(1)=B 30090 'A=USR(0)+USR1(VARPTR(A(0))) 30091 GOTO 71 30100 'END 30110 'A=USR2(0) 30111 '------------FIN LOADER BGM PAR MSXLEGEND----------------- Le loader proprement dit)
Malheureusement, j'ai droit à un => Out Of Memory In 110.
Peut être la répétition de la commande [DIM] entre les lignes:
30030 DIMA(1):A$="blabla.bgm"
et
110 Dim DX(8),DY(8),VA(8),AC(15,11),CO(66,13)
Si vous avez des idées! Edité par igal Le 18/12/2010 à 12h02
Bonjour tout le monde,
Igal,
L'ordre CLEAR 200,&H9000 indique, entre autre, que la zone mémoire située à partir de &H9000 ne doit pas être utilisée par le basic.
Je viens de taper les 3 commandes suivrantes sous bluemsx :
?fre(0) -> 23415 s'affiche (il s'agit de la mémoire disponible)
CLEAR 200,&H9000 -> Ok
?fre(0) -> 3326 s'affiche
Autrement dit, cet ordre soustrait 20 Ko à la mémoire disponible. et 3 326 octets pour le programme et les variables (les tableaux surtout), ça fait un peu court...
Mais il me semble que 20 Ko pour un player, ça fait un peu beaucoup (à moins qu'il y ait aussi des samples)... Edité par Stapha Le 18/12/2010 à 12h34
Igal,
L'ordre CLEAR 200,&H9000 indique, entre autre, que la zone mémoire située à partir de &H9000 ne doit pas être utilisée par le basic.
Je viens de taper les 3 commandes suivrantes sous bluemsx :
?fre(0) -> 23415 s'affiche (il s'agit de la mémoire disponible)
CLEAR 200,&H9000 -> Ok
?fre(0) -> 3326 s'affiche
Autrement dit, cet ordre soustrait 20 Ko à la mémoire disponible. et 3 326 octets pour le programme et les variables (les tableaux surtout), ça fait un peu court...
Mais il me semble que 20 Ko pour un player, ça fait un peu beaucoup (à moins qu'il y ait aussi des samples)... Edité par Stapha Le 18/12/2010 à 12h34
Apres pour les adressages, je ne me suis pas asser interesser
Stapha :
Bonjour tout le monde,
Igal,
L'ordre CLEAR 200,&H9000 indique, entre autre, que la zone mémoire située à partir de &H9000 ne doit pas être utilisée par le basic.
Je viens de taper les 3 commandes suivrantes sous bluemsx :
?fre(0) -> 23415 s'affiche (il s'agit de la mémoire disponible)
CLEAR 200,&H9000 -> Ok
?fre(0) -> 3326 s'affiche
Autrement dit, cet ordre soustrait 20 Ko à la mémoire disponible. et 3 326 octets pour le programme et les variables (les tableaux surtout), ça fait un peu court...
Mais il me semble que 20 Ko pour un player, ça fait un peu beaucoup (à moins qu'il y ait aussi des sampes)...
Igal,
L'ordre CLEAR 200,&H9000 indique, entre autre, que la zone mémoire située à partir de &H9000 ne doit pas être utilisée par le basic.
Je viens de taper les 3 commandes suivrantes sous bluemsx :
?fre(0) -> 23415 s'affiche (il s'agit de la mémoire disponible)
CLEAR 200,&H9000 -> Ok
?fre(0) -> 3326 s'affiche
Autrement dit, cet ordre soustrait 20 Ko à la mémoire disponible. et 3 326 octets pour le programme et les variables (les tableaux surtout), ça fait un peu court...
Mais il me semble que 20 Ko pour un player, ça fait un peu beaucoup (à moins qu'il y ait aussi des sampes)...
Ok. Je vais regarder de ce coté là!
En attendant, pour ceux que ca interresse, voici les 3 loaders en action.
Voici les 3 Loaders prêts à l'emploi:
SME3FAT => Loader SME3 Mini Démo + Moteur Mario Fat.
SME3FAT.zip
LEGENFAT => Loader BGM MsxLegend + Moteur Mario Fat.
LEGENFAT.zip
SALAMFAT => Loader Salamander Démo + Moteur Mario Fat.
SALAMFAT.zip
Stapha :
Bonjour tout le monde,
Igal,
L'ordre CLEAR 200,&H9000 indique, entre autre, que la zone mémoire située à partir de &H9000 ne doit pas être utilisée par le basic.
Je viens de taper les 3 commandes suivrantes sous bluemsx :
?fre(0) -> 23415 s'affiche (il s'agit de la mémoire disponible)
CLEAR 200,&H9000 -> Ok
?fre(0) -> 3326 s'affiche
Autrement dit, cet ordre soustrait 20 Ko à la mémoire disponible. et 3 326 octets pour le programme et les variables (les tableaux surtout), ça fait un peu court...
Mais il me semble que 20 Ko pour un player, ça fait un peu beaucoup (à moins qu'il y ait aussi des samples)...
Igal,
L'ordre CLEAR 200,&H9000 indique, entre autre, que la zone mémoire située à partir de &H9000 ne doit pas être utilisée par le basic.
Je viens de taper les 3 commandes suivrantes sous bluemsx :
?fre(0) -> 23415 s'affiche (il s'agit de la mémoire disponible)
CLEAR 200,&H9000 -> Ok
?fre(0) -> 3326 s'affiche
Autrement dit, cet ordre soustrait 20 Ko à la mémoire disponible. et 3 326 octets pour le programme et les variables (les tableaux surtout), ça fait un peu court...
Mais il me semble que 20 Ko pour un player, ça fait un peu beaucoup (à moins qu'il y ait aussi des samples)...
Voila c'est fixé.
Il fallait simplement revoir à la baisse la quantité de mémoire allouée au BGM.BIN + MUSIQUE.BGM.
Pour rappel, voici la version qui fait planter.
2 CLEAR200,&H9000:BLOAD"bgm.bin"
Voici le correctif.
2 CLEAR200,&H9FFF:BLOAD"bgm.bin"
J'ai donc repris ta technique pour connaitre la quantité d'octets restants libres, et voici le résulta:
Apres le chargement et l'execution de MARIOFAT:
Je teste la mémoire et j'obtiens:
?FRE(0) => 22087 (Octets Restants libres)
J'effectue le teste en chargeant BGM.BIN en réservant la mémoire avec &h9000:
Je teste le restant de mémoire et j'obtiens:
?FRE(0) => 327 => Plantage du Moteur.
Après avoir fixé la quantité de mémoire allouée à BGM.BIN avec 9FFF au lieu de 9000:
Je teste le restant de mémoire et j'obtiens:
?FRE(0) => 2082 => Tout se passe bien.
Cette valeur peut varier d'une centaine d'octets en fonction du déroulement du scénario du Moteur MarioFat (lorsque Mario tombe dans un trou par exemple) mais ne Change pas en fonction de la musique .BGM chargée.
Nb: Toutes les fonctions audio Play etc...Sont accessibles en temps réel, ce qui est idéal pour personnaliser une action ou réaction dans le scénario.
Il reste donc environ 2 Ko de Mémoire libre. Il est sans doute possible de diminuer encore la quantité de mémoire allouée.
Une bonne nouvelle ne venant pas toute seule, J'ai mis la main sur SME3 PLAYER (auparavant je n'avais que SME3 Mini Démo).
SME3 PLAYER se prête très bien à la fonction de Loader Audio pour le moteur Mario Fat.
Dorénavant, le moteur Mario Fat à donc trouvé son Loader Audio Ultime puisque ce dernier reproduit à merveille simultanément les Puces Suivantes:
4 SCC + 2 Musiques Modules + 1 Fm Pac + Psg. Là encore, l'interactivité Aduio est au rendez vous, puisqu'il est possible de lancer les fonctions Play en temps réel.
Voici la nouvelle version de SME3FAT qui intègre dorénavant [le Player] et non plus [la Mini Démo].
SME3FAT.zip
Pour info, le player a été traduit en francais, et vous gardez la possibilité de choisir la musique de votre choix:
Ces modifications on été apportés:
210 GOTO 10000'DEFUSR=&HA006:A=USR(0):' Debute la musique
(Empêche la lecture de la musique, et renvoie à la ligne 10000)
10000 load"SME3FAT.bas
(Charge le moteur graphique)
Nb: Le Loader Audio SME3 (SME3 Player) génère un bug d'affichage lors du Scrooling du moteur Mario Fat.
Un Fix consiste à passer du Screen 5 au Screen 0 puis de nouveau le Screen 5.
Voici le Fix:
13 SCREEN5,2:SCREEN0
(Bascule en screen 5 puis screen 0)
20 SCREEN5,2:COLOR 15,1,1
EFINTA-Z(Suite normal du programme, donc Screen 5 de nouveau!)
Encore une Fois, si vous savez comment convertir les fichiers PR3 en PLY...Ou si vous avez des idées n'hésitez pas.
Bonsoir à tous.
Après une petite visite sur le Wiki du village, j'ai découvert la Fonction STRIG (0) qui répond à l'appuie de la barre d'espace très simplement.
Le But étant d'appliquer une animation spécifique (un coup d'épée) suggérant une attaque!
J'ai abordé la chose de la façon suivante.
1) La détection doit se faire à chaque Cycle.
2) Lorsque l'appui de la [Barre d'espace] est détecté, une autre séquence d'animation doit être affichée (Le coup d'épée).
Je vous expose directement les modifications, puis l'explication qui la soutient. (Des erreurs sont possibles, merci de votre indulgence)
Pour des raisons d'accessibilité, les avancées sont faites sur le moteur WINNIE de MsxOsaure (en attendant une lisibilité plus accessible du moteur MARIO FAT de Stapha )
ORIGINAL:
310 D=D+26:IF D = 208 THEN D = 0
D est le bloc à afficher, ici il s'incrémente de 26 pixels (largeur du bloque) et se limite à 208 (dernier pixel de la dernier image [8] à afficher).
MODIFICATIONS:
310 D=D+26:IF D = 208 THEN D = 52
J'ai décidé de consacrer 2 images aux coups d'épées (26+26=52), et 6 images par déplacement (de 52 à 208) Nord, Sud, Est, Ouest et enfin Statique.
Bien entendu, la matrice est dessinée en tenant compte de ces changements.
Pour plus de clarté, voici la Matrice:
La partie en rouge est celle affichée par défaut selon les directions choisis. Haut, Bas, Gauche et droite ainsi que pour les diagonales grâce aux commandes de la ligne 310.
La partie en noir sera jouée en cas d'appuie sur la [Barre d'espace] grâce aux commandes ne ligne 410.
ORIGINAL:
410 S=STICK(0)
MODIFICATIONS:
410 S=STICK(0):IFSTRIG(0)THEN D = 0
IF STRIG (0) THEN D = 0 signifie qu'en cas d'appui sur la [Barre d'espace], D prendra la valeur 0 et ce sera donc la partie en noir qui sera lue (Coups d'épée).
Le résulta est le suivant:
Nb: J'ai essayé de changer la position de la [Face] en modifiant l'ordre d'application du déplacement en diagonale.
Fait [face à droite] lors du déplacement diagonal DROITE/BAS en suivant cet ordre:
Fait [face en Bas] lors du déplacement diagonal DROITE/BAS en suivant cet ordre
mais aucun changement dans les [Actions] diagonales Bas/Droite. (Pas de coups d'épée)
Voici la disquette qui vous donnera une idée plus précise!
Il faut exécuter ZELDAVE.BAS
ZELDA.zip
Si vous avez une idée, merci de votre aide
Edité par
igal
Le 27/12/2010 à 22h36
Après une petite visite sur le Wiki du village, j'ai découvert la Fonction STRIG (0) qui répond à l'appuie de la barre d'espace très simplement.
Le But étant d'appliquer une animation spécifique (un coup d'épée) suggérant une attaque!
J'ai abordé la chose de la façon suivante.
1) La détection doit se faire à chaque Cycle.
2) Lorsque l'appui de la [Barre d'espace] est détecté, une autre séquence d'animation doit être affichée (Le coup d'épée).
Je vous expose directement les modifications, puis l'explication qui la soutient. (Des erreurs sont possibles, merci de votre indulgence
)Pour des raisons d'accessibilité, les avancées sont faites sur le moteur WINNIE de MsxOsaure (en attendant une lisibilité plus accessible du moteur MARIO FAT de Stapha
)ORIGINAL:
310 D=D+26:IF D = 208 THEN D = 0
D est le bloc à afficher, ici il s'incrémente de 26 pixels (largeur du bloque) et se limite à 208 (dernier pixel de la dernier image [8] à afficher).
MODIFICATIONS:
310 D=D+26:IF D = 208 THEN D = 52
J'ai décidé de consacrer 2 images aux coups d'épées (26+26=52), et 6 images par déplacement (de 52 à 208) Nord, Sud, Est, Ouest et enfin Statique.
Bien entendu, la matrice est dessinée en tenant compte de ces changements.
Pour plus de clarté, voici la Matrice:
La partie en rouge est celle affichée par défaut selon les directions choisis. Haut, Bas, Gauche et droite ainsi que pour les diagonales grâce aux commandes de la ligne 310.
La partie en noir sera jouée en cas d'appuie sur la [Barre d'espace] grâce aux commandes ne ligne 410.
ORIGINAL:
410 S=STICK(0)
MODIFICATIONS:
410 S=STICK(0):IFSTRIG(0)THEN D = 0
IF STRIG (0) THEN D = 0 signifie qu'en cas d'appui sur la [Barre d'espace], D prendra la valeur 0 et ce sera donc la partie en noir qui sera lue (Coups d'épée).
Le résulta est le suivant:
| DEPLACEMENT DE LINK | |||
|---|---|---|---|
| STATUT | MOUVEMENT | ACTION | COMENTAIRES |
| STATIQUE | MARTEAU | IMMOBILE | Je n'arrive pas à inverser l'action et le mouvement! |
| HAUT | DEPLACEMENT | COUPS D EPEE | La Face est dirigée vers le haut. Parfait |
| HAUT/DROIT | DEPLACEMENT | COUPS D EPEE | La face est dirigée vers la droite. Parfait |
| DROIT | DEPLACEMENT | COUPS D EPEE | La face est dirigée vers la droite. Parfait |
| DROIT/BAS | DEPLACEMENT | K.O | La face est dirigée vers la droite, mais pas d'action pq??? |
| BAS | DEPLACEMENT | COUPS D EPEE | La face est dirigée vers le bas. Parfait |
| BAS/GAUCHE | DEPLACEMENT | COUPS D EPEE | La face est dirigée vers la gauche. Parfait |
| GAUCHE | DEPLACEMENT | COUPS D EPEE | La face est dirigée vers la gauche.Parfait |
| GAUCHE/HAUT | DEPLACEMENT | K.O | La face est dirigée vers la gauche, mais pas d'actions pq??? |
Nb: J'ai essayé de changer la position de la [Face] en modifiant l'ordre d'application du déplacement en diagonale.
Fait [face à droite] lors du déplacement diagonal DROITE/BAS en suivant cet ordre:
Code TEXT :
2748 ' SP gestion mouvement: DROITE/BAS 2749 ' 2750 P=POINT(INT((X+8)/16),203+INT((Y-4)/16)) 2751 Q=POINT(INT((X+20)/16),203+INT((Y-4)/16)) 2752 Y=Y+4*(P>6)*(Q>6) 2753 P=POINT(INT((X+8)/16)+1,202+INT((Y+8)/16)) 2754 X=X-4*(P>6):A=38:RETURN
Fait [face en Bas] lors du déplacement diagonal DROITE/BAS en suivant cet ordre
Code TEXT :
2748 ' SP gestion mouvement: DROITE/BAS 2749 ' 2750 P=POINT(INT((X+8)/16)+1,202+INT((Y+8)/16)) 2751 X=X-4*(P>6) 2752 P=POINT(INT((X+8)/16),203+INT((Y-4)/16)) 2753 Q=POINT(INT((X+20)/16),203+INT((Y-4)/16)) 2754 Y=Y+4*(P>6)*(Q>6):A=152:RETURN
mais aucun changement dans les [Actions] diagonales Bas/Droite. (Pas de coups d'épée)
Voici la disquette qui vous donnera une idée plus précise!
Il faut exécuter ZELDAVE.BAS
ZELDA.zip
Si vous avez une idée, merci de votre aide
Edité par
igal
Le 27/12/2010 à 22h36
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie