Vertel 3 - Page 1

J'ai une petite question à propos de la fonction paus, puis retr :
Lorsque je veux connaître la valeur de paus, je fais donc vertel("paus","","retr","t",1)
Puis après je vérifie la valeur de t avec des if, mais pour vérifier si la touche gauche a été appuyée, il faut faire if t=338, alors que le code touche est normalement 337, et pour droite, il faut mettre 344, alors que c'est normalement 340.
J'ai raté un truc dans la doc, ou non ?

Heu non, c'est juste que les codes renvoyés par ngetchx() sont pas les mêmes que getkey() en basic (et fais gaffe, c'est pas non plus les mêmes sur 89 / 92+)

oui, pour la différence entre 89 et 92, je savais.
Bon bas sinon je saurais pour la prochaine fois

d'ailleurs j'ai pas compris pourquoi il s avaient inversés les touches de direction en ASM et pas en basic

Oui, c'est un peu c** quand même ...

Alors là tu me déçois Vertyos
Allez, voici la routine que j'utilise dans ma librairie, elle attend en basse consommation (important, surtout que tu n'utilises pas non plus les niveaux de gris) et renvoie getkey:

typedef unsigned short ushort;
typedef unsigned char car;
ushort atTouche()
{
 car *arg;
 while(!kbhit()) idle();
 push_getkey();
 arg=top_estack;
 return (ushort)GetIntArg(arg);
}

Ce code a été écrit sous CC (comment ça vous l'auriez deviné? )

Heu... C'est nul
Nan franchement à part grossir la taille de la lib je vois pas l'interet... ngetchx() met aussi la calc en basse consomation, et ça fait un seul appel au lieu de ton gros bloc (qui en plus utilise un appel à une fonction Ti-Basic )

Non, ngetchx() n'attend pas en basse consommation (peut-être sur AMS 2.09 que je n'ai pas testé mais ça m'étonnerait beaucoup). Essaie de laisser ta calc deux jours allumé avec un vertel("paus"). Maintenant, remplace les piles et laisse deux semaines ta calc allumée avec un lib("Keywait") de ma librairie et reprends son utilisation comme si de rien n'était
Sinon quel est le désavantage de faire appel à une fonction BASIC? Tu ne vas pas me dire qu'une routine d'attente de touche est cruciale niveau vitesse hm?

J'allais éditer : en effet ça ne met pas en basse consomation, par contre ça scanne le port IO pour gerer les transferts de fichiers éventuellement (ça peut servir, cf installeur de CF par exemple). Mais bon, je laisse rarement ma calculatrice allumée avec un programme en attente
Niveau vitesse nan, puisque c'est secondaire pour une lib basic, mais comme ton code est plus gros ET plus lent, jamais j'irais remplacer ngetchx() par ça

Plus gros de 50 octets (pile, testé)... c'est pas la mort. Avec cette technique, je pouvais programmer sur TI plus d'un mois sans changer de piles. Avec flib à l'époque (et ngetchx() donc), même pas une semaine entière...
Enfin voilà quoi... c'est toi qui vois

Brunni
: Plus gros de 50 octets (pile, testé)... c'est pas la mort.

lol c'est énorme ! Si j'avais une astuce pour gagner 50 octets sur la lib, je l'utiliserais tout de suite... enfin bref...

Alors commence par programmer ta lib en ASM si tu veux vraiment gagner en taille

Ouep, je sais bien qu'il reste plus beaucoup d'autres solutions que celle-là, mais je suis vraiment pas chaud pour reprendre tout le code en asm, surtout vu mon niveau...

On peut réellement faire des miracles en ASM

cf #12

Brunni, je veux bien mettre ton code dans la version de FLib que je maintiens (vu que FL a arrêté la programmation sur TI). Je peux mettre ton code sous GPL?

Une très forte économie des piles contre 50 octets seulement, je prends tout de suite, moi. (Quant à la vitesse, je n'en à rien à battre.)

le con de service qui vient foutre sa merde rien que pour se faire remarquer et faire chier bob

Désolé, Kevin, mais je crayonne liquid (dans le fond)

Complètement....

Bof, ça me fait pas chier, au contraire si il fait de bonnes choses pour FLib, ça me motivera
(bon là ok, c'est pas vraiment une bonne chose )

Vertyos (./15)> Je ne disais pas ça pour essayer de te convaincre de passer à l'ASM.

Kevin> Bien sûr
Malheureusement ce ne sera pas utilisable de manière brute puisque FLIB utilise les niveaux de gris. Donc cette méthode n'est pas applicable si les nvg sont enclenchés. Cependant je crois savoir que tu avait fait une routine d'IDLE en niveaux de gris, alors il faudra utiliser celle-ci à la place...
Et tu n'es pas obligé de laisser code tel quel (les typedef ne servent à rien, c'est juste parce que j'avais écrit le code sous CC).

Une question pour Vertyos :
Pourquoi main/vertel("pict","image/img1", x, y , 1) ne m'affiche rien alors que (désolé pour cette comparaison) main/flib("sprite: x, y, 1, image/img1") marche très bien.
En fait j'ai l'impression que vertel n'affiche que les images du repertoire courant, serait t'il possible de changer cela ?

Heu non, c'est surtout que c'est pas "image/img1" mais "image[b][/b]img1"... (je ne sais pas si FLib corrige ça automatiquement, ça expliquerait pkoi ça marche, mais en tout cas Vertel ne le fait pas.

Je ne pense pas Vertyos, parce que main/flib n'aurait pas marché non plus. En fait bob s'est certainement trompé de caractère et utilisé / au lieu de \ en tapant à l'ordi mais pas sur sa TI.

Oui, je me suis trompé de caractère, mais le problème est toujours là !!!

Heu chez moi ça marche très bien, d'appeller "image\pic"

Chez moi, ca marche pas... Mais vertel ne fait pas la même taille que le tien, ma version est 3.00 beta 4.

J'ai fais quelques tests et c'est que avec les images de 16*16 que ca marche pas

gni ? bon je testerais tt à l'heure, là je suis sur priston tale