FTL Parser 2004 - Page 11

C'est réglable avec les touches + et -. Ca va de 1 pixels à 7 pixels mais quelque fois il y a eu des problème : en remontant le texte ne veut plus s'afficher. Mais c'est surtout avec le mode caché qui ne marche plus très bien depuis le scrolling.

mais j ferais le nécessaire pour la réduire au maximum donc si t'as des conseils je suis preneur.

Brunni :
A l'époque je m'étais "battu" avec hibou parce que je détestais son scrolling pixel par pixel qui n'était joli uniquement sur VTI, sur une vraie calc ça bavait c'était absolument abominable, sans compter qu'il était impossible de suivre quoi que ce soit car ça allait trop vite. Mais apparemment je suis le seul à ne pas aimer ce scrolling, alors je me tais

Je crois voir à quel problème tu te heurtes. Si c'est ce à quoi je pense, là effectivement c'est pas gagné.

A l'époque je m'étais "battu" avec hibou parce que je détestais son scrolling pixel par pixel qui n'était joli uniquement sur VTI, sur une vraie calc ça bavait c'était absolument abominable

Mais apparemment je suis le seul à ne pas aimer ce scrolling, alors je me tais

Et puis si on veut faire des cours qui seront affichés longtemps sur la TI, on n'a qu'à ne pas utiliser d'animation étant donné que ton prog optimise ça.

Peut-être une suggestion si tu n'y a pas encore pensé: faire un mode noir et blanc uniquement.

D'ailleurs toi aussi Raphaël tu devrais pouvoir le faire pas trop difficilement.

Raphaël :
Au début je n'avais pas vu qu'Hibview le faisai et puis il y a deux trois jours j'ai découvert ce truc et c'est vraiment sympa.
Et surtout de pouvoir allez directement à la fin du texte. Je ne sais pas comment je peux faire ça mais bon je vais réfléchir.

A au fait hibou je voulais savoir comment tu faisait pour le scrolling (enfin je pourrais regarder dans les sources) :
Tu précalcule la hauteur du texte avant de l'afficher en fonction de la taille de la fonte ou tu fait ça en temps réel lors de la lecture. Moi je fais la deuxième solution pour ne pas alourdir le parsing et pas bouffer trop de place non plus mais c'est pas l'idéal surtout avec tout les paramètres qu'il faut gérer ensemble. Ce que j'ai fait est assez tordu d'ailleurs parce-que je vais un calcul exprès pour déterminer la hauteur de la ligne précédente lorsque l'on scroll de bas en haut.
Donc je ne peux pas calculer comme ça ou ils faut que je commence à afficher dans le tableau car je ne connais pas la hauteur des lignes suivante ou précédente à l'avance.

Et une fois ayant les hauteurs de toutes les lignes, le page par page est tres facile, et pour aller directement à la fin du texte aussi.

Raphaël
Ouais en fait tu utilise la première solution : tu enregistre les hauteur à l'avance.

Brunni
: En fait vous pré-analysez votre texte. Perso je ne faisais pas ça. Ca a l'avantage d'être plus rapide, ne pas avoir de temps de chargement et ne pas consommer de mémoire supplémentaire. Par contre les gros désavantages c'est qu'il n'est pas possible de faire du centrage (horizontal et vertical) ou l'alignement à droite, justifié, etc.

si, je pense que c'est possible. Je ne connais pas le détail de vos algos, mais avant d'afficher une ligne, vous pouvez surement vous démerder pour étudier/parser cette ligne et donc d'en étudier les dimensions et ainsi agir en consequence.

Brunni
:

si, je pense que c'est possible. Je ne connais pas le détail de vos algos, mais avant d'afficher une ligne, vous pouvez surement vous démerder pour étudier/parser cette ligne et donc d'en étudier les dimensions et ainsi agir en consequence.

Il me semblait que tu faisais comme ça toi?

Sinon dans le cas de Text Walker il me semble qu'il soit impossible de le faire avec un scrolling. Imaginons que le gars dessine un rectangle, de 200 de hauteur. Si on va tout en bas du texte puis qu'on remonte, on ne va pas aller chercher 200 pixels plus haut que le haut de la page pour voir s'il y aurait éventuellement un rectangle à dessiner...

Sinon dans le cas de Text Walker il me semble qu'il soit impossible de le faire avec un scrolling. Imaginons que le gars dessine un rectangle, de 200 de hauteur. Si on va tout en bas du texte puis qu'on remonte, on ne va pas aller chercher 200 pixels plus haut que le haut de la page pour voir s'il y aurait éventuellement un rectangle à dessiner...

Avec text walker, je peux par exemple dessiner un rectangle, y placer une fenêtre et écrire mon texte qui sera sur plusieurs lignes. Là je ne vois absolument pas comment faire...

Je crois qu'il faut t'occuper du rectangle (lorsqu'il est dans l'écran ou même à moitié) et après tu t'occupe de regarder pour chaque éléments s'ils peuvent être affiché ou non.

après tu t'occupe de regarder pour chaque éléments s'ils peuvent être affiché ou non.

C'est pas si simple. Et déjà comment savoir que le rectangle se trouve à moitié dans l'écran s'il est peut-être défini 500 pixels plus haut que la page affichée?

Raphaël
: En parsant le fichier avant.[....]

Sinon le mode ccahé marche enfin de nouveau avec le scrolling ! Il sera donc toujours possible de décacher du texte avec la touche DIAMOND en "temps réel" dans le viewer.
Et l'explorateur XML ne pose plus non plus de problème lors de l'affichage du texte contenu dans les balises !

un mode caché ?!?
remarque pourquoi pas d'ailleurs tu me donne des idées.....héhé

effectivement, en parsant avant, on peut toujours se débrouiller. Mais Brunni a choisi de faire de l'économie de mémoire et de ne pas avoir de temps de chargement. Sous ces conditions, ca semble impossible.

Raphaël :
Par contre, c'est pas gagner pour ton viewer d'après ce que j'ai compris, non ? ... Vu que tu fait le calcul avant le parsing ?
Enfin non, en fait. Quand le texte est caché il suffit de passer à la ligne suivante ou précédente suivant le sens dans lequel du scroll et le tour est joué.
Sauf que si le texte est caché à la première ligne ou à la dernière ça pose un problème supplémentaire.
J'ai déjà résolu le premier (par miracle ) et il faudra que je m'occupe du suivant.

Si, si c'est possible mais il faut qu'il fasse l'étape du parsing dans le viewer.

La syntaxe de txtrider/hibview oblige de parser le texte entierement avant de l'afficher, que ce soit du simple scrolling ou du page/page. Et la syntaxe que txtwalker permettant des formatages plus évolués, le scrolling devient trop compliqué.

hibou :
Mon problème, c'est que la fonte change à chaque #1, #2 ou #3. Mais c'est juste un changement. Donc, si je scroll pour remonter le texte, je dois parser "à l'envers" en remontant le code. Le problème est qu'il m'est impossible de connaitre la font avant une balise #1 à part à remonter tout le texte. J'ai tourné le problème dans tous les sens, on peut pas s'entirer sans connaitre le format de chaque ligne à l'avance !

J'ai fait ça parce que je me suis dit que ça m'éviterait les emmerdes d'une fonction "remonter d'une ligne" (très lourd parce qu'elle doit gérer tous les styles -> tout reprogrammer, et en plus ça risque d'être moche avec le wordwrap)

__attribute__((regparm))void PutBitmap(short x, short y,unsigned char *pic,unsigned char *video_plane)
{
	
  short i=0,j=0;
  short nb_l=pic[1];
  short nb_c=pic[3];
  *pic=+4;
  while(j<nb_l)
  {
        short y_offset = (y<<8)-(y<<4);
        short x_pic = x;
        short i=0;
        while(i<nb_c)
        {
  	       *(video_plane+((y_offset + x_pic) >> 3))|=*(pic++);
  	       x_pic=x_pic+8;
               i=i+8;
  
        }
       y++;
       j++;
  }
}