Editeur Hexa - Page 2

Bon, je l'ai envoyé. Vous devriez le recevoir.
Azerty83> cherches pas, c'est mort
Cool, y a des nouveaux smiley

Moi, je veux bien aussi ola.e-ml@wanadoo.fr

mwarf les grays... ^^ (enleve les, ca ralentit plus que ca ajoute de la lisibilité)

bon sinon :
g du le tester sur 89 car quand je charge une rom de 92+ ce VTI de ***** (à toi de trouver le mot qui convient) me fout une 'Access violation at address 0040A2D6 in module 'vti.exe'. read of address FFFFFFFF '
c nul VTI !!!

Je garde les gray, car ça permet de refaire l'image à chaque passage. Sinon, je suis obliger de faire des fillrect et plusieur autre testes pour vérifier que l'offset sélectionner est bien celui qui est afficher. Ce qui est chiant, c'est que les deux gros bloc de flib me bouffes 2,5 Ko.

Ca y est, il est sur mon tous nouveau site :
http://perso.club-internet.fr/delbreil/hexedit.9xp
Bon, en fait, il faut faire fichier et enregistrer sous... pour le télécharger. Je sais pas encore comment on fait pour forcer le téléchargement.

J'attend ta ripostes, Azerty83
[edit]Edité par MacIntoc le 05-11-2001 à 18:43:48[/edit]

Bon... voilà une nouvelle version :
[url]http://perso.club-internet.fr/delbreil/hexedit.9xp [/url]
J'espére que le lien fonctionne maintenent.
On peut maintenant modifier un octet.
Entré pour entrer dans ce mode. Esc pour le quitter sans changement. Entré quitter le mode eu sauvegardant les modifications.
Voilà, voilà...

Je viens de m'apercevoir que je suis un des seul qui donne mes sources en ligne
Au fait, je te remerci, Azerty83

bon macintoc, si tu continue, j'apprend le C, et la tu feras moins le fiers...

bon sinon ta nouvelle version, j peux rien dire, sur 89 c pas possible de bien tout voir.... ( VTI), sinon continu...

Souffre
Tu pourras pas profité du meilleur éditeur hexa sur TI

LOL. Un éditeur hexa en BASIC ne sera jamais le meilleur.

kevin> c pas la peine d'en rajouter, c'est deja pas facile de faire qqch de bine en basic...

mac> m'en fout !
au fait, il met combien de temps pour afficher une page entiere ? (de combien d'octets au fait ?)

Il met autant de temp qu'un programme C pour afficher les 64 octets à l'écran (bon, pas tous à fait, mais la différence est acceptables).

moi aussi
24 sec pour 10 lignes de 8 octets (80) avec offset+hexa+caractères

(un copain en avait fait un : 14 sec pour 7 lignes de 10 (70) avec :
- seulement decimal : 14 secs
- seulement hexa : 18 secs )

Euh... tu veux dire à l'ouverture où à l'affichage ?

je fais les 2 en meme temps :
je lis un octet, je l'affiche

et toi tu fais comment ? (tout s'affiche d'un coup! c bizarre !)

Pour accélérer l'affichage, j'ouvre le fichier une bonne fois pour toutes, au détriment de le vitesse d'ouverture.
Je pense que je vais faire un mode ouverture rapide et un autre affichage rapide.
[edit]Edité par MacIntoc le 08-11-2001 à 19:29:37[/edit]

et tu l'ouvre dans quoi ?
une liste ?
par contre tu utilise quoi comme methode d'affichage ?
(euh pour les gros fichier, c patine trop )

Je fait 3 liste :
une pour les offset
une pour l'affichage hexa
une pour l'affichage ASCII
Et je rassemble par groupe de huit les octets, je sauvegardes l'offset entier (qui commence par 0 ou par 8), et je passe au 8 octets suivant,... jusqu'a ce qu'il n'y ait plus d'octets.
Et chaque groupe et offset constitue un élément des 3 listes cités plus haut.
Une fois ces listes construites, je les affiches.

T'aurais pas fait une nouvelle version de varedit, par hasard ?
Paceque moi, je suis un peu bloquer avec le selection multiple et l'insertion (enfin, la récupération de ce que l'utilisateur veut insérer).

Pour accelerer, faut faire une multitude de sous prog ayant chacun peut de ligne,
c'est ce que j'ai fait pour mon prog Txtrider_basic, au debut mon prog
m'était une minute pour afficher une page !!
car le traitement était trop lourd et inutile, j'ai diviser les tache pour aller plus vite,
et j'utilise des listes qui se remplisse au fur et a mesure que le texte descent.
je pense qu'on peut accelere ton prog,
car que le fichier soit grand ou petit ton prog ira a la même vitesse .

C'est à dire ?
Si j'ai bien compris, c'est au moment de l'affichage que ça rame, si on calcule la ligne au moment de l'afficher.
Est-ce que tu pourrais préciser ta techniques ?
Si ça fonctionne, ce serat un grand soulagement pour le démarrage.

ton prog je l'ai pas vu pour juger, ou je peu l'avoir pour tester

C'est pas seulement au moment de l'affichage que sa ralenti,
c'est surtout le traitement des données qui est long

pour augmenter sensiblement la vitesse du prog je fait de petite boucle du style

loop
recup_liste(...) -> recupere seulement une ligne du prog
traitement_liste(...) -> s'occupe de transformer ta liste en donner hexa
affichage_liste(...) -> affiche betement le resultat de traitement liste
...
enloop

les sous prog eu-même on des petit code et des sous sous prog du style

affichage_liste(code_a_afficher, ligne, option)
prog
if code_a_afficher = ce_que_tu_veux
mettre a l'écran(...) -> un sous sous prog, plus il y en a plus sa va vite !!!
if ligne >= max_taille_ecran
0->ligne
...
endprog

il faut sous traiter toutes tes operations, l'explication c'est que la ti met un certain temps
a lire ton prog, donc plus tu reduit la taille des passage sur les même ligne de code, et plus tu soulage ta ti, de calcule et test inutile qui ralenti fortement ton prog!!!

quand je dit que sa accellere l'affichage,
c'est pas des blagues, le dernier txtrider_basic v1.00 final (pas encore en circulation)
met pour
la prise de donnee + le traitement + l'affichage = 1.3 secondes a s'afficher...
sa laisse reveur pour ton prog

sinon regarde la source de txtrider_basic v1.00B, sa te donnera surment des idées

>double-r: c'est que la ti met un certain temps a lire ton prog

Pas si tu l'exécutes au moins une fois avant de l'archiver! En négligeant cela, tu fais le BASIC encore plus lent qu'il ne l'est déjà!

Et pour une collection d'outils pour programmer des programmes rapides, cf. ma signature.
[edit]Edité par Kevin Kofler le 08-11-2001 à 21:51:57[/edit]

Sauf que ta collections d'outils fait planter la calc quand on sait pas l'utiliser.
double-r>1,3 seconde c'est trop. J'affiche une ligne presque instantanément. La technique que tu dis est celles utiliser par Azerty83 (en partie). Et puis faut aussi calculer la chaine ASCII (caractère) et l'offset. Et ça complique les choses pour la selection multiple. Je pense plutot que je vais faire un prog C pour l'ouverture, mais bon, ça m'étonnerai que j'y arrive. Ou alors je calculerai les 8 première ligenes et je calcule le reste pendant le temps ou l'utilisateur ne fait rien.

Sinon, t'en que j'y pense, quelqu'un connaitrai t-il la chaine hexa qui permet d'ouvrir le menu char (2nd+ "+") ?

c quoi ta tech pou rafficher une ligne hper rapidement ?

sinon pour le menu char : regarde les sources de moveleft()
(c un prog asm (a utiliser dans les kbdprgm en plus de sendstr qui envoi une string dans l'ecran home) qui deplace le curs de 1 cran vers la gauche
en fait il simule l'appui sur la touche [<-]
il te suffit donc de remplacer le scancode de [<-] par celui de [2nd]+[+] (ya pas de pb c sur 16bits dans la souce) et tu recompile (_strout comme param avec as92 ou tu le transforme en exec avec makeexec) ...)

C'est pas une ligne qui met 1.3 sec
c'est une page entiere...
compte 0..1... c'est bon la page formater est afficher..

>Kevin
je c'est qu'il faut lancer un prog une fois, pour que la ti l'execute plus vite.
mais la ti affiche plus vite avec des sous prog, car dans une boucle ou il y a plusieur condition, si tu met a la place dans une condition qui ne sera pas utiliser par exemple affich(...), la boucle passera a la condition suivante sans lire ce qui a dans affich() et qui
prend 2 ko...
Pourqoui faire lire des prog entier a la ti si on peut luiç faire lire des petit code rapide?

>"1.3 s pour une page"
Effectivement, le gain de vitesse est trés impressionant !
Mais ça risque de prendre pas mal de place. Je suis pratiquement déjas à 10 Ko, si on rajoute à chaque fois 30 octets, à chaque petit sous-programmes, ça ira péché dans les 20 ou 25 Ko !!
Mais c'est surtout pour la selection multiple, que t'as technique m'inquiètes. Je me prend pas mal la tête avec le fichier déjas pré-calculer, alors si il faut calculer à chaque fois la ligne suivante, je pense pas que je saurais m'y retrouver. Mais je vais essayer de l'utiliser au démarrage, pendant le pré-calcul. C'est que je peux le télécharger ?

>Azerty83 : " c quoi ta tech pou rafficher une ligne hper rapidement ? "
Si c'est à moi que tu pose la question, j'utilise simplement un "drawstr:" pour chaque lignes à afficher :
drawstr: 2, 10*ligne2+34,"&offset[ligne]&" "&bithex[ligne]&" "&bitchar[ligne]
...
ligne : c'est le numèro de la chaine afficher à l'écran (compris entre 1 et 8)
C'est lourd, mais c'est ce que j'ai trouver de + rapide.

Ca m'a l'air compliquer ton histoire pour le menu char, mais je vais essayer. Et c'est où qu'on peut télécharger tous ça ?

Kevin> Si c'est possible qu'un programme basic soit plus puissant que le C ou l'ASM. Par exemple Zstar
[edit]Edité par MacIntoc le 09-11-2001 à 22:51:50[/edit]

>MacIntoc
au contraire sa diminu la taille de ton prog si tu t'arrange a utilise plusieur fois
des petite fonction puissante

si vous saviez tous les teste que mon prog fait...
autant faire des puissante fonction utilisable plusieur fois que plusieur petite fonction.

Ca y est je l'ai trouver, suffisait de regarder dans les news officieuses. J'analyserai ça plus tard, je part pour l'armèe, demain (je m'engage pour l'Afghanistant)
J'ai télécharger WinTrans9x en français, tant que j'y était