WLib : Topic de dev

8 load les sprites à partir du slot 0, donc si tu fais {1,1} tu load un sprite venant de Str1. Pour l'afficher tu utilises donc le slot 0.

et on a autant de slots que l'ont veut ? Si je veux 43 sprites loadés, ça marche ?

Y'a 66 slots, mais il se peut que ça change.

incroyable!!!!
je savais que tu pouvais le faire, c'est vraiment incredible!!!!!!
Es ce que je peux recopier les progs de w-lib (j'ai pas de cable)??

Bien sûr avec de la patience dès qu'il aura donné les programmes. Ce sont des programmes asm sans shell sur ti83 donc forcément affichés hexadécimaux. Tu peux donc les ouvrir dans un éditeur de TI-Basic et lire le contenu des 83p.

Apparemment ça marche très bien partout, donc la dernière version est à télécharger ici : http://mattias.refeyton.fr/espace-ti/Wlib/Wlib.zip

Cette fois-ci, j'ai inclus une beeeeylle description des commandes et arguments, pour vous rendre la vie plus facile

Alors effectivement la version 83p est en hexa, donc ouvrable avec http://tiforge.info/ti_editor par exemple, mais bon, elle fait déjà presque 1000 octets, donc bonne chance pour tout recopier sans la moindre faute - car une seule faute causera un RAM clear quasi-certain.

Bonjour
je n'ai pas du comprendre ce qu'il fallait faire
j'ai envoyé à la ti83 les 8xp
et voila ce que ça m'affiche ...


Bien à vous

sinon pour info sur la page d'accueil
Not Found

The requested URL /espace-ti/WLib/WLib.zip was not found on this server.

c pas le 8xp qu'il fallait envoyer, c'etait les 83p... si c'est une 83 normale

rpgcreator a écrit:c pas le 8xp qu'il fallait envoyer, c'etait les 83p... si c'est une 83 normale

comme j'ai vu TI-73 (que je connaissais même pas de nom...) j'ai du lire TI76 et fait l'amalgame avec TI82stat...

OK c'est bon . j'avais oublié aussi le A.8xp qui n'était pas dans le même dossier.
ça marche bien bravo !

désolé pour le dérangement

oh une precision:
la version 83p fait exactement 1835 octets, donc pour ceux qui recopient et que la taille du programme ne fait pas EXACTEMENT le nombre que je viens d'indiquer, je VOUS DECONSEILLE FORTEMENT DE L'UTILISER, sauf si vous voulez mettre votre calculatrice en danger de mort mémoriale certaine

bonne remarque

Plop,

Après une grosse période passée à faire autre chose et une autre sans PC ni téléphone (tout m'a pété dans les mains), j'ai enfin continué Wlib

Quoi de neuf :

• openPrgm(n° Str) : ouvre un programme dont le nom est dans la Str pour lecture/écriture et le place en tant que programme courant. Initialise le curseur virtuel au début du programme. Renvoie 0 dans W en cas de succès, sinon 1.
  
• readToken(n° Str) : lit le token pointé par le curseur virtuel dans le fichier courant (il peut être 1 ou 2 octets !), le stocke dans la Str et avance le curseur virtuel d'un ou deux octets selon le token lu. J'ai prévu de mettre 0 dans W si la lecture a échouée (en gros si on a dépassé la fin du fichier) mais c'est pas encore fait.
  

Ce que j'ai prévu :

• readLine(n° Str) : stocke toute une ligne de caractères lus (jusqu'au prochain : ou la fin du programme) dans la Str.
  
• setCursor(position) : place le curseur à la position donnée dans le fichier courant (0 c'est le début). Renvoie 1 dans W si erreur (curseur parti trop loin, en-dehors du fichier), sinon 0.
  
• writeToken(n° Str) : écrase le token pointé par le curseur virtuel avec le premier token dans la Str. Écrire un token deux-octets sur un token un-octet rajoutera un octet à la taille totale du programme ; écrire un token un-octet sur un token deux-octets en enlèvera un.
  
• insertToken(n° Str) : insère le premier token de la Str à l'emplacement du curseur virtuel. Avance ce dernier derrière le token récemment inséré.
  
• insertLine(n° Str) : insère une ligne entière (jusqu'au prochain : contenu dans la Str ou jusqu'à sa fin) à l'emplacement du curseur virtuel, et déplace ce dernier à la fin de la ligne récemment insérée.
  
• deleteToken : supprime le token pointé par le curseur virtuel. Le curseur ne bouge pas, et pointera donc le token qui suivait celui qui aura été récemment supprimé.
  
• deleteLine : supprime une ligne entière (jusqu'au prochain : ou la fin du programme) à partir de l'emplacement pointé par le curseur virtuel. Tout le contenu du fichier sera déplacé en conséquences.
  

Voilà, je vais implémenter les fonctions de tokens d'abord puis celles de lignes ensuite, avec peut-être une bêta entre les deux (si vous êtes sages  ).

Super

Ca va être intéressant ça


Quelques petites remarques:
.Essayes de ne pas trop changer la valeur de l'erreur (mettre par ex toujours 1 pour erreur et 0 pour correct, sinon on va plus s'y retrouver ("Renvoie 0 dans W en cas de succès, sinon 1" / "J'ai prévu de mettre 0 dans W si la lecture a échouée")
.Tu gère comment les tokens de retour à la ligne?
Par exemple: si on veut rentrer un token de retour à la ligne?
Si on lit un token de retour à la ligne?
Lorsqu'on lit une ligne est-il au début (si on était au début de la ligne)? A la fin? Pas du tout? Du coup le curseur se place après le retour à la ligne suivant?

Ah oups je voulais écire 1 dans W si ça échoue, sinon 0. Je me suis emmêlé les pinceaux (voilà ce que c'est que d'écrire à 3h du mat'). De manière générale, W est nul si l'opération a réussi.

Pour les tokens de retour à la ligne, ben c'est juste un token, donc c'est géré comme un token normal. La seule exception est que ça délimite les lignes, donc quand on lira une ligne le token de fin de ligne ne sera pas renvoyé, par contre le curseur pointera le token après le token de fin de ligne.

Pour lire une ligne, il suffit juste que le curseur soit quelque part dans la ligne, et la fonction lira la ligne à partir du curseur jusqu'au prochain :.

Mh, maintenant que j'y pense ça serait plus simple d'écrire 0 dans W si on échoue, comme ça ça permet différentes valeurs de retours. Je vais plutôt faire ça.

De cette manière la fonction de lecture de ligne pourra renvoyer 1 si la ligne a été terminée par un retour de ligne ou 2 si ele a été terminée par un : simple.

Ok.

Par contre je me demande ce que ça fera si on essaye d'afficher le token de retour à la ligne (dans un Disp/text ou Output par exemple)... J'essayerai de tester ça tout à l'heure.

Ah et aussi ça serait bien une méthode comme setCursor mais qui prenne en paramètre non pas une position mais un num de ligne.
Ah et aussi pour cette méthode si on a par exemple si on a un token deux-octets en tout début de prgm, et qu'on passe 1 comme position à la méthode, il se passe quoi? On se retrouve en plein milieu du token?

Non, parce que la position se compte en tokens et pas en octets. J'aurai pas dû utiliser le mot "octet" pour les fichiers.

Si t'affiches un token "retour de ligne" ($3F je crois), ben tu verras un retour de ligne c'est-à-dire une ligne blanche et un : à la ligne en-dessous.

Ok.

En fait, pas exactement

J'ai fait quelques test, résultats en images :


Donc:
Text( ignore tout simplement le token (quoique ça dépend en fait... Je pense que ça cour-circuite un peu le graph buffer, d'où le "5" qui s'est effacé est ressemble à un "!"
Disp/Pause et affichage à partir de la dernière réponse (fin de prgm ou saisie de chaine dans l'écran home):
un caractère vide est affiché et un ":" est affiché à la ligne (normal jusque là) mais l'affichage continue après le caractère vide, et non pas après le ":".
Output: là ça devient intéressant: L'affichage est correct (caractère vide + ":" à la ligne + retour à la ligne du curseur).

Après c'est toi qui gère hein je suis pas responsable de ce que tu fais avec la lib.

Sinon, j'ai implémenté writeToken pour les tokens d'un octet sur d'autres tokens d'un octet. Vu que ça marche bien, le reste devrait pas être trop compliqué

Oui c'est sur, c'était par curiosité que j'ai fait ça

J'ai testé un autre truc assez cool: ac le débugeur de wabbitemu, j'ai bidouillé un peu la VAT: après avoir créé un programme, j'ai changé l'adresse que pointait la VAT liée à str0, pour la faire pointer vers le prgm.
Comme je m'y attendais, str0 contenait ensuite une chaine qui correspondait au contenu du prgm! Encore mieux: modifier la chaine revenait à modifier le prgm, et inversement...
Ca peut être sympa aussi de pouvoir récupérer comme ça le contenu d'un prgm dans une chaine: même pas d'utilisation de mémoire en plus, puisque la chaine se comporte comme une référence en C++. Par contre du coup il faut penser à libérer la chaine après...

Et ça c'est vachement plus hard. Donc non.

Je ne proposais pas vraiment à l'intégrer à Wlib, parce que là il faut vraiment penser à libérer la chaine (sinon adieu le prgm). Ca pose des pb en ti basic: si on quitte avec [ON], on risque de faire des dégâts au prgm chargé ainsi.
J'ai juste présenté la technique parce que c'est simple à faire en asm, et que ça peut être intéressant.

Effectivement c'est une bonne expérience, mais c'est complètement inutilisable dans Wlib.

J'ai téléchargé Wlib, je teste dès la semaine prochaine, une fois le concours ti planet passé

Par contre le code d'exemple... non !   
Pas optimisé du tout ça   

Bien sûr que non <_< déjà c'est un exemple pour apprendre à utiliser la lib, pas à optimiser du Basic, pis t'façon j'en ai jamais fait.

Ahah t'inquiète je rigolais (même si appeler WLib même quand il n'y a pas de déplacement n'est pas forcément une bonne idée d'exemple ).

Ben écoute j'accepte toute contribution.