Viewer de Matrix|List - Page 3

C'est tellement dégoutant que je vais voir si je trouves pas un TUTO pour essayer d'appeler directement l'éditeur de MATRIX du TIOS.
Il doit être 2 fois plus speed à l'affichage que le miens.

j'avais demander à Flanker s'il ne pouvait pas nous faire ça mais , il a dit que c'était chiant à faire. C'est dommage vu que par cette méthode le code je pense ne dépasserai pas les 4ko

Je vais voir du coté des Events.h, si j'arrive à piger quelque chose

pk tu ne fais pas un cache de chaque expression plutot que de passer par le TIOS a chaque fois ? c'est ce que je fais dans uview, et j'ai aucun pb de lenteur

j'ai l'impression qu'il s'entête à tout réafficher...

Pollux -> par cache tu vex bien dire copie
Si, si je copie les expressions dans un Tableau de Handle grace à 'HS_popEStack'.
ça doit bien être aussi rapide que de faire un 'memcpy' pour sauver en mémoire.

Je n'utilise pas d'entrée dans la VAT de la TI à condition que 'HS_popEStack' le fasse à mon insu.
je vais mettre en ligne la version que je viens de modifier pour que vous voyiez comment ça se comporte.

Si ça se trouve j'en fait un petit peu trop. Comparé à la 1ère version ( très couteuses en mémoire vu que j'utilisais que des chaîne pour sauver les EXPR ) c'est normal que l'affichage soit moins rapide.

jfg ->
je n'ai surement pas pigé ce que tu essais de m'expliquer :
- si je procède comme tu as dit c'est-à-dire en affichant à chaque fois la nouvelle ligne ou colonne en fonction du fait que je scrolle dans l'une des 4 directions
je pense bien que celà va faire un paquet de cas de figures

désolé j'ai pas été clair, je voulais dire copier l'image dessinée par le tios, pas l'expression sur l'estack ^^

Voilà j'ai mis-à-jour MATVIEW. j'utilise une tableau d'ESI.

Je n'ai pas encore révisé la façon de scroller, ce qui veut dire que je réaffiche tout à chaque fois.
je modifierai ça ce soir. j'espère que ça va scroller grave après ça.

Dans l'état il est utilisable . j'ai compilé séparément pour chaque TI.

Edit Jeudi 09

j'ai pensé à un truc histoire de faire plaisir à ceux qui veulent du Pretty Print.
- une touche pour basculer l'affichage de l'élément en cours en pretty_print dans une fenêtre.
Bon y aura pas le scrolling. le code fait déjà 8Ko alors faut pas exagérer.

ça fait vraiment chier d'implémenter le scrolling .
Déjà que j'utilise :
- 3,84 Ko pour la sauvegarde de l'écran
- 3.84 Ko pour l'écran virtuel

Si j'utilise BitMapGet il va falloir encore 3,84 Ko pour sauver la partie de l'image qui reste inchangé avant de l'envoyer au bon endroit dans l'écran virtuel.
Donc je vais être obligé d'utiliser 'memmove' pour déplacer directement ce que je veux dans l'écran virtuel.

Quel gymnastique.


A part ça j'espère que le Viewer fonctionne corectement.
Si quelqu'un se trompe pour le tester, qu'il me dise si y des truc qui clochent. Surtout au sujet des touches de navigation

Déjà que j'utilise : - 3,84 Ko pour la sauvegarde de l'écran

Pourquoi ? Tu ne souhaites pas utiliser SAVE_SCREEN ?

andoh_wilfried :
Donc je vais être obligé d'utiliser 'memmove' pour déplacer directement ce que je veux dans l'écran virtuel.

Quel gymnastique.

tu découvres les joies du C

c'est ce que je viens de décidé de faire tout à l'heure au toilette ( on y trouve le temps de voir les choses en perspective ) .
A départ j'affichait le Viewer dans une fenêtre, donc je ne sauvais pas tout l'écran.

Vu que je ne m'en sert que pour évaluer l'élément édité ou pour le convertir en chaine une expression, autant profiter de l'ESTACK.

SAVE_SCREEN bouffe de la pile. HSR est une alternative intéressante, utilisée dans TI-Chess.

C'est quoi ça HSR ??

je n'utilise quasiment pas la pile dans mon code. C'est donc pas du luxe 3,84 Ko pour >Sauver l'Ecran.

Ça me dit quelque chose, HomeScreenRestore, mais je ne sais plus comment procéder pour l'effectuer.

Extrait de TI-Chess (la 4.12 est sortie, testez-la SVP - oh le vilain plug pas beau :P), tichess.c:
/*===========================================================================*/
/* Home Screen restauration - Greg Dietsche (original HSR 3.0 - 06/19/2002) */
/*===========================================================================*/
void HomeScreenRestore(void);
asm("HomeScreenRestore:\n"\
" movem.l %d0-%d7/%a0-%a6,-(%a7)\n"\
" movea.l 0xC8,%a4\n"\
" movea.l (0x124,%a4),%a0\n"\
" jsr (%a0) | call MenuUpdate\n"\
" move.w #0xA,-(%a7)\n"\
" movea.l (0x3AC,%a4),%a0\n"\
" jsr (%a0) | call ST_refDsp with empty message\n"\
" movea.l (0x38C,%a4),%a0\n"\
" jsr (%a0) | call ST_eraseHelp\n"\
" move.l #0x1E,-(%a7)\n"\
" move.w #0xFF,-(%a7)\n"\
" move.l %a4,%d0\n"\
" andi.l #0xE00000,%d0\n"\
" cmpi.l #0x800000,%d0\n"\
" beq.s ____ti89 | TI-89T\n"\
" cmpi.l #0x400000,%d0\n"\
" beq.s ____ti92PV200 | TI-92P\n"\
" cmpi.l #0x200000,%d0\n"
" bne.s ____other_model | unknown model, skip.\n"
" movea.l (0xBC,%a4),%a0\n"\
" cmpi.b #0xEF,(0x2,%a0)\n"\
" beq.s ____ti92PV200 | V200\n"\
"____ti89:\n"\
"| TI-89/TI-89T\n"\
" pea 0x56E6.w\n"\
" bra.s ____drawline\n"\
"____ti92PV200:\n"\
"| TI-92P/V200\n"\
" pea 0x5A2E.w\n"\
"____drawline:\n"\
" movea.l (0x9F0,%a4),%a0\n"\
" jsr (%a0) | call memset (draws bottom line)\n"\
"____other_model:\n"\
" movea.l (%a4),%a0 | FirstWindow\n"\
" movea.l (%a0),%a0 | dereference the pointer\n"\
"____dirtywindows:\n"\
" ori.w #0x2000,(%a0) | set Dirty Flag\n"\
" tst.l (0x22,%a0) | is there another window?\n"\
" movea.l (0x22,%a0),%a0 | movea does not affect ccr\n"\
" bne.s ____dirtywindows\n"\
" lea (0xC,%a7),%a7\n"\
" movem.l (%a7)+,%d0-%d7/%a0-%a6\n"\
" rts");


void _main(void) {
[Tout le code du _main]
HomeScreenRestore(); // Dernière action du programme.
}

ce truc sous-entend bien que tout programme est sensé se finir dans le Home et pas ailleur.

En effet, mais je ne vois pas en quoi ça gênerait un explorateur de fichiers.

qu'est ce qui prend moins de place (sans compter la mémoire allouée)? le save screen de tigcc ou forcer le redessinage de l'écran ?

./68:
3840*2, c'est pas grand chose...
Et ta "gymnastique", c'est une ligne!

En code dans un programme, c'est clairement SAVE_SCREEN. Mais HSR évite de charger la pile de LCD_SIZE octets environ - le quart de sa capacité totale, donc plus du quart de ce à quoi on a accès.

la RAM j'en ai 158Ko ( Oui j'ai un Tas de TSR installé et Preos aussi ).
le save_screen ça ne laisse plus que 12Ko pour la pile TIOS environ. Si en plus le Viewer est appellé à partir d'autres prog, la pile a qu'à bien se tenir

jfg ->
la gymnastique en 1 ligne tu dis !!!! Je ne pense pas.
La solution la plus simple à codé c'est d'utilise BitMapGet ( ce qui sous-entant gaspillér 3,84Ko pour la copie ).
Dans l'autre cas, faut faire un for pour déplacer pixel par pixel une zone rectangulaire situé au mileu de l'écran virtuel.
Ensuite Faut afficher ce qui manque au bon endroit. Ce peut-être dans les 4 directions

Si c'est pas prise de tête comme gymnastique ça !
Parceque la solution simple j'aime pas trop, car on peu faire mieux.

./81 le scrolling est fait en une ligne (j'assume que le scrolling horizontal est de 8 pixels, car sinon de tt façon ça bave.)

./80 Mais comme généralement on utilise pas toutes la pile...

Il serait bien que tu expliques ce que tu entend par là.
Quelle fonction utilises-tu?

Parce que il y a au moins 2 choses à faire si j'utilse un seule écran Virtuel.
1- déplacer la zone d'affichage qui reste inchangé ( pour cela je doit faire plein de test puisque l'on peut se déplacer de 3 façons :
* case par case
* page par page
* aller au début ou à la fin
2- Afficher les nouvelles données au bon dans l'écran virtuel.

Maintenant tu me dis de suite si je me trompe dans la façon de voir l'implémentation du scrolling dans le Viewer( en fait c'est un éditeur ).

Voici à ce propos un exemple d'affichage


Si des gens sont de l'avis de jfg j'attends quelques éclaircissements car il semble que j'ai tout faux

Est ce que tu peux te déplacer horizontalement ? Si oui, un simple memmove ne suffit effectivement pas.

Si tu te déplace d'une case vers le bas:
memmove(buffer+(y+case_h)*30,buffer+y*30,case_h*30*5);
et tu redessine la 1ère ligne.

vers le haut:
memmove(...#flème#...);
et tu redessine la 6e ligne.

y=ordonée du haut de ton tableau
case_h=hauteur d'une case

Si par contre tu te déplaces dans ton tableau page par page, c'est évident que tu doit tout réafficher... (sauf si tu stock tout ton tableau dans un énorme buffer, auquel cas c'est un jeu d'enfant de scroller verticalement. mais je ne pense pas que tu va faire ça étant donné que ça limiterait la hauteur de ton tableau à 64000/30/case_h cases)

Euh je ne voulais pas d'extrait de code , seulement la méthode car j'aime bien me charger de l'écriture du code .

Je me déplace tant verticalement qu'horizontalement puisse qu'on scrolle dans une matrix .
ça se ne se fait donc pas en une ligne de code. tu vois bien que tu fais plusieurs cas de figures. ça m'étonnait aussi.

M'enfin je m'arrangerai bien pour faire un seul appel memmove dans une boucle for.
Parce qu'autrement c'est pas possible que ça prenne en compte à la fois le scrolling vertical et le scrolling horizontal.

Ensuite je fais un appel pour dessiner ce qu'il faut pour completer l'affichage.

De plus il reste les cas de figure où une partie de l'affichage courant coincide avec les déplacement par page ou déplacement au début/fin

On peut condenser les 2 memmove pour scroller vers le haut et vers le bas en un seul. Et si il n'y avait pas la colonne des indices qu'il ne faut pas bouger quand on scroll horizontalement, on aurait put tout faire avec un seul memmove.</veux avoir raison>
C'est là où je voulais en venir.</lourd>

Je te remercie pour tes suggestions. l'essentiel c'est que ça fasse avancé le soft dans le bon sens