Getkey() vs rowread() - Page 1

J'ai essayer cette petite macro:
#define GetKey() (kbhit() ? ngetchx() : 0) et c'est vraiment très rapide et surtout plus simle que rowread().
Ca vaut qd même le coup d'utiliser rowread() ?

pour un jeu oui, ta méthode est trop lente

C'est lent, en effet.
Pourquoi ne pas utiliser kbhit directement ? D'après la doc de TIGCC, kbhit retourne la même chose que ngetchx.
"kbhit checks to see if a keystroke is currently available. Any available keystrokes can be retrieved with ngetchx. If a keystroke is available, kbhit returns a nonzero integer (in fact, it returns the exactly same value as ngetchx); if not, it returns 0. Note that kbhit does not pick a keystroke from the keyboard queue. So, kbhit will continue to return non-zero value until "keypress" flag is reset by calling ngetchx, GKeyFlush or GKeyIn.

Note: kbhit function is slow, because it also handles receiving eventual bytes from the link port (used mainly internally in TIOS when the calculator is in the Home screen). See kbd_queue for much faster way to check the keyboard state.
"
Dans ce cas-là, GetKey doit être
#define GetKey() kbhit()
ou tu remplaces carrément GetKey par kbhit...

Il y a aussi les fonctions/extensions de langage:
(kbd.h)
BEGIN_KEYTEST
END_KEYTEST
_keytest
_keytest_optimized
(plus simple que _rowread, mais un peu moins rapide).

(compat.h)
RR_xxx.

Ok ! Merci bien. :-)

janjan> tout dépend du type de jeu

sinon, pour un jeu qui a besoin de vitesse, _rowread est indispensable (en désactivant l'AUTO_INT_1 (et 5), ou en les redirigeant vers rien)...

Raphaël : tu peux faire appel aux macros de lecture prédéfinies de GraphX. Même si ton programme n'utilise pas GraphX !

Par exemple, pour tester si la touche F5 est pressée, on fait if (GX_F5pressed()) {// code} !
En plus, toutes les macros sont compatibles entre les deux calculatrices, que tu compiles pour V200 ou pour TI89 ! exemple : la "fonction" GX_ESCAPEpressed teste bien la touche [ESC] que ce soit sur TI89, 92+, V200.

XDanger a écrit :
C'est lent, en effet. Pourquoi ne pas utiliser kbhit directement ? D'après la doc de TIGCC, kbhit retourne la même chose que ngetchx.

À cause de ça:

Note that kbhit does not pick a keystroke from the keyboard queue. So, kbhit will continue to return non-zero value until "keypress" flag is reset by calling ngetchx, GKeyFlush or GKeyIn.

Thibaut a écrit :
Raphaël : tu peux faire appel aux macros de lecture prédéfinies de GraphX. Même si ton programme n'utilise pas GraphX !

Par exemple, pour tester si la touche F5 est pressée, on fait if (GX_F5pressed()) {// code} !
En plus, toutes les macros sont compatibles entre les deux calculatrices, que tu compiles pour V200 ou pour TI89 ! exemple : la "fonction" GX_ESCAPEpressed teste bien la touche [ESC] que ce soit sur TI89, 92+, V200.

Ces macros sont totalement inutiles, vu qu'il y a la même chose intégrée dans TIGCCLIB!
if (_keytest(RR_F5)) {/* code */}
if (_keytest(RR_ESC)) {/* code */}
...

Kevin :

1) mes macros sont un peu plus rapides que les votres (à moins que vous ayez optimisé votre _rowread dans la dernière version)
2) je peux dire que ce sont les votres qui sont inutiles puisque les miennes existent déjà.

T'as

Thibaut
a écrit : 2) je peux dire que ce sont les votres qui sont inutiles puisque les miennes existent déjà.

Les nôtres existaient avant.

De toute façon le _rowread de TIGCC n'est plus utilisable dans la dernière bêta de GraphX, à cause du fonctionnement événementiel "multitâche".

Donc mes macros sont nécéssaires dorénavant

squale92 a écrit :
janjan> tout dépend du type de jeu
sinon, pour un jeu qui a besoin de vitesse, _rowread est indispensable (en désactivant l'AUTO_INT_1 (et 5), ou en les redirigeant vers rien)...

Sauf si on utilise Xlib pour les détournements, quand on l'initialise (XOn()), elle détourne ces int, ect, actives les grays, vérifie la RAM ect, bref, on a moins de trucs à faire, et c pas plus mal (et honnetement, ça n'enlève pas de "liberté" au programmeur , car de tt façon il FAUT le faire, et en plus c pas du tout dur à faire avec les fonctions TIGCC_LIB).

>> si on utilise Xlib pour les détournements, quand on l'initialise (XOn()), elle détourne ces int, ect, actives les grays
Petite précision : GraphX aussi.

Et avec GraphX on peut tester plein de touches (mes fameuses macros) alors qu'avec Xlib on est limité au joypad je crois

avec Xlib, on est limité au jopad, mais on peut tjs utiliser _rowread (mais, c'est plus lent que le joypad).

jachiechan> ou alors, tu réécris TA propre fonction de JoyPad, qui correspond aux touches que TU veux !
(je ne l'ai pas encore fait pour KII... mais après avoir commencé à étudier cette idée pour autre chose, je me demande si je vais pas l'adapter aussi pour KII...)

_rowread plus lent que le JoyPad ?
pas forcément...
(du moins, dans la dernière source de Xlib que j'ai maté sur le JoyPad, celui-ci était implémenté avec _rowread => il faut en plus le temps d'appeller la fonctions, plus le temps de tester des touches dont tu n'as peut-petre pas besoin... (d'ou l'idée de Joypad perso ))

while (_rowread (0)){}
while (!_rowread (0)) {}

Ca fait quoi _rowread(0)

ça teste pour TOUT le clavier

squale92 a écrit :
jachiechan> ou alors, tu réécris TA propre fonction de JoyPad, qui correspond aux touches que TU veux ! (je ne l'ai pas encore fait pour KII... mais après avoir commencé à étudier cette idée pour autre chose, je me demande si je vais pas l'adapter aussi pour KII...)

Pas con, je n'y avais même pas pensé. Vive l'open source !

_rowread plus lent que le JoyPad ?
pas forcément...
(du moins, dans la dernière source de Xlib que j'ai maté sur le JoyPad, celui-ci était implémenté avec _rowread => il faut en plus le temps d'appeller la fonctions, plus le temps de tester des touches dont tu n'as peut-petre pas besoin... (d'ou l'idée de Joypad perso ))

Il me semble que même dans la version que j'ai (1.05), le Joypad utilise _rowread.
Mais j'ai fait des benchs et il s'est avéré qu'avec le joypad c'était plus rapide qu'avec _rowread (enfin, j'ai fait le bench sur vti, donc c'est pas sûr). Ça vient peut-être du fait que dans le joypad, tu teste un membre d'une structure, au lieu de lire un port (enfin j'en sais rien, de toute façon joypad à besoin de lire le port aussi pour mettre à jour les membres de sa structure...)

jackiechan >> avec Xlib, on est limité au jopad, mais on peut tjs utiliser _rowread (mais, c'est plus lent que le joypad).

Avec GraphX aussi ! simplement, il faut utiliser GX_rowread plutôt que _rowread. Mais ça fonctionne EXACTEMENT pareil (en un peu plus rapide ).

Pas con

Merci

dans le JoyPad, TiMad fait ce que beaucoup ne pensent pas à faire en utilisant _rowread : pour les touches qui sont sur une même ligne de la matrice clavier, il est possible de toute les tester en faisant un seul appel à _rowread, en stockant le résultat ds une var, et de faire le & sur cette var ensuite.
=> mais tu peux aussi le faire dans ton propre programme !

dans le JoyPad, puisque tu utilises _rowread (le Joypad est basé dessus), tu lis aussi les ports
et l'inconvénient de Joypad, c que ça teste des touches dont tu peux ne rien avoir à foutre (d'où l'intéret d'écrire un Joypad perso pour chaque projet )

>> TiMad fait ce que beaucoup ne pensent pas à faire en utilisant _rowread
J'y ai pensé pour GraphX

Raphaël : si tu ne veux pas te prendre la tête, emploie les macros de GX

--------------------------------------------------
Bon allez j'arrête ma pub

Thibaut> je ne pensais à personne en particulier !
N'yant pas vu le source de GraphX, je n'allais pas parler de toi, d'ailleurs ! je parlais juste de Timad car nous parliohs du JoyPad de Xlib, dont j'ai vu les sources (encore qu'elles ont peut-être été modifiées depuis)



Mais je parlais de par ma propre expérience (premièrement), mais aussi par des
sources qui me sont passées entre les mains.


Sinon, GraphX est Open-Source ?

squale92 a écrit :
dans le JoyPad, TiMad fait ce que beaucoup ne pensent pas à faire en utilisant _rowread : pour les touches qui sont sur une même ligne de la matrice clavier, il est possible de toute les tester en faisant un seul appel à _rowread, en stockant le résultat ds une var, et de faire le & sur cette var ensuite. => mais tu peux aussi le faire dans ton propre programme !

En effet.
Cf. aussi http://tigcc.ticalc.org/doc/kbd.html#_keytest_optimized.

> Sinon, GraphX est Open-Source ?
A ma connaissance, non. Ou du moins, elle ne l'est pas encore (?).

Kevin> arf, oué, j'y pense jamais à ça
faudrait un jour que je teste...

XDanger> OK. c ce que je pensais, mais j'avais la flemme de chercher

Je ne la met pas open source car ça ne vaut pas le coup : si un débutant veut apprendre ma manière d'afficher les sprites, autant qu'il désassemble, mes sources n'ont aucun commentaire.

les gens qui respectent les codeurs et leur choix de faire du closed-source ne désassemblent pas.
perso, je n'ai pas l'habitude de désassembler de sprog spr voir comment le codeur fait. si la source est fournie, je la regarde, sinon, si je connais le codeur, je la lui demande. s'il refuse, je respecte son refus, et ne désassemble pas.

Mmmhh, si quelqu'un me demande la source d'une fonction pour apprendre à coder, je ne la lui refuserai pas !

On va dire que GraphX est en semi-open-source

OK.

et si ce n'est pas pour apprendre à coder ?
(autrement dit, si ce n'est pas un débutant, mais quelqu'un qui a déjà codé pas mal)



je précise que JE ne suis pas interessé par les sources de GX, et que personne ne me les a demandé, que je n'ai pas envie de les filer à qui que ce soit ou autre.
Je me renseigne juste

Si ce n'est pas pour apprendre ma technique d'affichage, je refuserai, car je ne vois alors que deux objectifs de sa part :
- faire un copier-coller de ma routine et dire "j'ai fait moi-même",
- vouloir optimiser ma routine pour faire avancer GX. Manque de bol je sais déjà comment optimiser mais je ne le fait pas car GX perdrait l'avantage de la taille.