FTL Parser 2004 - Page 8

rien n'empeche quiquonque de retrousser ces manches et d'aider PpHd si on découvre/resou des bugs, il en sera surement meme tres content

Euh il avait écrit une première version d'un memmove/memcpy optimisé, puis j'avais réécrit en plus rapide (il faudrait juste relire pour vérifier que y a pas de bug). C pas de ma faute si il a pas sorti de nouvelle version depuis... (pas envie de forker )

Bon finalement la release c'est pas pour tout de suite (en tout cas pas avant 2 semaines) : je vais implémenté la getsion des images. Il faudrait que je refasse l'affichage du texte pour que quand on se déplace avec le viewer, on se déplace de pixel en pixel et non plus ligne par ligne. Parce-que jusqu'à maintenant ça allais bien mais avec les images ça va être un peu plus dur. Avec des sprites c'est très facile vu qu'ils ont la même taille mais là avec 3 fontes et puis pleins de paramètres je ne sais pas comment je vais faire.
On peut déjà affiché des image image mais il faudrait que j'ajoute des paramètre spéciaux pour les image du sytle : encadré, centré ....
Mais par contre pour la structure je ne sais pas trop comment faire : ce que j'ai fait ne tiens pas du tout debout et je veux faire un truc correcte.
Est-ce que ça vous paraît bon si j'utilise une structure comme ceci :

struct
{
union
{
Bitmap_in_text *Bitmap;
Text *TEXT;
}File;

unsigned char bit:1;

}Document;

Avec le bit je sais si la ligne à affiché correspond à du texte ou a une image... par contre ça va être la galère pour manipuler les structure.

./211: Oui sauf que j'ai plein de bugs a corriger...

Raphaël :
Avec le bit je sais si la ligne à affiché correspond à du texte ou a une image... par contre ça va être la galère pour manipuler les structure.

GCC va padder ton bit à un octet entier (au moins; je me demande s'il ne va pas le padder à 2 octets). Et les octets entiers sont plus simples à tester, donc mets plutôt unsigned char flag;. D'ailleurs, conseil spécial, utilise 255 plutôt que 1 pour "vrai", c'est plus court à obtenir sur le 68k.

Ok. Par contre j'ai des gros problème de crash : j'ai dû me planter quelque part en remplaçant les structures.
Voici les structures que j'utlises :

typedef struct
{

unsigned char stick_char:2;
unsigned char color:2;
unsigned char align:2;
unsigned char under_line:1;
unsigned char on_line:3;
unsigned char font:2;
unsigned char animate:2;
unsigned char left:2;
unsigned char right:2;
unsigned char inter_line:2;
unsigned char br:2;
unsigned char frame:1;
unsigned char blink:1;
unsigned char hide:1;
short x:12;// 4096


}Str_Mode;
typedef struct
{

char *str;
Str_Mode *param;


}TEXT;


typedef struct
{
union
{
BITMAP *Bitmap;
TEXT *Text;
}File;
unsigned char flag;
}DOCUMENT;

Je déclare la structure qui va stocker le fichier lors du parsing comme ceci :
DOCUMENT *Document=malloc(2048*sizeof(DOCUMENT));

Ce qui doit faire un tableau de 2048 lignes si je ne me trompe pas...

Et ensuite j'alloue la mémoire pour le texte et les paramètre comme avant c'est à dire comme ça :
Document[nb_str].File.Text->str = malloc(Mem_to_alloc);
sauf qu'avant j'utilisais la structure TEXT au lieu de la structure document ce qui faisait :
TEXT *Text = malloc(2048*sizeof(TEXT));
et
TEXT[nb_str]->str = malloc(Mem_to_alloc);

... Avec ces unions je n'y comprend pas grand chose et apparement il n'y a pas ou pas assez de mémoire allouée pour stocker le texte et les paramètres alors que j'ai simplment changé de structure.

Avec ton malloc, tu n'alloues que ton tableau de pointeurs. Il faudra en plus allouer toutes tes structures TEXT et StrMode séparément.

Ouais, c'est ce que je faisais avant et ce que je fais toujours :

Il faudra en plus allouer toutes tes structures TEXT et StrMode séparément.

C'est à dire ?
Il faudrait que j'alloue aussi 2048 lignes pour TEXT par exemple et ne pas faire comme je fais ? :

DOCUMENT *Document=malloc(2048*sizeof(DOCUMENT));

Document[nb_str].File.Text->str = malloc(Mem_to_alloc);
Document[nb_str].File.Text->param = malloc(sizeof(Str_Mode));

Une fois j'ai alloué autant de mémoire pour la structure TEXT et ça a marché seulment après j'ai touché un truc et depuis ça ne marche plus alors je suis revenu en arrière.

Raphaël
: Il faudrait que j'alloue aussi 2048 lignes pour TEXT par exemple et ne pas faire comme je fais ?

Oui! Ce que tu fais présuppose que tu as un membre TEXT Text, alors que ce que tu as est un membre TEXT *Text!

Ah ouais mais là ça bouffe carrément plus de mémoire alors !
Ce que je voulais faire c'est une structure qui contient :
- la structure TEXT qui permet d'avoir une chaîne et un paramètre.
ou
- la structure BITMAP qui permet d'avoir une image.
- Et un octet pour savoir si c'est une image ou une chaîne de caractère.

Et c'est avec cette structure que j'alloue en fonction du nombre de lignes. C'est possible de faire ça ?
Parce-que je ne m'y suis peut-être mal pris pour faire ma structure là ?

Je suis arrivé à faire ce que tu viens de me dire en reprenant une sources antérieure mais c'est pas ce qu'il y a de meiux parce-qu'il faut deux tableaux : un pour Document et puis un pour Text alors que je n'ai besoin de qu'un seul en fait.
Il faudrait mettre l'octet flag au même niveau que TEXT et BITMAP alors ?

Si tu veux faire ça, ta structure sera de taille variable, donc tu ne peux pas l'utiliser dans un tableau. Un tableau de pointeurs à la limite, mais pas un tableau tout court. La déclaration serait:

typedef struct 
{ 
unsigned char flag; // Le flag AVANT l'union!
union 
{ 
BITMAP Bitmap; 
TEXT Text; 
}File; 
}DOCUMENT;

mais comme déjà dit, ça ne va pas aller avec ton tableau.

Ok.
Mais alors la structure DOCUMENT fait combien d'octets ? : 4 pour File + 2 (vu que la structure en fait 6 lorsque j'ai regardé avec printf) pour flag.
Et ensuite il faudrait de nouveau allouer de la mémoire pour TEXT ou BITMAP.
Ce qui fait encore 4 octets et donc 10 au total ?
Je ne comprend pas l'intérêts des Union dans ce cas ?
En fait pour gaspiller moins de place il faudrait que je face une structure avec le flag et une autre qui contient l'union TEXT et BITMAP.
Comme ça, ce couterait que 4 octets pour l'union + 1 pour le flag = 5 octets ?

Tu n'as visiblement pas compris la différence entre une structure qui contient un pointeur et une structure qui contient une autre structure directement.

Ce que je ne comprend pas c'est pourquoi cette structure n'irait pas :
typedef struct
{
unsigned char flag; // Le flag AVANT l'union!
union
{
BITMAP Bitmap;
TEXT Text;
}File;
}DOCUMENT;

Enfin je vais essayer comme ça je verrais pourquoi.

J'y suis enfin arrivé et voilà la structure que j'utilise :
typedef struct
{
unsigned char flag;
union
{
BITMAP *Bitmap;
TEXT Text;
}File;

}DOCUMENT;
En fait j'avais fait l'erreur bête de laisser un pointeur à Text alors que les seuls trucs qui sont alloués sont les éléments de la structure Text. Et puis pour Bitmap rien n'est alloué puisque j'utilise directement les fichiers PIC.
Donc tout marche sauf que la méthode d'affichage (enfin de scrolling) qui fait déplacer le texte de ligne en ligne n'est pas adapté aux images... et là je ne sais vraiment pas comment faire pour scroller tout les 3-4 pixels par exemple... Enfin je verrais plus tard parce-que là je n'ai pas le temp.

les bmp sont en nvg au fait ?
si oué, ca va prendre cp de place

Je sais pas. Pour l'instant c'est des PIC en noir et blanc... enfin en gris foncé et blanc. Je pensais aussi ajouter une syntaxe qui permette avec deux images de faire deux plans pour les nvg mais c'est vrai que ça prendra de la place.
Je pensais à compresser les PIC en un autre format avec le RLC ou autre chose mais ça ne servira pas à grand chose vu qu'il faudra quand même les décompresser pour l'affichage.

ba sinon, tu met par défaut en noir et blanc pis si y'a deux plans tu met en nvg ...

Oui c'est ce que je voulais faire : s'il y a deux images sur la ligne de code j'affiche en niveaux de gris et sinon j'affiche que sur un plan. La routine de l'AMS est assez rapide mais je ne sais pas ce qu'il en est si j'affiche deux images. Je vais peut-être essayer de trouver une meilleure routine mais mais je ne sais pas si elle sera bien meilleure. Xlib en a une je crois ? ... Et ça vaut le coup par rapport à celle de l'AMS ? Et elle est clipée ? Par contre ça risque de me me rendre plus de place surtout.
Et puis je ne sais pas ce qu'il en est pour PedROM.

Non, je veux dire qu'un st.b D0 est plus court et plus rapide que les 2 instructions que tu viens de proposer.

Et un moveq #1,d0 ou moveq #-1,d0 est encore plus rapide que tout ça Mais évidemment, ça ne fait pas de truc conditionnel.

La différence est que st.b marche aussi pour les adresses mémoire et pas moveq. C'est pour ça que 255 est un choix meilleur pour "vrai". On peut utiliser moveq #-1 dans les registres et st en mémoire.

Ah oui en effet ça donne des trucs du genre : st (%a0,%d3.l). J'avais encore jamais vu cette instruction.

La série sCC est vraiment l'instruction la plus exotique du 68k. J'ignorais complètement son existence et surtout son utilité pendant longtemps. C'est Samuel Stearley qui a fini par me la montrer.

Porquoi elle n'est pas expliqué dans les documentations de motorola ?

Si, elle y est.
Elle est désignée par Scc (cc représente la condition et peut prendre 16 "valeurs" différentes : ne, eq, cc, cs, vc, vs, hi, hs, ...)

D'ailleurs, 'sf' peut même avantageusement remplacer clr.b (plus rapide).

Non, c'est la même vitesse

Ah bon, 'sxx' va aussi lire l'opérande? Faut dire que j'ai pas regardé une table de timing depuis super longtemps, alors des points de détail comme ça...