FTL Parser 2004 - Page 10

Ouf ça me rassure ! Je pensais que j'avais encore fait n'importe quoi. C'est pas grave, de tout façon j'ai bientôt finit de programmé ce que je voulais et j'utilise les routines de lignes d'extgraph 2.

J'ai fini le clipping dans BitmapPut de PedroM (Code a l'arrache).

Ok, parfait ! Et au fait tu en es à la version combien maintenant ? Et elle sort quand la prochaine version ? Et memset et memcpy ont été amélioré ?

Du calme. Je finis 0.81: des bugs a corriger, des fonctionnalites a ameliorer. memset n'a pas ete ameliore. Il le faut ?

Du calme.

Je finis 0.81: des bugs a corriger, des fonctionnalites a ameliorer. memset n'a pas ete ameliore. Il le faut ?

J'ai testé la version PedRom et je me suis aperçu que assez lent alors j'ai pensé que ça venait de la routine DrawChar mais ensuite je me suis aperçu que c'était aussi lent avec la routine de TinyX : c'est presque deux fois plus lent que sur l'AMS.
Je n'utilise plus memset mais memcpy je l'utilise toujours et je me demandais si ça venait de ça ?
S'il est aussi rapide que celui de l'AMS il n'y a pas de problème mais dans le cas contraire la version de PedRom sera plus lente.

memset et memcpy sont lent. Oui. Bon je corrigerai cela un jour.

Ouais parce-que là par contre il y a une majorité de programme qui l'utilise si ne n'est pas tous.

Rapahel: pkoi tu veux des memcpy/memset rapide ? pke bon, si t'as besoin de rapdiité, autant les faire toit même ... ca sera surement mieux adapté

pkoi tu veux des memcpy/memset rapide ? pke bon, si t'as besoin de rapdiité, autant les faire toit même ... ca sera surement mieux adapté

J'ai déjà fait refait memset en C et c'est jsute un poil plus rapide que l'AMS. Et pourquoi je en veux pas ? ... Bah pour utiliser autant que possible les routines de l'AMS parce-que je cherche vraiment à faire le programme le plus petit possible.
Et puis memset et memcpy c'est quand même bien les fonctions les plus courantes alors ça vaut le coup de les optimiser sur PedRom. Si tout le monde doit refaire les routines parce-que celle de la ROM ne sont pas rapide c'est pas cool... enfin je sais pas vous en pensez quoi ?

C'est idiot de refaire les fonctions qui sont déjà dans la ROM dans les programmes. La vitesse n'est pas une excuse valable.

nEUrOO :
Rapahel: pkoi tu veux des memcpy/memset rapide ? pke bon, si t'as besoin de rapdiité, autant les faire toit même ... ca sera surement mieux adapté

Mais non. Le memcpy/memset d'AMS est rapide, sauf qu'il y a un gros temps d'initialisation (=> pas top pour les petites structures <100 octets )

Rapahel: oki, je pensais que ct pke tu trouvais ca pas assez rapide ... (sans en savoir ton utilisation)

Kevin: heureusement qu'on a jamais besoin de tracés de lignes rapides par exemple

Personnellement, quand je veux tracer un segment, j'utilise des ROM_CALLs comme DrawLine ou DrawClipRect... Sauf à un endroit dans Backgammon (la barre du milieu dans DrawCurrentBoard) où je trace des segments horizontaux très courts à une position x connue dans 3 plans de gris différents et où, par conséquent, il est plus simple de faire ça inline.

En tout cas, c'est fait.

Kevin: c'est vrai que Backgammon demande des ressources graphiques incroyable ...

C'est la preuve qu'il n'y a pas besoin de ressources graphiques incroyables pour faire un jeu

J'ai aussi un pb au niveau de la rapidité sous l'AMS avec malloc (sous pedrom ça va bien mieux et si dans les prochaines version le memset et plus rapide ça sera parfait) parce-que je l'utilise "en temps réel" dans le programme pour allouée une quantité précise de mémoire et pour les fichier qui font plus de 5 ko ça devient une catastrophe. Et je me demandais si il était possible de faire quelque chose à ce niveau là : du genre coder un malloc plus rapide ?

Utilise un seul bloc et HeapRealloc au lieu d'allouer des tonnes de blocs. (Sur PC, c'est en général un mauvais conseil, mais sous AMS, c'est nettement plus efficace. AMS déconne complètement s'il y a trop de blocs.)

Utilise un seul bloc et HeapRealloc au lieu d'allouer des tonnes de blocs. (Sur PC, c'est en général un mauvais conseil, mais sous AMS, c'est nettement plus efficace. AMS déconne complètement s'il y a trop de blocs.)

Et avec ça, il n'y a aps de mémoire alloué pour rien ? Et pour faire un seul bloc je fais comment : c'est tout des pointeurs et il y en a pas mal : les images, le texte, les paramètres, les balises XML et les formatages définis par les utilisateurs.

memset et memcopy sont similaires a AMS en termes de vitesse dans la 0.81 (3% plus lent).

Comme vous pouvez le voir dans cette capture (issue de la toute dernière version) FTL Parser à pas mal évoluer : j'ai entièrement recodé le viewer pour réaliser un scrolling par pixel permettant un déplacement plus agréable.
Par contre c'est peut-être pas ce qu'il y a de mieux : en fait il n'y a pas de scrolling sur l'écran et tout le texte est afficher à chaque fois.
Sinon j'ai ajouté la possibilité d'inclure des images avec cette commande #img[nom du répertoire\fichier PIC]
Tout comme le texte il sera possible de lui attribuer des paramètres ou des modes de formatage : la plupart des paramètres pour le texte ont été repris pour les images.
En tout cas j'aurais bien galéré ! J'espère que vous comprenez que la date de la release soit un peu repoussé mais il doit sans doute resté des bugs (notamment dû au clipping).
Normalement c'est pour bientôt ... et je vais avoir besoin de beta testeurs et puis de personnes pour réaliser quelques exemples (si quelqu'un à le courage ?).
[img]http://perso.wanadoo.fr/raphael.domenge/programmes_ti89/projet_ftl_parser/FTL Parser v0.55.gif[/img]

Ton viewer a l'air d'etre vraiment performant
Perso, je trouve ta syntaxe un peu bizarre, mais pourquoi pas.

Par contre c'est peut-être pas ce qu'il y a de mieux : en fait il n'y a pas de scrolling sur l'écran et tout le texte est afficher à chaque fois.

La solution que j'ai adopté pour hibview est d'ajouter 2 buffers, 1 pour le haut de l'écran, 1 pour le bas.
Ainsi, je fais un scrolling de l'écran ligne de pixel par ligne de pixel. Puis, je recopie la ligne de pixel manquante de l'ecran à partir d'un des buffers (suivant le sens du scrolling). Des qu'un buffer se "vide", je le rempli en dessinant la ligne qu'il faut dans le buffer.
L'inconveniant est en mémoire : pour toi, il te faudra 2 buffers * 2 couleurs * hauteur_maximale_d'une_ligne * largeur_de_l'ecran/8

Ton viewer a l'air d'etre vraiment performant

Merci. Par contre au niveau du parsing c'est l'horreur à cause de tout ces malloc !

Perso, je trouve ta syntaxe un peu bizarre, mais pourquoi pas.

Ouais c'est clair mais j'ai voulu faire quelque chose de moins compliqué que les balises et puis au début je n'avais pas prévu de faire tout ça alors je suis peut-être partit sur de mauvaise base.
Sinon tu penses que je peux changer quoi dans la syntaxe ?

La solution que j'ai adopté pour hibview est d'ajouter 2 buffers, 1 pour le haut de l'écran, 1 pour le bas.

Ah ok ! J'ai cru que tu utilisais un seul buffer assez grand et que tu dessinais plus bas.

L'inconveniant est en mémoire : pour toi, il te faudra 2 buffers * 2 couleurs * hauteur_maximale_d'une_ligne * largeur_de_l'ecran/8

Ouais surtout que si on compte aussi les images.. enfin elles peuvent être clippées sur les deux buffers aussi.
Pour le moment je vais y laisser comme ça ; j'ai passé toute la journée depuis ce matin à essayer de faire ce scrolling.

Et au fait tu travailles toujours sur la dernière version de Hibview en ce moment ?

Raphaël
: Et au fait tu travailles toujours sur la dernière version de Hibview en ce moment ?

oui, et ma nouvelle version commence tout juste à marcher

Pour afficher le texte en bas tu peux utiliser DrawCharClip (Attention, c'est plus lent que DrawChar).l

Oui pour la version PedRom (qui pourra être utilisé avec l'AMS également mais ça va être très lent). Mais il faudra que je clip dans mon programme les coordonnées pour afficher les lignes des mode encadré, surligné, soulignés... enfin il y en a un paquet.
Par contre il faudrait que je trouve une autre routine que celles de TinyX juste pour les chaînes clippés ou que je tente de la clippé.
En tout cas je vais voir. Merci pour la remarque.

Sinon j'ai ajouté aussi la possibilité de régler la vitesse de scrolling entre 1 à 10 pixels mais ça génère un petit bug : lorsque l'on remonte au début du document il arrive que l'on remonte de 2 à 5 pixels plus haut lorsque l'on modifie la vitesse de scrolling mais bon c'est pas trop grave encore .

Bah, ca peut se clipper tout ca
bonne chance :P

J'ai entièrement refait mon scrolling parce-qu'il était foireux : le fichier était affiché depuis le début ! ... En fait ce que j'avais fait ne marchais pas du tout alors j'ai tout refait est je pense que maintenant c'est au point.
Donc théoriquement ça devrait être plus rapide.

La solution que j'ai adopté pour hibview est d'ajouter 2 buffers, 1 pour le haut de l'écran, 1 pour le bas. Ainsi, je fais un scrolling de l'écran ligne de pixel par ligne de pixel. Puis, je recopie la ligne de pixel manquante de l'ecran à partir d'un des buffers (suivant le sens du scrolling). Des qu'un buffer se "vide", je le rempli en dessinant la ligne qu'il faut dans le buffer.

A mon avis, cette solution n'est pas bonne pour le lecteur de Raphaël, là il a meilleur temps de tout réafficher à chaque fois (par contre bonjour la consommation des piles!) étant donné qu'il gère les animations...
Raphael>Tu effectues un scrolling de combien de pixels à chaque fois?

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.

(par contre bonjour la consommation des piles!)

Je ne sais pas. Mais j'ai pas mal été influencé depuis que j'ai lu la doc de TEXT WALKER et j'ai essayé de réduire au maximum la consommation des piles.
Dans tout les cas (sauf quand on appuie sur une touche) le programme se met en mode idle. A vrai dire il y a même deux modes idle. Un lorsque l'écran ne contient pas d'animation : si ce qui est affiché à l'écran n'est pas animé c'est un mode idle très efficace qui est utilisé. Il attend juste la pression d'un touche. Et il y en a un deuxième lorsque l'écran contient du texte animé : là il y a la gestion des touches et le timer qui va faire quitter le mode idle donc c'est un peu moins efficace mais ça marche quand même bien je pense.
En plus il est possible de régler la fréquences des animations avec une commande.
En ce qui concerne la consommation des piles je pense avoir fait ce qu'il fallait : tout le programme est en idle et dans le viewer je suis sûr que le programme est au moins les 3/4 du temps en idle (sauf si une touche est pressé là c'est moins efficace ).
Tu penses que c'est suffisant où je pourrais encore faire d'autres choses pour réduire la conso des piles ? C'est clair que comparé à ton prog c'est le jour et la nuit mais j ferais le nécessaire pour la réduire au maximum donc si t'as des conseils je suis preneur.
Voici la fonction que j'utilise : c'est celle que m'a indiqué Kevin :
void gray_idle(void)
{
pokeIO(0x600005,0b10111);
}