v3 - Page 10

RedSilk > En voulant décompiler Vertel tu montre bien que tu ne sais pas comment elle marche. Et si tu pense que oui, alors essaye de faire plus performant, après tout... (pas la peine de repomper FLib, tu arriverais difficilement à la moitié de la vitesse de Vertel)

Bon enfin bref tu fais comme tu veux, mais faut quand même savoir que 1° apparement t'es pas très au courant vu le nombre de conneries que tu me sors, 2° bah t'es le deuxième à qui je refuse d'envoyer le source de Vertel, tous les autres l'ont eu sur simple mini message sans aucun problème, 3° si tu préfere FLib je vois pas pkoi tu me gonfle dans ce topic...


Bon maintenant plus interessant, andoh_wilfried :

sequentiel ? Normalement vertel comprend que si l'on utilise dans un appel un nombre et une liste , le nombre doit être utilisé autant de fois que nécesaire.

Oui mais non
Le fait de mettre le même nombre plusieurs fois dans la liste oblige Vertel à "mettre à jour" le nombre à chaque cycle. Alors qu'en temps normal, elle ne considère pas qu'il a changé entre deux cycles, donc elle ne le redéfinit pas. Or dans ce cas spécial, il a effectivement changé.

T'aurais dû penser à m'envoyer le lien pour télécharger dans ta reponse puisqu'il s'agit d'une mise-à-jour !

Y'a pas de mise à jour, tout ce que j'ai dit était censé marcher avec la version actuelle

Par contre y avec les chaine ça fout la merde. Seul l'utilisation normale fonction ie rechercher un seule chaine dans une liste de chaine avec index par defaut. Dès que j'essaie de mettre un index ça foire
-avec 2 arguments numériques le resulat est un peu aléatoire en fonction des nombre que tu met en 1er ou 2nd arg -avec 3 arg là c'est la totale.

Heu je ne pense vraiment pas que le résultat soit "aléatoire". Soit ça marche, soit ça marche pas. Dans tous les cas je ne peux rien faire sans une explication plus précise (ie : avec un exemple)

D'ailleur une question tu stockes les résultats temporaires de vertel dans quelle variable ? parceque je suppose que c'est pas dans "#@" sinon j'aurai pas eu besoin de faire un "retr" pour recuperer ces résultats !

Tu ne peux pas accéder à cette variable (c'est pas pour rien qu'elle s'appelle variable "interne" ). Elle est créée temporairement quand tu l'utilise dans Vertel, et détruite à la fin de l'appel. D'ailleurs "#©" est l'ancienne syntaxe, avec Vertel 3 tu peux gagner un octet en utilisant simplement "#".

exemple
Dans tous les cas le tag sequentiel marche pas pour le test voici 1 petit exemple :
vertel("test",{1,2,3,1,2,3},"->",{1,2},{0,0},"","retr","a")
donne {1,1}

3 choses:

1) 3e fois que tu sors que Vertel a des performances de brute alors que
ça reste du Basic.

2) Je ne t'ai pas demandé la source de vertel, alors peut-être que tu
refuses de manière préventive.

3) J'aimerais qu'il y ait des raisons plus importantes de prendre vertel.
Par exemple vertel1, je l'utilise, je suis bien obligé pour le zoom et
les masques. Le mieux serait que tu continues à mettre des fonctions
qu'on ne trouve pas ailleurs (au lieu de promouvoir une hypothétique
vitesse de malade). Par exemple, des grandes pics de plus de 240x128
avec du scrolling, ou même des graphismes en tiles, si t'as la place,
ou simplement des routines optimisées pour les pics 16x16, ou bien
un rappel de pic avec halo.

si tu fais
for i,1,beaucoup_quoique_un_peu_moins_resterait_rencore_demonstratif
vertel(ouga)
endfor
c'est sur, c'est du basic et c'est lent

\mais vertel a une syntaxe bien a elle dans le passage d'argumets (l'utilisation de listes) qui permet, dans une certaine mesure, de se passer
de boucles
a ce moment la tu peux reduire l'appel precedent a un seul appel a vertel : vertel(ouga_avec_l'utilisation_de_listes)
et la je ne vois pas ou tu vois du basic la dedans, ce n'est plus qu'un appel a un programme en C
(je sais, ca reste du basic, car dans les args de l'appel tu as encore des fonctions basic, mais l'interert de vertel est de ce passer le plus possible des structures de controle en basic, et donc de limiter l'utilisation du basic ())

et les fonctions de tiles peuvent etre realisees - a peu pres aussi rapidement que flib - par vertel sans fonction speciale, juste avec les listes.

j' ai oublié le Tag sequentiel :
-vertel("test",{1,2,3,1,2,3},"->",{1,2},{0,0},"","retr","a")
donne en fait {1}
-vertel("test",{1,2,3,1,2,3},"->",{1,2},"","retr","a")
donne en fait {1,4,7,10} comme avant

Ça restera toujours plus lent que du C pur ou, encore mieux, de l'assembleur.

et les fonctions de tiles peuvent etre realisees - a peu pres aussi rapidement que flib - par vertel sans fonction speciale, juste avec les listes.

Justement, flib est lente !!!!

Edit: KK > , toujours plus lent que le C seul, on récupère les
arguments...

flib est lente dans la fgestion des arguments et des parametres

pas forcement sur les fonctions elles-meme
sur une fonction non-elementaire comme un affichage de tiles, la lenteur de flib ne se fait pas vraiment ressentir

Oui, mais on pourrait faire une fonction qui prend en argument le nom d'un string
contenant les données sprite, et le nom de la matrice.

bah ouais, et alors ?
tu peux quasiemnt faire ca avec vertel...

Oui, mais moi je parle d'une implémentation autrement plus rapide que ce qu'on peut faire
actuellement. Un affichage instantané à l'écran, et avec scrolling éventuellement, si on met
des coordonnées de plan dans la matrice par exemple.

Pour les chaines
-vertel("test",{"1","2","3","1","2",3"},"2",0,0,0,"","retr","a")
donne en fait {1,2,3,4,5,6}

-vertel("test",{"1","2","3","1","2",3"},"2",0,0,5,"","retr","a")
donne en fait {6,7,8,9,10,11}

-vertel("test",{"1","2","3","1","2",3"},"->",{"1","2"},0,0,{0,0},"","retr","a")
donne en fait {1,1}

-vertel("test",{"1","2","3","1","2",3"},"->",{"1","2"},k,0,{0,0},"","retr","a")
donne en fait {1} k quelconque

en l'etat actuel de vertel tu peux faire un afficchage quasi instantane pour remplir l'ecran de tiles (16*16 c'est raisonnable))
par contre souvent tu as des calculs preliminaires qui peuvent prendre plusieurs disaines de secondes

mais si on fait ces calculs une fois pour toutes, tu peux faire de l'affichase quasiment instantanne

RedSilk :
1) 3e fois que tu sors que Vertel a des performances de brute alors que ça reste du Basic.

Elle a des "performances de brute" (on va dire simplement qu'elle s'en sort pas trop mal) POUR DU BASIC... J'ai absolument jamais comparé ça à autre chose que du basic, t'es totalement HS.

Par exemple, des grandes pics de plus de 240x128
avec du scrolling, ou même des graphismes en tiles, si t'as la place,
ou simplement des routines optimisées pour les pics 16x16, ou bien un rappel de pic avec halo.

Bon ça ça montre que t'as absolument rien capté au fonctionnement... Un indice : ROM_CALL.
P.S : Renseigne toi avant qu'on commence une discussion serieuse, je perd mon temps à te répondre et tu perds le tiens à raconter n'importe quoi.

Kevin Kofler
: Ça restera toujours plus lent que du C pur ou, encore mieux, de l'assembleur.

La remarque qui tue
Oui évidement... D'ailleurs dans le même genre de remarques on peut dire qu'un programme sur PC avec un proc de 2Ghz tournera plus rapidement que sur Ti avec 12Mhz

Bon tous les deux (RedSilk / Kevin). Si c'est uniquement pour dire que c'est de la merde sans
• Rien proposer d'autre (= ça sux, mais je propose rien de mieux),
• Donner un seul argument intelligent (= autre que "le C c'est plus rapide"),
Vous êtes priés de vous abstenir tant que vous pouvez encore le décider vous-même

J'évite tout de suite la remarque comme quoi j'accepterais aucune critique : non, totalement faux. Au contraire je veux des bonnes critiques qui feront avancer la lib. Mais ni l'un ni l'autre ne m'avez donné de bonne critique pour le moment, uniquement des évidences ou des rabaissage gratuits.

andoh_wilfried :
exemple
Dans tous les cas le tag sequentiel marche pas pour le test voici 1 petit exemple :
vertel("test",{1,2,3,1,2,3},"->",{1,2},{0,0},"","retr","a") donne {1,1}

Et ça devrait donner 1,4,2,5 j'imagine ? Bon alors pour le coup ça risque d'être beaucoup plus compliqué à résoudre... Le {0,0} devrait être séquenciel par rapport à la 2eme liste, mais pas la première, donc faudrait le marquer avant mais du coup ça change l'ordre des arguments... Bon vu qu'il n'est pas possible de faire de gestion séquencielle croisée (et que mes neurones commencent à faiblir avec toutes ces liaisons dans tous les sens), ça risque d'être assez compliqué. Faudra que j'y reflechisse, mais pour le moment (en semaine) j'ai pas le temps :-/

Ok A++

Si Vertel était codé en assembleur il y aurais un bon rapport vitesse et taille du code et donc offrir un large choix de fonctions. Il en devient plus intressant de directement s'attaquer à la ROM de TI en là modifiant et en intégrant ou dérivant des fonctions du TI-Basic du genre pxlon avec ça propre routine intégrée en mémoire FLASH... Pour moi c'est le top pour les programmeurs en TI-Basic mais reste que Vertel est un atout et donc il ne faut pas absolument cracher dessus. Reste le problème qu'il y a de plus en plus de programmeur en TI-Basic et qui demande de plus en plus de routines rapide et efficace.

Vertyos > Ce que je dit est pour t'aider et faire avancer la lib (Quant à Kevin, j'en sais rien... )

Par exemple, des grandes pics de plus de 240x128
avec du scrolling, ou même des graphismes en tiles, si t'as la place,
ou simplement des routines optimisées pour les pics 16x16, ou bien un rappel de pic avec halo.

C'est ça qui devrait t'aider. Tu dis que j'ai donc rien compris à......... Abrégeons.
J'aimerais beaucoup pouvoir faire:

vertel4("bpic",0,0,12,40,pic)

Pour demander de mettre à partir de 0,0 sur l'écran actuel l'image "pic" (à partir de 12,40 dans la pic)
avec donc un clipping.

Genre mon image fait du 240x256 et est enregistrée en PIC par un hack (d'autres fonctions à implémenter...)
et j'en rappelle la moitié basse.

Ou vertel4("halo",0,0,truc) pour rappeler une pic truc avec halo d'un pix avec calcul de masque temps réel. (Si PpHd passe par là...)

geogeo
: Si Vertel était codé en assembleur il y aurais un bon rapport vitesse et taille du code et donc offrir un large choix de fonctions.

Bof. Etant donné la taille de Vertel, l'aspect de son code C et les switchs utilisés, la passer en assembleur n'aurait qu'un effet plutot mineur, surtout quand on compare avec la vitesse du basic.

Il en devient plus intressant de directement s'attaquer à la ROM de TI en là modifiant et en intégrant ou dérivant des fonctions du TI-Basic du genre pxlon avec ça propre routine intégrée en mémoire FLASH...

Berk
Pedrom pourrait proposer un Ti-Basic avec des fonctions plus rapides, et là ça serait très interessant, mais modifier AMS pour ça, c'est un hack aussi dangereux que sale

RedSilk > Tu n'as toujours pas comprit ce que j'ai dit par ROM_CALL. Vertel pourrait être plus rapide si j'avais recodé les fonctions. Simplement encore plus que la vitesse je vise l'économie de place, et faire une lib pour le basic de 24ko c'est tout simplement n'importe quoi. Donc pour les pic j'utilise BitmapPut et il n'est pas question de recoder la fonction (à 1ko la fonction, je te laisse imaginer la taille de la lib...)

RedSilk>

Vertyos
:

geogeo
: Si Vertel était codé en assembleur il y aurais un bon rapport vitesse et taille du code et donc offrir un large choix de fonctions.

Bof. Etant donné la taille de Vertel, l'aspect de son code C et les switchs utilisés, la passer en assembleur n'aurait qu'un effet plutot mineur, surtout quand on compare avec la vitesse du basic.

Je ne pense pas que tu ferais des miracles niveau vitesse, puisque de toute façon, la lib est utilisée avec du BASIC, mais question taille tu pourrais gagner beaucoup je pense, en ASM.
Enfin, je sais bien que tu n'as de toute façon aucune intention de la recoder en ASM, mais je voulais juste apport mon grain de sel.

Sasume :
Je ne pense pas que tu ferais des miracles niveau vitesse, puisque de toute façon, la lib est utilisée avec du BASIC, mais question taille tu pourrais gagner beaucoup je pense, en ASM. Enfin, je sais bien que tu n'as de toute façon aucune intention de la recoder en ASM, mais je voulais juste apport mon grain de sel.

Heu... Il me semble que t'as vu le code source, et franchement non je ne pense vraiment pas qu'on puisse gagner beaucoup en codant en asm

Et en codant en hexa

la tu perdrais beaucoups en cheveux sur la tete

Autre probleme avec : je sais pas si c'est ma ti avec AMS 2.9 ou VERTELmais essayer ceci et dite moi si ça marche :
:dupstr(s,n)
:Func
:@STRING,N
:Local z,r,t
:vertel("size","s","","retr",'z")
:vertel("read","s",3,z-5,"","retr","r")
:vertel("make","t",z+(n-1)*(z-5),"","load",seq("#r",i,1,n),"","load",{0,45},"","retr","","writ","t",3,"#@")
:t
:EndFunc

Ce code est sensé dupliquer n fois la chaine s
Alors ça fonctionne pour n<15 ; au delà il se passe un truc bizarre.
J'ai utiliser tthedit ' Un editeur HEXA'. Il se trouve que il manque une repetition au delà de n=14

Alors que quelqu'un m'explique. La taille du d'un STRING ça tient sur le 2 et/ou 3 premiers octets (car j'ai utiliser 2 ) ??????????

Vertyos => Fonction 'test'
Je suppose que c'est réalisable et j'espere que tu l'ajoutera :
Pourquoi est-on obligé d'utiliser uniquement l'opérateur = pour 'test' ? Tu pourrai laisser le choix aussi de '<>'
je pense que ça peut être pratique.

:Func
:@STRING,N
:Local z,r,t
:vertel("size","s","","retr",'z")
:vertel("read","s",3,z-5,"","retr","r")
:vertel("make","t",z+(n-1)*(z-5),"","load",seq("#r",i,1,n),"","load",{0,45},"","retr","","writ","t",3,"#@")
:t :EndFunc

Ouïe... Quand tu load une string ça la charge en format TiOS, c'est à dire 0,string,0,45. Tu ne peux pas l'écrire dans une variable avec write, qui n'accepte que des entiers

J'ai regarde les exemple et en particulier v3_ginfo.
Au debut tu recherche tous les fichier de la calculette et tu renvoie la place de tous ceux qui ont l'extension VTG. Ensuite tu fais une boucle pour creer une list contenant seulement les fichiers qui ont l'extension VTG.
Est ce qu'il y aurait moyen de faire ca plus rapidement.

Pour mon prog, ca ressemble : j'ai une matrice avec des nombres compris entre 1 et 150 et une list de 150 elements et je veux avoir une matrice qui dans chaque case a l'element correspondant a la list.
Exemple avec 3 element

l = {"aaa","bbb","ccc"} et m = [[2,3,1][3,3,2][1,1,3]]

Et je voudrais trouver : m2 = [["bbb","ccc","aaa"][""ccc",""ccc","bbb"]["aaa","aaa","ccc"]]

Est ce possible de le faire sans boucle (ou encore mieux avec vertel) ?

OUi vertyos, je suis d'accord mais pourquoi ça marche dans un cas et pas dans l'autre ?
Une autre question peut-on utiliser vertel dans les fonctions ?

J'ai un bug bizarre avec les TSR et PREOS qui désactive une partie des restrictions sur les fonctions ;
donc j'utilise vertel dans les fonctions, et aussi des instructions basic comme Input,Text et même le Dialog s'execute mais il provoque une erreur apès .

Reexplique le truc du load et du format TI de STR
parceque t n'est pas loader et n'est pas un STR avant que je n'ecrive dedans !

Vertyos > Ben vertel c'est déjà 3 libs différentes. Et puis recoder les fonctions aurait fait un avantage
supplémentaire par rapport à flib.