Editeur Hexa - Page 3

Que la force soi avec toi

macintoc : en fait toi tu t'y prend comme un goret : un seul appel flib contenant 64 drawstr (un pour chaque octet), dans ce cas la c sur ca va etre rapide !
(mais bon tu fais comment quand ya moins de 64 octets a afficher dans ta page ? )

moi je fais une boucle for avec getbyte et 2 drawstr (1 pour hex et un pour char), que je fais executer 8 fois (8 octects par ligne), puis je reexecute ma boucle autant de fois qu'il y a de lignes entieres a afficher
pour la ligne trounqué c une 3eme boucle qui affiche la ligne de moins de 8 octets

c plus lent mais ca ne pose aucun pb...

ceci dit je vais surement utiliser ta methode ligne par ligne...


sinon : "ya zstar"
ca me fais chaud au coeur ! sisi

Et putain de bordel de bugs à la merde de forum. C'est la troisième fois qui vire la moitié du post. Et il affiches même pas les smiley. obligé de les retrouvés de tête.
Bon, a part ça, j'espère que ça va passer cet fois.
Azerty83>
J'utilise pas 64 drawstr (c'est pas 10 ko qu'il prendrait, hexedit, c'est 50). Je n'utilise "que" 8 drawstr + 1 pour l'offset actuellement affiché (tiens, en parlant de ça, j'ai repris ta technique ). Regardes comment sont organiser les trois liste bithex, offset et bitchar. J'ai fait en sorte qu'une concaténation suffise à les assemblé (en ajoutant &" "& ente chaque liste pour marquer la séparation). Mais je vais supprimer le formatage de l'offset, elle est totalement inutile , donc le démarrage sera plus rapides. Je vais essayer aussi d'utiliser la methode de Double-R, ça ne peut pas faire de mal, et si c'est aussi efficace chez moi, ce sera le bonheur assuré (c'est où que j'ai entendu ça ?).
Pour Zstar, bah... C'est normale, il est trop bien ce jeu. Et puis fallait bien prouvé à Kevin qu'il se trompait
Double-R>" Que la force soi avec toi"
Je préfères utiliser le courant, plutôt que la force
(Je pense pas que tu comprennes)

Moment de vériter : ce post va-t-il s'afficher en entier ?

[edit]Edité par MacIntoc le 10-11-2001 à 22:49:57[/edit]

Bon, ben j'ai réussi à gagner 30 s. toutes les 4 min en déplaçant 2 instruction !
Mais, j'arrive pas à utiliser ta technique Double-R. En divisant la grosse boucles en petit sous-programmes, ça met 2 fois plus de temps.
Faudrait que tu m'envois la dernière version de txt-rider.

c ptet que tu defini tes sspros par des define au debut de ton prog (comme moi quoi...) et la c normal car il les tokenise a chaque 1er appel (comme moi quoi...) et c ptet de là que vient la perte de temps

enfin moi je pense que ta technique est une technique de goret pas du tout flexible...
quand tu decale ta page de une ligne, tu raffiche tout ?
et quand ta pahge n'est pas entierement remplie, tu fais comment ? tu perdre 'hachement de temps ?

le dernier txtrider basic, utilise des sous prog externe et compiler par la TI.
c'est clair que si tu met tous dans un m^me fichier tu ne va pas y arriver.

essayer de fait des sous prog externe a ton prog et lancer les tous une fois.
apres teste ton prog, et admire, magie...sa vite einh....

mais moi g horreur des progs en 2000 fichiers, je fais toujours tout tenir sur le meme (d'ou mkpak), enfin moi, je perd une second au lancement du prog, c pas enorme (sur les 24 qu'il met a tout afficher)
mais parcontre si j'arrive a faire aboutire mkpak, là vive les progs en 3000 fichiers reunis en 1 seul !!!

t'embete pas, flib a une certaine fonction qui regroupe tous tes fichier,
alors mes tes sous prog en esterne tu vera sa tourne plus vite.

tsss ca fait 2 fichiers (1 de trop) !

Je fait en sorte que ma page soit entièrement remplis, sinon j'ai une erreur de dimension.
En gros, j'utilise deux type de scroll. Un définis par ligne2 qui déplace le curseur, et ligne qui change les lignes affiché.D'accord, 8 drawstr, c'est pas subtil comme programmation, mais contrairement à ce que tu pourrais croires, c'est trés flèxible, puisqu'il suffit de déplacer la 1e lignes pour que le reste suives, et puis j'utilise des dizaine de variables différentes pour faire en sorte que la traductions 92+ à 89 pose le moins de problème possibles.

Et c'est place qui détermine la position horizontale. De ce fait, (ligne2+ligne-2)*8+place nous donne l'octet selectionner.

Je n'utilise pas define. C'est beaucoup trop lent et gros. Dans le même style, ton mkpak est aussi rapide (voir + puisqu'il n'y a pas de tokenisation) et permet de compressez les fichiers, donc de gagner de la place. j'ai plutôt essayé en créant directement les progs avec l'éditeur. Aprés compilation, ça prend 2 fois plus de temp. Mais je pense que c'est l'ouverture des sous-programmes qui plombe tous.

En ce qui concerne l'affichage, c'est dés qu'on appuit sur une touche, je raffiches tous (gray oblige). Pour la selection multiple, je vais utiliser le n&b. Ca m'arrange pas qu'il raffiche tous à chaque fois, dans ce cas là.

Sinon, pour ton varedit, J'ai remarquer que seul ta dernière lignes changait. Ce que tu peux faire pour scroller sur tous l'écran, c'est de sauvegarder dans une image les 7 dernières ligne et de les ré-afficher un peu plus haut puis d'afficher la dernière ligne.
Je tiens à remercier Anthop pour cet technique

Double-R>
Diviser les prog en sous-prog, c'est exactement ce que j'ai fait (j'ai diviser la grande boucle en 16 fichier), et une fois compiler, il mettent deux fois plus de temp !
Comprend pas

moi je ne pense pas que la division en ssprogs accelere le prog, mais c le rend moins gros.
a la limite c utile pour remplacer une boucle for fixe (toujours le meme nd d'iterations)

au lieu de

for x,1,5
..
instructions
..
endfor

fu fais

define inst()=prgm:..:instructions:..:endprgm
inst()
inst()
inst()
inst()
inst()

C'est ce que j'utilise pour l'affichage.
Je met 8 drawstr aulieu d'un seul dans une boucle for .
C'est qui le bourrin, alors ?

essaye ça:
lance tous tes sous prog externe 1 fois, archive les.
demarre ton prog principale

la si ça accelere pas,c'est ton systeme d'affichage qui met
trop de temps.

C'est pas à l'affichage que sa rame, c'est au moment de la construction du fichier.
En attendant, voici une nouvelle version.
J'ai implémenter une partie de la selection muktiple :
on ne peut selectionner que à doite ou à gauche et seulement sur la page afficher, sinon, ça plante. J'ai aussi corriger quelques bugs stupides.
http://aymericdelbreil.free.fr/hexedit.9xp
Fichier/Enregistrer sous... pour le télécharger

Voilà, j'espère que ça marches.

[edit]Edité par MacIntoc le 11-11-2001 à 19:47:44[/edit]

S'il était écrit en C ou assembleur, il ne ramerait pas du tout.

tthedit de la TIGCC Tools Suite est un éditeur hexadécimal en C _nostub.

Mais quand ça plante, c'est fatal
Et je pense faire l'ouverture du fichier en C, je pense pas avoir le choix
Ou en ASM, je sais pas encore.

bon ben a moi aussi: Varedit v0.3b (clic droit puis enrigestrer sous..)
grosse amelioration de la vitesse : 9 sec pour la page !!!
en fait g utilisé la methode semi goret entre ton prog et le mien...



[edit]Edité par azerty83 le 12-11-2001 à 21:08:54[/edit]

Bah... moi aussi, j'ai améliorer l'interface de démarrage
Il y a maintenant deux fichier, le prog et l'image d'arrière plan (Azerrty83 vas me tuer). J'ai aussi corriger un petit bug. Sinon, rien. Mais je passerai probablement en n&b dans la prochaine version, je pense avoir trouver un truc pour accélérer l'affichage.

En attendant, Azery83, je sais toujours pas ou télécharger les progs pour récupérer la chaine hexa qui ouvre le menu char.

J'ai oublier le lien
http://aymericdelbreil.free.fr/Hexedit.exe
[edit]Edité par MacIntoc le 13-11-2001 à 15:39:48[/edit]

Voilà la version en n&b
http://aymericdelbreil.free.fr/Hexedit.zip

bon la chaine exec (faut tout faiore soi meme ici )
exec "207800c820680338487a000c3f3fffe4e905c8f4e7507100000e000024000000102de710000"

en rouge c le scancode de la touche a presser (ici 2nd+[-])
attention apres appel du varlink, il y a restauration de l'ecran home ! (sauve !)
pour le reste, je verrais plus tard !

edit : bon et là c ok ?
[edit]Edité par azerty83 le 15-11-2001 à 13:03:59[/edit]

Elle a l'air de pas être bonne ta commande exec (après le premier c8, il doit manquer un caractère je crois)

Je t'en demandait pas tant...
Surtous pour quelquechoses de faux
Donnes moi plutot les lien vers les progs à télécharger et laisses les experts te montrer la voie

Tiens, Extended, est-ce que tu pourrais faire une comparaison rapide entre les hexedits basic (celui d'Azerty83 et le miens) avec celui que tu utilises. Ca permétrait de nous faire une idée une idée ce qui restes à améliorer.

je ne sais plus qui sous-entendait que qd le C plantait, ct fatal...
Qd le BASIC se planet, c'est aussi fatal...
J'ai déjà réussi à avoir une barre noire en programmant en TI-BASIC? et sans Flib !!!!!

(En faisant des magouilles avec switch et le double fenétrage... je me souviens que je voulais utiliser l'éditeur de txt de la TI en BASIC...)

arf !!! c pas une erreur de programme c une erreur de la rom

C'est des bug ponctuelles :
essayes de recevoir une variable dans une boucle try, il y a des chances pour que ça plantes. Mais ça, c'est indépendant de notre volonté, et ont peut rien y faire.

Si on utilise les chaînes Exec, il y a également risque de plantage. Même encore plus de risque si on ne sait même pas ce qu'on exécute. Et Flib est également en C. Et personnellement, tthedit n'a jamais planté chez moi.

Certes, mais y a pas beacoup de prog basic qui utilises exec, et FLib est fait par quelqu'un qui sait programmer. Quand on sait pas programmer en C, il faut ré-apprendre tous, et quand on arrive à compiler un programme, on s'apperçoit qu'il fait planter la calc.

exec "
2078 00c8 2068 0338
487a 000c 3f3c fff
e490 5c8f 4e75 0710
000 0000 0000 0000
102d 4e71 0000"

bon cette fois je crois que c'est bon...