man - Page 3

ben je suppose sinon c'est complètement illisible non ? par contre si tu veux vraiment te faire chier, il y a des règles de séparation bien plus fines que se contenter d'autoriser les fin de lignes sur les caractères blancs (cf. césure, cf. ce que fait TeX, etc... mais ça ne vaut pas forcément le coup non plus ^^)

Folco (./60) :
Et les lignes sont découpées proprement ? ie sur les tirets/espaces/tabulations ?

Ben oui !

La fonction NextLine() d'ebook s'occupe des espaces et des retours à la ligne.

Merci

Bon, j'ai aucune envie de repomper le code d'Ebook Reader, c'est ni mon genre ni intéressant.

Voici l'algo auquel j'ai pensé, dites-moi ce que vous en pensez :
- On copie le texte à partir du pointeur courant jusqu'à la première occurence de \n ou de \0
Boucle :
- On remplace le-dit caractère par \0 après l'avoir sauvegardé.
- Si DrawStrWidth( chaine ) est plus petit que LCD_WIDTH, on affiche sans se poser de question, puis on reprend l'affichage en partant au caractère suivant.
- Si la taille en pixels dans la fonte donnés dépasse LCD_WIDTH, alors on revient jusqu'à l'espace/tiret/tab d'avant, après avoir restauré le caractère précédent
- goto Boucle.

Ca semble naïf, peut-être y a-t-il beaucoup mieux ?


Zephyr -> Ah merci, je savais pas qu'il y avait des softs dédiés à ça, mais comme tu dis, on va pas pousser jusque là. Mais ça reste intéressant.

Réutiliser le code d'ebook est parfaitement permis par la licence. Nombreux sont ceux qui ont réutilisé du code écrit par Thomas ou moi dans les projets TICT. Mais je t'accorde que ça n'est pas aussi intéressant que d'imaginer les algos soi-même

Sur le principe, l'algo auquel tu as pensé et celui de NextLine() sont évidemment globalement similaires
Il faut savoir que certains des ebooks au format TICT Ebook Reader ne comportent aucun retour à la ligne. Leur auteur a tout simplement dû les éditer avec un éditeur de texte qui gère le wrap (en gros, à peu près tous ). Par conséquent, la chaîne est copiée caractère par caractère, et la taille en pixels est calculée caractère par caractère, en accédant directement aux données binaires de la font (ce qui est d'ailleurs plus facile en kernel-based qu'en AMS native... en kernel-based, il y a des RAM_CALLs, alors qu'en AMS native, il faut faire des choses plus compliquées, voir SetupCharSet()).
Je pense qu'il est mieux de faire ainsi que de faire du backtracking.

Ce qui m'importe, c'est que ça ne lag pas. Après, je préfère utiliser les fonctions de haut niveau. Je pense que le code de PpHd doit être assez optimal à ce niveau. Mais au cas où, je ferai ce que tu proposes en effet, merci du tip.

Si tu commences ta routine par un appel à DrawStrWidth, avec en entrée une chaîne contenant un paragraphe de quelques centaines de caractères (personnellement, c'est avec le minimum de retours à la ligne que je ferais une page de man), ça va lagger
Pour avoir la largeur en pixels d'un caractère dans la font 0, il y a sf_width, mais je viens de voir que PedroM ne l'implémente pas, ce qui me surprend un peu: quelques lignes d'assembleur suffisent, et cette routine peut difficilement être moins utilisée "dans la nature" que bsearch, par exemple.

Oui, mais je viens de penser à un truc qui résoud le problème ipso facto : recopier la ligne dans un buffer, pour y modifier un caractère et le remplacer par 0, c'est bien, mais ça nécessite un buffer potentiellement de la taille du fichier (qui peut être archivé, donc read-only). Le truc serait d'utiliser un buffer de 120 bytes (sur la pile), puisque le maximum de caractères affichables me semble être 120 fois la lettre 'i' ou une similaire sur un écran de 240 pixels. Qu'en penses-tu ?

Lionel Debroux (./68) :
Si tu commences ta routine par un appel à DrawStrWidth, avec en entrée une chaîne contenant un paragraphe de quelques centaines de caractères (personnellement, c'est avec le minimum de retours à la ligne que je ferais une page de man), ça va lagger
Pour avoir la largeur en pixels d'un caractère dans la font 0, il y a sf_width, mais je viens de voir que PedroM ne l'implémente pas, ce qui me surprend un peu: quelques lignes d'assembleur suffisent, et cette routine peut difficilement être moins utilisée "dans la nature" que bsearch, par exemple.

AMS 2.00 or higher

Clairement, il faut utiliser un buffer de sortie de taille limitée
Dans ebook, le buffer de sortie passé à NextLine() fait 100 octets, il est alloué sur la pile.
Mais une recopie de la ligne (qu'elle soit faite inline ou en appelant strcpy), avec remplacement d'un caractère par 0, puis un appel à DrawStrWidth, est une double boucle... alors qu'une seule boucle suffit. En séparant la copie et le calcul de la taille en pixels, tu risques d'avoir du code qui est à la fois plus gros et plus lent.


./70: exact, mais PedroM contient au moins deux routines (GetDataType et SmapTypeStrings, je les ai faites parce que j'en avais besoin pour TICT-Explorer) et une variable (FiftyMsecTick) qui ne sont exportées dans la table de jump (GetDataType et SmapTypeStrings), ou tout simplement n'existent (FiftyMsecTick), que sur AMS 2.00+

Lionel Debroux (./71) :

./70: exact, mais PedroM contient au moins deux routines (GetDataType et SmapTypeStrings, je les ai faites parce que j'en avais besoin pour TICT-Explorer) et une variable (FiftyMsecTick) qui ne sont exportées dans la table de jump (GetDataType et SmapTypeStrings), ou tout simplement n'existent (FiftyMsecTick), que sur AMS 2.00+

static inline int sf_width (char c) { return * ((char *)font_small)[c*6] }

Lionel Debroux (./71) :
En séparant la copie et le calcul de la taille en pixels, tu risques d'avoir du code qui est à la fois plus gros et plus lent.

Donc copie d'un char + DrawStrWidth dessus dans la foulée ? Suffit d'initialiser le buffer à 0 avant (ça c'est rapide)

Sinon la table des caractères est foutue comment ? Le plus rapide serait d'aller lire la taille du char en le copiant, ie si on a l'adresse de la table dans a0, lire l'octet offset(a0,<char>), avec offset == endroit où est situé la taille du char, ce que je ne connais pas.

PpHd vient de répondre au post précédent. Tous les 6èmes octets a partir de font_small

Oui, mais je ne comprends pas le chinois. Bon merci.

Donc copie d'un char + DrawStrWidth dessus dans la foulée ?

copie d'un char + sf_width, plutôt

Suffit d'initialiser le buffer à 0 avant (ça c'est rapide)

Pas besoin d'initialiser le buffer, il suffit de terminer la string avec un 0.

Si on utilise pas le romcall, oui, tout à fait.

Idée flash : quid du support de la font de SIDE ? avec genre "-1" dans system\font ?
La font sera-t-elle exportée ?

Ceci dit, à 6 octets le caractère, je peux l'embarquer, mais ça serait un peu con. SIDE ne peut pas exporter une adresse, genre side::font ?. J'aime bien les fontes à chasse fixes pour tout ce qui est informatique technique (source évidemment, mais aussi doc, terminaux etc...).

Folco (./78) :
Idée flash : quid du support de la font de SIDE ? avec genre "-1" dans system\font ?

J'ai proposé l'idée. Sans grand intérêt.
Et faut modifier toutes les fonctions touchant la fonte.

Folco (./78) :
La font sera-t-elle exportée ?

Ca de suite ,c'est plus simple.

Question : la font pourrait-elle être packagée séparément ? Genre non compressée dans /system ou que sais-je ? Histoire que si l'on veut builder PedroM sans SIDE un jour, mais avec man, ça marche toujours ?

Je ne sais pas si c'est une bonne solution par contre.

Et puis elle est tellement géniale cette fonte ! Tous les avantages de la petite avec les avantages des grandes, sans le moindre inconvénient !

Folco (./80) :
Question : la font pourrait-elle être packagée séparément ? Genre non compressée dans /system ou que sais-je ? Histoire que si l'on veut builder PedroM sans SIDE un jour, mais avec man, ça marche toujours ?

... Qu'est-ce que tu veux faire toi encore ????

Euh... rien de spécial, mais on pourrait avoir pedrom@002F (on doit être rendu là) qui pointe sur la fonte, et tous les programmes qui le désirent qui s'y réfèrent, non ? Et Side s'en servirait comme les autres.

Parce que si je ne suis pas sûr que Side soit là, je n'ai plus qu'à embarquer la font, je ne vois pas trop d'autre solution, non ?

... Qu'est-ce que tu veux faire toi encore ????

J'aime bien le ton désabusé, j'ai donc tant d'idées à la konh que ça ^^

Pour des contraintes techniques, ca serait plutôt .set pedrom__sidefont, pedrom__0000+28
Ca irait ? Mais non, mais non

Ca m'irait très bien même !

Sauf qu'il faudra que tu rajoutes le controle pour être sur que ca existe (PedroM 0.80 & 0.81).

Une fois que 0.82 sera sortie, est-ce qu'il faut vraiment se soucier de 0.80, et même de 0.81 ?

Aux programmeurs de voir

Anéfé ! Mais il me semble, si j'ai bien lu le changelog, que la 0.80 souffre d'un bug au niveau de ARGC ou ARGV, qui ne permet pas d'utiliser mes programmes. Quant à la version minimale requise, je la spécifie dans le readme (à cause de RAM_THROW par exemple).

Suggestion : mon éditeur utilisait ça :

.byte    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x22, 0x22, 0x22, 0x00
.byte    0x22, 0x00, 0x55, 0x55, 0x00, 0x00, 0x00, 0x00, 0x22, 0x77
.byte    0x22, 0x77, 0x22, 0x00, 0x33, 0x66, 0x77, 0x33, 0x66, 0x00
.byte    0x55, 0x11, 0x22, 0x44, 0x55, 0x00, 0x22, 0x55, 0x22, 0x55
.byte    0x33, 0x00, 0x22, 0x22, 0x22, 0x00, 0x00, 0x00, 0x11, 0x22
.byte    0x22, 0x22, 0x11, 0x00, 0x22, 0x11, 0x11, 0x11, 0x22, 0x00
.byte    0x00, 0x55, 0x22, 0x55, 0x00, 0x00, 0x00, 0x22, 0x77, 0x22

à la place de ça (side.c) :

  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x02, 0x02, 0x00,
  0x02, 0x00, 0x05, 0x05, 0x00, 0x00, 0x00, 0x00, 0x02, 0x07,
  0x02, 0x07, 0x02, 0x00, 0x03, 0x06, 0x07, 0x03, 0x06, 0x00,
  0x05, 0x01, 0x02, 0x04, 0x05, 0x00, 0x02, 0x05, 0x02, 0x05,
  0x03, 0x00, 0x02, 0x02, 0x02, 0x00, 0x00, 0x00, 0x01, 0x02,
  0x02, 0x02, 0x01, 0x00, 0x02, 0x01, 0x01, 0x01, 0x02, 0x00,
  0x00, 0x05, 0x02, 0x05, 0x00, 0x00, 0x00, 0x02, 0x07, 0x02,

Parce que la table de side est remplie à 50% de vide. La mienne permet de faire ça :

	|=======================================================
	|	compute the mask to apply on the chars
	|=======================================================
	moveq.l	#0x0f,%d1			|if the char is at an ord multiple of 4+n*2
	btst.b	#2,%d2				|is it?
	bne.s	MaskOk				|yes, so continue
		moveq.l	#0xfffffff0,%d1		|else change the mask

puis de masker le sprite des cacartères (bon ok, faut qu'ils soient à une ordonnée multpiple de 4, mais c'est très commode. ^^)

Pas compris....