La Place des Développeurs Mes 1ers pas sur MSX ...
Reprise du message précédent
Salut les zamis,J'ai une question :
est-il possible d'utiliser à la fois le stick et le clavier ?
Je m'explique : pour wii? je souhaite jouer
- avec 1 stick 2 boutons (fire1 = action, fire2 = pause..... ca, ca marche, c'est implémenté)
- avec 1 stick 1 bouton (Fire1 = action, ESC = pause...... aïe, j'y reviens plus bas)
- avec le clavier (directions + ESPACE= action et ESC = pause, pareil...)
pour la pause, je fais la chose suivante :
if ((get_trigger(3)==255) || (READKEY()==0x1b))
alors, get_trigger(3) lis l'état du FIRE2
et
READKEY utilise CHGET (0x009f) dans cette routine
unsigned char READKEY(void)
{
__asm
call KILBUF
call CHGET
ld L,A
__endasm;
}
eh bien qd je rajoute (READKEY()==0x1b) -0x1b étant le code retourné pour la touche ESC- le deplacement au stick ne fonctionne plus et le deplacement au clavier est ....très perturbé (saccade)
d'où ma question, peut-on facilement combiner stick+n'importe quelle touche du clavier
Merci et à bientôt
Hello les joyeux codeurs,
CHGET est une fonction assez lente qui n'est pas appropriée à ce que tu veux faire.
Il vaut mieux aller lire la KEY MATRIX c'est beaucoup plus rapide, car les concepteurs du MSX ont eu la bonne idée
de mettre l'état de chaque touche du clavier dans des variables système accessible en RAM.
Dans FUSION-C je l'ai implanté de façon très simple :
Le fonction GetKeyMatrix( char Line);
va retourner un octet correspondant à une ligne de la matrice clavier.
Chaque bit de cet octet correspond à l'état d'une touche.
1 : Not pressed
0 : pressed
Voici la matrice internationale du Clavier MSX
Si tu veux avoir l'état de la touche ESC, il te faut donc lire la ligne n°7 de la matrice, et interpréter le bit n°2
Si ce bit est à 0, alors la touche est pressée (comme une orange
)
Edité par ericb59 Le 13/03/2021 à 08h12
CHGET est une fonction assez lente qui n'est pas appropriée à ce que tu veux faire.
Il vaut mieux aller lire la KEY MATRIX c'est beaucoup plus rapide, car les concepteurs du MSX ont eu la bonne idée
de mettre l'état de chaque touche du clavier dans des variables système accessible en RAM.
Dans FUSION-C je l'ai implanté de façon très simple :
Code C :
#define GetKeyMatrix( data ) (*(char *)((0xFBE5+ data)))
Le fonction GetKeyMatrix( char Line);
va retourner un octet correspondant à une ligne de la matrice clavier.
Chaque bit de cet octet correspond à l'état d'une touche.
1 : Not pressed
0 : pressed
Voici la matrice internationale du Clavier MSX
Si tu veux avoir l'état de la touche ESC, il te faut donc lire la ligne n°7 de la matrice, et interpréter le bit n°2
Si ce bit est à 0, alors la touche est pressée (comme une orange
)Code C :
unsigned char esc; esc=(GetKeyMatrix(7) >>2) & 1; if (esc) { /// Touche ESCAPE NOT PRESSED } else { // Touche ESC PRESSED }
Edité par ericb59 Le 13/03/2021 à 08h12
Données disponibles en mémoire
Pour compléter, le système MSX (qui s'exécute 50/60 fois par seconde) va mettre à jour des variables en mémoire avec l'état de toutes les touches du clavier et des boutons des joysticks.
Tu vas y trouver :
- L'état actuel des touches (comme indiqué par Eric) à l'adresse 0xFBE5
Code C :
#define M_NEWKEY 0xFBE5 // 11 New status of each keyboard matrix row. The status is updated by the KEYINT interrupt routine. // Bit correspondence for a European Keyboard Layout: // NEWKEY+0 = 7 6 5 4 3 2 1 0 // NEWKEY+1 = ; ] [ \ = - 9 8 // NEWKEY+2 = B A ACCENT / . , ` ' // NEWKEY+3 = J I H G F E D C // NEWKEY+4 = R Q P O N M L K // NEWKEY+5 = Z Y X W V U T S // NEWKEY+6 = F3 F2 F1 CODE CAPS GRPH CTRL SHIFT // NEWKEY+7 = RET SEL BS STOP TAB ESC F5 F4 // NEWKEY+8 = RIGHT DOWN UP LEFT DEL INS HOME SPACE // NEWKEY+9 = 4 3 2 1 0 / + * // NEWKEY+10 = . , - 9 8 7 6 5 // See here for other keyboard layouts. const unsigned char __at(M_NEWKEY) g_NEWKEY[11];
-
Code C :
#define M_OLDKEY 0xFBDA // 11 Previous status of each keyboard matrix row. const unsigned char __at(M_OLDKEY) g_OLDKEY[11];
- L'état des boutons des 2 joysticks à l'adresse 0xF3E8.
Code C :
#define M_TRGFLG 0xF3E8 // 1 Information about trigger buttons and space bar state // 7 6 5 4 3 2 1 0 // │ │ │ │ └── Space bar, trig(0) (0 = pressed) // │ │ │ └────────── Stick 1, Trigger 1 (0 = pressed) // │ │ └──────────── Stick 1, Trigger 2 (0 = pressed) // │ └────────────── Stick 2, Trigger 1 (0 = pressed) // └──────────────── Stick 2, Trigger 2 (0 = pressed) const unsigned char __at(M_TRGFLG) g_TRGFLG;
Définir une variable const unsigned char __at(0xF3E8) g_TRGFLG; va te permettre de pouvoir facilement y accéder de n'importe ou dans ton code.
Par exemple, tu peux faire if((g_TRGFLG & 0x20) == 0) pour détecter l'appuis sur le bouton 2 du joystick 1.
PS : Le système MSX ne met à jour ces informations qu'une fois sur deux (donc 25/30 fois par seconde), mais c'est amplement suffisant pour tes besoins.
Routine du BIOS
Pour la direction des sticks, il n'y a pas de variable BIOS qui contienne cette info à ma connaissance donc tu dois passer une fonction du BIOS : GTTRIG (à l'adresse 0x00D8).
Code ASM :
GTTRIG Address : #00D8 Function : Returns current trigger status Input : A - Trigger button to test 0 = space bar 1 = port 1, button A 2 = port 2, button A 3 = port 1, button B 4 = port 2, button B Output : A - #00 trigger button not pressed #FF trigger button pressed Registers: AF
Accès direct au PSG
Sinon, tu peux aussi accéder directement aux registres du PSG (oui, c'est le processeur sonore qui gère le joystick
).Je vais pas entrer dans le détail, mais c'est la façon la plus optimale de faire (et celle que j'utilise dans ma lib).
Cf. :
- https://github.com/aoineko-fr/CMSX/blob/master/cmsx/src/input.h
- https://github.com/aoineko-fr/CMSX/blob/master/cmsx/src/input.c
Et pour en revenir à ton problème, il n'y a absolument aucune raison que la lecture du clavier impact celle du joystick ou inversement.
On est toujours ignorant avant de savoir.
ericb59 :
Ha ! Je ne savais pas qu'il y avait l'état précédent des touches en 0xF3E8 
Fausse joie.
Le Bios utilise bien cet espace pour stocker les valeurs précédentes, mais ils les écrasent avant la fin de l'interruption.
Du coup, coté programme, tu as toujours OLDKEY == NEWKEY.
Il faut donc sauvegarder soi-même ces valeurs dans notre programme si on veut détecter les appuis/relâchement de touches.
On est toujours ignorant avant de savoir.
@Ricco, un p'tit cadeau :
Avec ça, tu peux maintenant lire n'importe quelle touche du clavier sans te soucier de connaitre dans quelle rangée (row) elle se trouve et sans aucun appel de fonction.
Il te suffit par exemple de faire if(IS_KEY_PRESSED(KEY_F1)) pour savoir si la touche F1 est enfoncée, ou if(IS_KEY_PRESSED(KEY_N)) pour la touche N.
Code C :
#define MAKE_KEY(r, b) ((b << 4) | r) #define KEY_ROW(key) (key & 0x0F) #define KEY_IDX(key) (key >> 4) #define KEY_FLAG(key) (1 << KEY_IDX(key)) #define KEY_0 MAKE_KEY(0, 0) #define KEY_1 MAKE_KEY(0, 1) #define KEY_2 MAKE_KEY(0, 2) #define KEY_3 MAKE_KEY(0, 3) #define KEY_4 MAKE_KEY(0, 4) #define KEY_5 MAKE_KEY(0, 5) #define KEY_6 MAKE_KEY(0, 6) #define KEY_7 MAKE_KEY(0, 7) #define KEY_8 MAKE_KEY(1, 0) #define KEY_9 MAKE_KEY(1, 1) #define KEY_1_2 MAKE_KEY(1, 2) #define KEY_1_3 MAKE_KEY(1, 3) #define KEY_1_4 MAKE_KEY(1, 4) #define KEY_1_5 MAKE_KEY(1, 5) #define KEY_1_6 MAKE_KEY(1, 6) #define KEY_1_7 MAKE_KEY(1, 7) #define KEY_2_0 MAKE_KEY(2, 0) #define KEY_2_1 MAKE_KEY(2, 1) #define KEY_2_2 MAKE_KEY(2, 2) #define KEY_2_3 MAKE_KEY(2, 3) #define KEY_2_4 MAKE_KEY(2, 4) #define KEY_2_5 MAKE_KEY(2, 5) #define KEY_A MAKE_KEY(2, 6) #define KEY_B MAKE_KEY(2, 7) #define KEY_C MAKE_KEY(3, 0) #define KEY_D MAKE_KEY(3, 1) #define KEY_E MAKE_KEY(3, 2) #define KEY_F MAKE_KEY(3, 3) #define KEY_G MAKE_KEY(3, 4) #define KEY_H MAKE_KEY(3, 5) #define KEY_I MAKE_KEY(3, 6) #define KEY_J MAKE_KEY(3, 7) #define KEY_K MAKE_KEY(4, 0) #define KEY_L MAKE_KEY(4, 1) #define KEY_M MAKE_KEY(4, 2) #define KEY_N MAKE_KEY(4, 3) #define KEY_O MAKE_KEY(4, 4) #define KEY_P MAKE_KEY(4, 5) #define KEY_Q MAKE_KEY(4, 6) #define KEY_R MAKE_KEY(4, 7) #define KEY_S MAKE_KEY(5, 0) #define KEY_T MAKE_KEY(5, 1) #define KEY_U MAKE_KEY(5, 2) #define KEY_V MAKE_KEY(5, 3) #define KEY_W MAKE_KEY(5, 4) #define KEY_X MAKE_KEY(5, 5) #define KEY_Y MAKE_KEY(5, 6) #define KEY_Z MAKE_KEY(5, 7) #define KEY_SHIFT MAKE_KEY(6, 0) #define KEY_CTRL MAKE_KEY(6, 1) #define KEY_GRAPH MAKE_KEY(6, 2) #define KEY_CAPS MAKE_KEY(6, 3) #define KEY_CODE MAKE_KEY(6, 4) #define KEY_F1 MAKE_KEY(6, 5) #define KEY_F2 MAKE_KEY(6, 6) #define KEY_F3 MAKE_KEY(6, 7) #define KEY_F4 MAKE_KEY(7, 0) #define KEY_F5 MAKE_KEY(7, 1) #define KEY_ESC MAKE_KEY(7, 2) #define KEY_TAB MAKE_KEY(7, 3) #define KEY_STOP MAKE_KEY(7, 4) #define KEY_BS MAKE_KEY(7, 5) #define KEY_SELECT MAKE_KEY(7, 6) #define KEY_RET MAKE_KEY(7, 7) #define KEY_SPACE MAKE_KEY(8, 0) #define KEY_HOME MAKE_KEY(8, 1) #define KEY_INS MAKE_KEY(8, 2) #define KEY_DEL MAKE_KEY(8, 3) #define KEY_LEFT MAKE_KEY(8, 4) #define KEY_UP MAKE_KEY(8, 5) #define KEY_DOWN MAKE_KEY(8, 6) #define KEY_RIGHT MAKE_KEY(8, 7) #define KEY_NUM_MUL MAKE_KEY(9, 0) #define KEY_NUM_ADD MAKE_KEY(9, 1) #define KEY_NUM_DIV MAKE_KEY(9, 2) #define KEY_NUM_0 MAKE_KEY(9, 3) #define KEY_NUM_1 MAKE_KEY(9, 4) #define KEY_NUM_2 MAKE_KEY(9, 5) #define KEY_NUM_3 MAKE_KEY(9, 6) #define KEY_NUM_4 MAKE_KEY(9, 7) #define KEY_NUM_5 MAKE_KEY(10, 0) #define KEY_NUM_6 MAKE_KEY(10, 1) #define KEY_NUM_7 MAKE_KEY(10, 2) #define KEY_NUM_8 MAKE_KEY(10, 3) #define KEY_NUM_9 MAKE_KEY(10, 4) #define KEY_NUM_MIN MAKE_KEY(10, 5) #define KEY_NUM_COM MAKE_KEY(10, 6) #define KEY_NUM_DOT MAKE_KEY(10, 7) #define M_NEWKEY 0xFBE5 // New status of each keyboard matrix row. The status is updated by the KEYINT interrupt routine. const u8 __at(M_NEWKEY) g_NEWKEY[11]; #define IS_KEY_PRESSED(key) ((g_NEWKEY[KEY_ROW(key)] & KEY_FLAG(key)) == 0)
Avec ça, tu peux maintenant lire n'importe quelle touche du clavier sans te soucier de connaitre dans quelle rangée (row) elle se trouve et sans aucun appel de fonction.
Il te suffit par exemple de faire if(IS_KEY_PRESSED(KEY_F1)) pour savoir si la touche F1 est enfoncée, ou if(IS_KEY_PRESSED(KEY_N)) pour la touche N.
On est toujours ignorant avant de savoir.
Un très grand MERCI les potos,
Hier soir j'avais commencé à regarder cette histoire de matrice et de NEW/OLD-KEY mais le regard de Dominique Webb a rendu mes paupières très lourdes hihihi
J'essaierai ce soir de mettre en pratique en plus des éléments que vous m'avez laissés
Merci encore pour votre aide
Edité par Ricco59 Le 13/03/2021 à 17h23
Hier soir j'avais commencé à regarder cette histoire de matrice et de NEW/OLD-KEY mais le regard de Dominique Webb a rendu mes paupières très lourdes hihihi
J'essaierai ce soir de mettre en pratique en plus des éléments que vous m'avez laissés
Merci encore pour votre aide
Edité par Ricco59 Le 13/03/2021 à 17h23
RE les potos
la version 4.1.0 de SDCC est là
j'ai compilé Wii? et voici les tailles correspondantes (la v400 etait bien bugguée...)
3.9.0 30886 octets
4.0.0 30850 octets
4.1.0 30689 octets
plus de 150 octets gagnés pour la 410 par rapport à la 400...
Je vais remettre des boucles qui plantaient avec wii? en compilant avec la v4.0.0. Je vais donc voir si c'est mieux ou non
Tchao tertousss
la version 4.1.0 de SDCC est là
j'ai compilé Wii? et voici les tailles correspondantes (la v400 etait bien bugguée...)
3.9.0 30886 octets
4.0.0 30850 octets
4.1.0 30689 octets
plus de 150 octets gagnés pour la 410 par rapport à la 400...
Je vais remettre des boucles qui plantaient avec wii? en compilant avec la v4.0.0. Je vais donc voir si c'est mieux ou non
Tchao tertousss
@aoineko @Ricco
Petite précision tout de même à apporter.
Les matrices clavier différent suivant les langues, et parfois suivant les modèles de MSX.
Si tu te base sur la matrice international pour récupérer le statut d'une lettre "Q" par exemple. Sur un clavier français elle sera noté "A", l'utilisateur n'utilisera donc pas cette touche si tu veux le faire appuyer sur "Q".
Attention donc à ce que tu veux checker...
Par contre, les touches "Spéciales" ESC, GRAPH, SHIFT, RETURN, F1 à F5 etc ... sont standardisée sur toutes les matrices (ile me semble), donc aucun problème de ce coté là.
Il y a quelques exemple de Matrices clavier ici :
https://www.msx.org/wiki/Keyboard Edité par ericb59 Le 13/03/2021 à 18h36
Petite précision tout de même à apporter.
Les matrices clavier différent suivant les langues, et parfois suivant les modèles de MSX.
Si tu te base sur la matrice international pour récupérer le statut d'une lettre "Q" par exemple. Sur un clavier français elle sera noté "A", l'utilisateur n'utilisera donc pas cette touche si tu veux le faire appuyer sur "Q".
Attention donc à ce que tu veux checker...
Par contre, les touches "Spéciales" ESC, GRAPH, SHIFT, RETURN, F1 à F5 etc ... sont standardisée sur toutes les matrices (ile me semble), donc aucun problème de ce coté là.
Il y a quelques exemple de Matrices clavier ici :
https://www.msx.org/wiki/Keyboard Edité par ericb59 Le 13/03/2021 à 18h36
Ricco59 :
la version 4.1.0 de SDCC est là
Cool
Je viens d'intégrer la 4.1.0 dans ma lib ; tout semble fonctionner nickel.
Voici la liste complète des modifications de cette version : https://sourceforge.net/p/sdcc/wiki/SDCC%204.1.0%20Release/
Je vais creuser un peu pouvoir s'il y a des modifications significatives.
ericb59 :
Petite précision tout de même à apporter.
Les matrices clavier différent suivant les langues, et parfois suivant les modèles de MSX.
Les matrices clavier différent suivant les langues, et parfois suivant les modèles de MSX.
Oui, ça dépend des besoins. Si c'est pour récupérer du texte, il faut passer par les fonctions du Bios (ou gérer les langues soi-même).
Par contre, si tu veux juste la position des touches sur le clavier, peut importante la langue, les touches seront toujours au même endroit.
Par ex., le WASD se trouve au même endroit sur un clavier français, même s'il s'appel ZQSD.
J'aurai du le préciser, mais les defines donne le nom des touches dans la configuration Internationale (QWERTY).
On est toujours ignorant avant de savoir.
Faudrait un jour que tu m'expliques tes #define intégrants des 'fonctions', ca m'a l'air super interessant
Voici ce que je vais mettre en place pour la lecture de la touche ESC qui 'matricement' parlant est toujours à row = 7 et bit = 2
unsigned char *pKB = (unsigned char *)0xFBEC;
if (*pKB == 0xfb) // ESC pressed
J'ai un pointeur KB qui 'pointe' sur 0xFBE5 + 7 (row) = 0xFBEC
si ESC est appuyé, j'obtiens l'octet suivant;
7654 3210
%1111 1011
bit 2 eteint
J'implémente ça et je vous tiens au jus
Stay tuned
edit : CA MAAAARRRRCHHHHEEEEE
Je continue ...
Edité par Ricco59 Le 14/03/2021 à 00h15
Voici ce que je vais mettre en place pour la lecture de la touche ESC qui 'matricement' parlant est toujours à row = 7 et bit = 2
unsigned char *pKB = (unsigned char *)0xFBEC;
if (*pKB == 0xfb) // ESC pressed
J'ai un pointeur KB qui 'pointe' sur 0xFBE5 + 7 (row) = 0xFBEC
si ESC est appuyé, j'obtiens l'octet suivant;
7654 3210
%1111 1011
bit 2 eteint
J'implémente ça et je vous tiens au jus
Stay tuned
edit : CA MAAAARRRRCHHHHEEEEE
Je continue ...
Edité par Ricco59 Le 14/03/2021 à 00h15
Les defines c'est du code qui est interprété par la pré-compilation (qu'on ne retrouves pas dans le fichier binaire final).
En gros, avant de compiler ton code C, le pré-compilateur va remplacer successivement tous tes defines par leur valeur.
Par ex, si tu as ces 2 deux defines et ce bout de code :
Le pré-compilateur va faire ces remplacements :
Ensuite, le compilateur va compiler le code C comme si tu avais écris key = 39 dans ton code.
L'avantage c'est que tu peux centraliser des traitements sans aucun surcout pour le code.
Pour prendre un exemple plus complexe, prenons if(IS_KEY_PRESSED(KEY_ESC)) avec les defines que je t'ai donné.
Pour rappel, les defines qui vont être utilisé ici :
Et la série des remplacements :
Tu obtient à la fin un simple test du 3e bit de rangée 7 ; celui qui correspond à l'appuis sur la touche Escape.
Le gros avantage, c'est que tu peux tester n'importe quelle touche avec la même macro sans avoir besoin de connaitre sa rangée (qui est stocké directement dans l'ID de la touche) et surtout sans aucun surcout pour le CPU car tous ces remplacements ont lieu avant la compilation et n'ont donc aucun impact sur les performance de ton jeu.
Par ex. :
J'espère que c'est plus clair.
En gros, avant de compiler ton code C, le pré-compilateur va remplacer successivement tous tes defines par leur valeur.
Par ex, si tu as ces 2 deux defines et ce bout de code :
Code C :
#define MAKE_KEY(r, b) ((b << 4) | r) #define KEY_ESC MAKE_KEY(7, 2) unsigned char key = KEY_ESC;
Le pré-compilateur va faire ces remplacements :
Code C :
unsigned char key = KEY_ESC; ... unsigned char key = MAKE_KEY(7, 2); // remplacement de KEY_ESC ... unsigned char key = ((2 << 4) | 7); // remplacement de MAKE_KEY(7, 2) ... unsigned char key = 39; // remplacement du calcul litéral
Ensuite, le compilateur va compiler le code C comme si tu avais écris key = 39 dans ton code.
L'avantage c'est que tu peux centraliser des traitements sans aucun surcout pour le code.
Pour prendre un exemple plus complexe, prenons if(IS_KEY_PRESSED(KEY_ESC)) avec les defines que je t'ai donné.
Pour rappel, les defines qui vont être utilisé ici :
Code C :
#define KEY_ROW(key) (key & 0x0F) #define KEY_IDX(key) (key >> 4) #define KEY_FLAG(key) (1 << KEY_IDX(key)) ... #define KEY_ESC MAKE_KEY(7, 2) ... #define M_NEWKEY 0xFBE5 // New status of each keyboard matrix row. The status is updated by the KEYINT interrupt routine. const u8 __at(M_NEWKEY) g_NEWKEY[11]; #define IS_KEY_PRESSED(key) ((g_NEWKEY[KEY_ROW(key)] & KEY_FLAG(key)) == 0)
Et la série des remplacements :
Code C :
if(IS_KEY_PRESSED(KEY_ESC)) ... if(IS_KEY_PRESSED(39)) // je répète pas les étapes vu au dessus pour passer de KEY_ESC à 39 ... if((g_NEWKEY[KEY_ROW(39)] & KEY_FLAG(39)) == 0) // remplacement de IS_KEY_PRESSED ... if((g_NEWKEY[39 & 0x0F] & KEY_FLAG(39)) == 0) // remplacement de KEY_ROW ... if((g_NEWKEY[39 & 0x0F] & (1 << KEY_IDX(39))) == 0) // remplacement de KEY_FLAG ... if((g_NEWKEY[39 & 0x0F] & (1 << (39 >> 4))) == 0) // remplacement de KEY_IDX ... if((g_NEWKEY[7] & 4) == 0) // remplacement des calculs litéraux
Tu obtient à la fin un simple test du 3e bit de rangée 7 ; celui qui correspond à l'appuis sur la touche Escape.
Le gros avantage, c'est que tu peux tester n'importe quelle touche avec la même macro sans avoir besoin de connaitre sa rangée (qui est stocké directement dans l'ID de la touche) et surtout sans aucun surcout pour le CPU car tous ces remplacements ont lieu avant la compilation et n'ont donc aucun impact sur les performance de ton jeu.
Par ex. :
Code C :
if(IS_KEY_PRESSED(KEY_F1)) if(IS_KEY_PRESSED(KEY_ESC)) if(IS_KEY_PRESSED(KEY_7)) if(IS_KEY_PRESSED(KEY_RIGHT)) if(IS_KEY_PRESSED(KEY_K)) if(IS_KEY_PRESSED(KEY_SHIFT) && IS_KEY_PRESSED(KEY_C)) // Shift + C ...
J'espère que c'est plus clair.
On est toujours ignorant avant de savoir.
Les #define tel que tu les utilises c'est super
pratique. Et c'est comme ça qu'il faut faire, tu es tout à fait dans le vrai, un véritable pro du C, et un codeur expérimenté.
Personnellement ça me perturbe énormément, car je trouve que ça complexifie énormément la lecture et la compréhension du code.
Pour le codeur à l'origine des macros, c'est simple, pour un codeur extérieur c'est plus complexe à déchiffrer.
Mais l'important c'est d'avoir un code qui tourne bien, pas forcément un code lisible.
(Quoi que )
Comme j'ai pas 15 ans d'expérience du C, je m'incline devant tant de sagesse et d'expérience, et ça me permet de progresser.
Personnel ment j'ai appris le C il y a 5/6 ans en même temps que ma fille qui faisait l'Ecole 42.
pratique. Et c'est comme ça qu'il faut faire, tu es tout à fait dans le vrai, un véritable pro du C, et un codeur expérimenté.
Personnellement ça me perturbe énormément, car je trouve que ça complexifie énormément la lecture et la compréhension du code.
Pour le codeur à l'origine des macros, c'est simple, pour un codeur extérieur c'est plus complexe à déchiffrer.
Mais l'important c'est d'avoir un code qui tourne bien, pas forcément un code lisible.
(Quoi que
)Comme j'ai pas 15 ans d'expérience du C, je m'incline devant tant de sagesse et d'expérience, et ça me permet de progresser.
Personnel ment j'ai appris le C il y a 5/6 ans en même temps que ma fille qui faisait l'Ecole 42.
C'est GENIAL Guillaume,
merci pour partager tes compétences et tes explications. Bien que je ne maitrise pas encore cette façon de travailler ni le C (faut vraiment que je m'attele aux pointeurs et sur le comment compiler 1 code source avec plusieurs machines cibles), je vais étudier
Pour en revenir à Wii? au niveau des contrôles, j'ai :
- clavier (touches directionnelles, espace = ACTION, esc = PAUSE)
- Stick 1 bouton (fire = ACTION, esc = PAUSE)
- Stick 2 boutons (Fire1 = ACTION, Fire2 = PAUSE)
Yapuka essayer sur une vraie machine
Oui, je peux faire une pause sur Wii? mais pour éviter de permettre à chacun de faire une pause et de chercher tranquillement la matrice 3x3 dans la mosaïque, une image représentant la pause (carré blanc+symbole bleu clignottant) cache la matrice 3x3 qui change en permanence tant que le joueur n'a pas rappuyer sur Fire1. Bin oué quoi
Prochaines étapes :
- debugger le MENU
- Ajouter des sons (comment les créer, comment les jouer ??)
Bon dimanche les zamis
Edité par
Ricco59
Le 14/03/2021 à 09h45
merci pour partager tes compétences et tes explications. Bien que je ne maitrise pas encore cette façon de travailler ni le C (faut vraiment que je m'attele aux pointeurs et sur le comment compiler 1 code source avec plusieurs machines cibles), je vais étudier
Pour en revenir à Wii? au niveau des contrôles, j'ai :
- clavier (touches directionnelles, espace = ACTION, esc = PAUSE)
- Stick 1 bouton (fire = ACTION, esc = PAUSE)
- Stick 2 boutons (Fire1 = ACTION, Fire2 = PAUSE)
Yapuka essayer sur une vraie machine
Oui, je peux faire une pause sur Wii? mais pour éviter de permettre à chacun de faire une pause et de chercher tranquillement la matrice 3x3 dans la mosaïque, une image représentant la pause (carré blanc+symbole bleu clignottant) cache la matrice 3x3 qui change en permanence tant que le joueur n'a pas rappuyer sur Fire1. Bin oué quoi
Prochaines étapes :
- debugger le MENU
- Ajouter des sons (comment les créer, comment les jouer ??)
Bon dimanche les zamis
Edité par
Ricco59
Le 14/03/2021 à 09h45
ericb59 :
Pour le codeur à l'origine des macros, c'est simple, pour un codeur extérieur c'est plus complexe à déchiffrer.
Mais l'important c'est d'avoir un code qui tourne bien, pas forcément un code lisible.
Mais l'important c'est d'avoir un code qui tourne bien, pas forcément un code lisible.
Les macros peuvent complexifier la compréhension de « comment est fait le code », mais par contre je trouve qu'elles peuvent améliorer grandement la compréhension de « ce que fait le code ».
Ce qui me semble presque plus important pour s'y retrouver dans un code source.
Par ex., je trouve qu'en terme de lisibilité, y a pas photo entre :
- if (*pKB == 0xfb)
et
- if(IS_KEY_PRESSED(KEY_ESC))
Ricco59 :
- Ajouter des sons (comment les créer, comment les jouer ??)
Personnellement, j'utilise ayFX (format qui semble assez rependu pour jouer des sons sur MSX).
Ce format à un éditeur que je trouve très pratique (http://shiru.untergrund.net/files/ayfxedit.zip)
Il existe un replayer en assembleur Z80 qui a servi de base à tous les autres (http://www.z80st.es/downloads/code/ayFX-replayer-1.31.rar).
J'en ai fait un wrapper en C pour ma lib et j'ai ajouté quelques fonctionnalités (https://github.com/aoineko-fr/CMSX/tree/master/cmsx/src/ayFX).
Eric (l'autre qui n'est pas toi
), utilise aussi ce format dans sa lib Fusion-C.
On est toujours ignorant avant de savoir.
Merci pour AYsfx et tout le reste Ca va etre chaud, il me reste moins de 2ko...
C'est vrai que ton 'écriture' est bcp plus compréhensible. C'est un reflexe que je dois prendre
Je reviens vers vous pour un nième problème
Dans 'Where is it ?' lorsque le joueur trouve la bonne matrice 3x3 dans la mosaïque, il marque des points (c'est normal héhéhé). Cela dit, comme sur la version coleco, je voudrais un visuel en même temps qu'un effet sonore
Les petits points représentant le chrono sont sur un fond noir, mais pas le 1, mais le ZERO
De fait, quand je change la couleur du border, la couleur change (j'ai testé avec openMSX et openMSX debugger)
Dès que je valide la bonne matrice, l'effet est présent mais j'ai des carrés noirs qui apparaissent à l'écran. Je ne dois pas utiliser la bonne méthode qui est ci-dessous :
void Border12(void)
{
__asm
ld hl,#BDRCLR // > Adresse couleur border
ld a,#12 // couleur vert foncé
ld (hl),a //
CALL CHGCLR
__endasm;
}
Effet désiré
Effet obtenu, des carrés noirs sont venus me contrarier
si vous avez des pistes, ce dont je ne doute pas, je suis preneur... comme d'hab
Merci encore
Edité par Ricco59 Le 17/03/2021 à 21h40
Ca va etre chaud, il me reste moins de 2ko...C'est vrai que ton 'écriture' est bcp plus compréhensible. C'est un reflexe que je dois prendre
Je reviens vers vous pour un nième problème
Dans 'Where is it ?' lorsque le joueur trouve la bonne matrice 3x3 dans la mosaïque, il marque des points (c'est normal héhéhé). Cela dit, comme sur la version coleco, je voudrais un visuel en même temps qu'un effet sonore
Les petits points représentant le chrono sont sur un fond noir, mais pas le 1, mais le ZERO
De fait, quand je change la couleur du border, la couleur change (j'ai testé avec openMSX et openMSX debugger)
Dès que je valide la bonne matrice, l'effet est présent mais j'ai des carrés noirs qui apparaissent à l'écran. Je ne dois pas utiliser la bonne méthode qui est ci-dessous :
void Border12(void)
{
__asm
ld hl,#BDRCLR // > Adresse couleur border
ld a,#12 // couleur vert foncé
ld (hl),a //
CALL CHGCLR
__endasm;
}
Effet désiré
Effet obtenu, des carrés noirs sont venus me contrarier
si vous avez des pistes, ce dont je ne doute pas, je suis preneur... comme d'hab
Merci encore
Edité par Ricco59 Le 17/03/2021 à 21h40
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie