rapidité en C - Page 1

bon, j'ai fait mon ptit joujou dla balle qui se ballade dans l'ecran (j'avais un peu oublié et jmy suis rmis, merci tous) et jme demandais comment kon pouvait faire pour ke la balle avance VITE quand on reste appuyé sur une touche ...
vala la source // C Source File // Created 09/11/2003; 16:57:16 #define USE_TI89              // Compile for TI-89 #define USE_TI92PLUS          // Compile for TI-92 Plus // #define OPTIMIZE_ROM_CALLS // Use ROM Call Optimization #define MIN_AMS 100           // Compile for AMS 1.00 or higher #define SAVE_SCREEN           // Save/Restore LCD Contents #include <tigcclib.h>         // Include All Header Files unsigned char ball_sprite [] = {0b11111111,                                                                                 0b01111110,                                                                                  0b00111100,                                                                                 0b00011000,                                                                                 0b00011000,                                                                                 0b00111100,                                                                                  0b01111110,                                                                                   0b11111111};   // Main Function    void _main(void)  {                 int a;              short xpos=(LCD_WIDTH-1)/2;       short ypos=(LCD_HEIGHT-1)/2;              ClrScr ();       Sprite8 (xpos,ypos,8,ball_sprite,LCD_MEM,SPRT_OR);              while (_keytest (RR_ESC)==FALSE)       {                                       a=ngetchx();                                           if (a==337)            {                 Sprite8 (xpos,ypos,8,ball_sprite,LCD_MEM,SPRT_XOR);                 ypos=ypos-1;            }                        else if(a==344)            {                 Sprite8 (xpos,ypos,8,ball_sprite,LCD_MEM,SPRT_XOR);                 xpos=xpos+1;            }                        else if(a==340)            {                 Sprite8 (xpos,ypos,8,ball_sprite,LCD_MEM,SPRT_XOR);                 ypos=ypos+1;            }                        else if(a==338)            {             Sprite8 (xpos,ypos,8,ball_sprite,LCD_MEM,SPRT_XOR);             xpos=xpos-1;            }                        if (xpos+8>(LCD_WIDTH-1)) xpos=-1;            if (xpos<0) xpos=1;            if (ypos+8>(LCD_HEIGHT-1)) ypos=-1;            if (ypos<0) ypos=1;                        Sprite8 (xpos,ypos,8,ball_sprite,LCD_MEM,SPRT_OR);                   }  }
merci a tous et a toutes
++

Utiliser _keytest

Je viens d'essayer le programme et j'ai pas vu de balle.
De plus tu utilise getchx qui attend l'appuye d'une touche prend une fonction qui scrute le clavier en permanence comme _keytest.

ngetchx scrute le clavier en parmanence. _keytest ne scrute le clavier qu'une fois, et encore, pas tout le clavier...
Le problème, c'est que ngetchx introduit une temporisation entre deux répétitions.

La lenteur de ngetchx n'a pas à voir avec la détection du clavier, mais avec les routines de link.

Ah ? Pourquoi ?

Parce que ngetchx réagit aussi au link, pas seulement au clavier.

La lecture du clavier est assurée à 100% par l'auto-int 1, donc il suffit juste d'aller chercher les touches au bon endroit pour les lire. ngetchx/kbhit, en plus d'aller chercher le code de la touche éventuel, s'amuse à regarder si on envoie pas qqch par le link (c'est comme ça que fonctionne la connexion TI-PC), et ça ralentit beaucoup. L'auto-int 1, elle aussi, est lente, mais ce n'est rien comparé à ngetchx

Il se passe quoi plus précisément ?
Mais je pense que la lenteur vient aussi et surtout du fait que le ngetchx impose un temps de répétition...

[edit] Pollux> cross-post

OK, donc l'AI1 lit le clavier et donne le n° de la touche pressée qqpart en mémoire.
Donc effectivement ngetchx n'a plus qu'à lire ça.

Comment se comporte ngetchx si on envoie qqch par le link ?

Ah oui, cross post

Et encore...

./10> ben il décode les paquets, par exemple : réception de variables (donc ça peut modifier la VAT => les pointeurs vers des hdl non lockés et les HSym sont invalidés, donc ça doit faire un joli trou de sécurité pour pas mal de progs ), envoi de la liste des variables, etc...

Et j'allais oublier aussi que même les pointeurs vers des handles lockés sont invalidés, si le handle est le contenu d'un fichier en ROM (réception de FlashApps) Et ça peut être encore pire si le code d'installation de la FlashApp contient des trucs pas très catholiques (du genre, elle suppose que l'application en cours est Home). Mais je ne suis pas sûr que l'installation de FlashApp soit activée avec ngetchx(), en fait (ou alors, peut-être que la véritable installation de la flashapp se passe au prochain EV_loop, i.e. prochaine boîte de dialogue Encore une raison de ne pas utiliser les boîtes de dialogue...)

./12> oué

Ce code est n'importe quoi:
1. tu mélanges _keytest et ngetchx. Ce n'est pas possible! Pour le premier, il faut obligatoirement rediriger les auto-interruptions n°1 et 5. Le deuxième a besoin de l'auto-interruption n°1.
2. (et c'est ça qui "ralentit"): tu utilises ngetchx n'importe comment. Utilisé comme ça, il attend un appui de touche. Il faut d'abord tester kbhit.

Tu pourrais essayer d'être plus aimable, Kevin ? tu peux me parler comme ça, puisque je suis pas toujours gentil avec toi, mais VauDou débute et ne t'a rien fait

(et c'est ça qui "ralentit")

Pas sûr, à mon avis ça accélère même plutôt (si on laisse la touche appuyée bien sûr ) : si la touche est déjà dans le buffer, alors kbhit() sera tout aussi lent que ngetchx(), mais on devra en plus se taper un ngetchx() pour vider le buffer -> 2x plus lent ; et si la touche n'est pas dans le buffer, ngetchx() attendra juste ce qu'il faut, alors qu'on sera obligé de faire des itérations supplémentaires de la boucle principale avec kbhit().
Evidemment, pour un "vrai" jeu mieux vaut utiliser kbhit/ngetchx que ngetchx tout seul, mais dans ce cas précis ngetchx tout seul devrait être plus rapide.

Dites je vois pas pkoi detecter le link ralentit tant que ca ngetchx... C'est juste un cmp.w #4,ReceiveBufferSize

utilise _rowread ca lit le clavier à bas niveau

cf ./2

Quel est l'opérateur le plus rapide : "_rowread" ou "_keytest" ?

pour un _keytest simple, pas de différence, puisqu'il est traduit en _rowread. Pour un _keytest_optimised, il fait des trucs en plus pour éviter de refaire un _rowread inutilement

ok mci alors je vais remplacer _keytest

Une alternative à ngetchx est OSDequeue, vraiment plus rapide. Il faut juste savoir que cette fonction ne stoquera rien dans l'entier passé en référence si aucune touche n'a été appuyée.
Le code de la touche résultant est identique à ngetchx, donc pas de problème.
=top_estack; return GetIntArg(argptr); }

Question lenteur on peut encore faire pire:short AttendTouche()		{
	GKeyFlush();
	while (!kbhit())/* idle()*/;
	push_getkey();
	ESI argptr

Ca permet d'avoir des codes de touches compatibles entre 89/92 sans avoir a tester inutilement sur laquelle des deux le prog tourne (uniquement #define USE_TI89)