image C -> PIC ?? - Page 1

(je repose le problème dans la rubrique C)

ya encore un truc que je comprend pas..
le programme en C dans le pac flib qui permet de faire les images au format pic,

static unsigned long plan0[] = {0, 32, 0, 32, 0xFFFFFF2F, etc...};

à quoi correspondent vraiment les quatres premiers chiffres?
avec moi parfois ça marche, et parfois ca marche pas ! alors à mon avis ya un truc que je saisie pas...

si par exemple on avait une images de 50 pixels de large et et 40 pixels de hauteur , ça donnerait quoi dans le code source du prog?!

Merci de m'aider...

Les fichiers PIC sont structurés comme ça :
TAILLE du fichier (en octets) -> 2 octets
Nb de LIGNES-> 2 octets
Nb de COLONNES-> 2 octets
Le fichier en lui-même (suite de 0 et de 1)->beaucoup d'octets
PIC_TAG-> 1 octet (ce TAG sert au TIOS pour identifer le type du fichier. Pour une image, le tag est 0xDF)

Donc, pour un fichier de 50 pixels de large et 40 de hauteur, on aura :
unsigned short image[]={255,40,50,..........,0xDF};
40 : largeur de l'image
50 : hauteur de l'image
40*50/8+2+2+1=255 : la taille de l'image + les 2 octets qui définissent le nb de lignes ou de colonnes + le TAG
[edit]Edité par jackiechan91 le 25-03-2002 à 21:11:21[/edit]

Regarde dans Flib, les sources de Image Creator (répertoire utils) peuvent t'aider

Comprend pas trop !
Dans les programmes utilitaires de flib, FL définit la taille de l'image avec 4 nombres.
moi je pensais que si on avait une images de 50 pixels de large et 40 de hauteur, ça ferait : unsigned long image[]={0,50,0,40,.......}.

jackiechan91> pourquoi tu déclare "image" en 'short', pourquoi pas en 'long'.
il me semble que c'est 'long' pour les images de plus de 32x32 pixels.

qui peut m'expliquer...

Je pense que ça ne change rien qu'elle soit déclarée en short ou en long. Il faudrait connaître l'avis d'olivier51 là-dessus, car il doit bien s'y connaître (il a fait TIPaint+).

Vous pouvez pas me donner la ligne de code correspondant à une image de 40 pixels de large et 50 de hauteur.
Merci!

Bon, je m'étais trompé dans mon premier post, en fait il faut faire ça : unsigned short image[]={255,40,50,..........,0xDF}; et là où il y a des points de suspension, tu mets ton image (suite de 1 et de 0 correspondant à l'état des pixels).
Mais il vaut mieux que tu comprennes vraiment comme ça fonctionne, comme ça tu pourras le refaire pour n'importe quelle image. De toute façon, tu auras besoin de comprendre pour pouvoir remplir ton tableau avec les 1 et les 0 qui correspondent à ton image.
Alors, par exemple, une image de 10 colonnes par 5 lignes entièrement noire correspondra à ça dans la RAM :

+----------+------+------+------+------+------+------+------+------+...+------+------+------+
|Adresse : | 89B5 | 89B6 | 89B7 | 89B8 | 89B9 | 89C0 | 89C1 | 89C2 |...| 89C7 | 89C8 | 89C9 |
+----------+------+------+------+------+------+------+------+------+...+------+------+------+
|Contenu : | 0000 | 0015 | 0005 | 0010 | 0255 | 0192 | 0255 | 0192 |...| 0255 | 0192 | 0223 |
+----------+------+------+------+------+------+------+------+------+...+------+------+------+
|En héxa : | 0x00 | 0x0F | 0x05 | 0x0A | 0xFF | 0xC0 | 0xFF | 0xC0 |...| 0xFF | 0xC0 | 0xDF |
+----------+------+------+------+------+------+------+------+------+...+------+------+------+

Voilà.
Les adresses commencent à une valeur que j'ai prise au pif.
Donc, sur les 2 premiers octets, on a 0x000F, soit 15, la taille du sprite (16/8*5+2+2+1, en octets)
Sur les 2 suivants : 0x0005, soit le nombre de lignes (en pixels)
Les 2 suivants : 0x000A, soit 10, le nombre de colonnes (en pixels)
Le suivant : 0xFF, ce qui correspond à une ligne de 8 pixels noirs.
Le suivants : 0xC0, ce qui correspond à une ligne de 8 pixels, dont seuls les 2 premiers sont noirs.
Pourquoi le tableau n'est-il pas rempli que 0xFF puisque le sprite est enièrement noir ??
et pourquoi pour calculer la taille, j'ai fait 16/8*5+2+2+1 au lieu de 10/8*5+2+2+1 ???
e du sprite, les suivantes sont identiques) |____ ___|____ ___| V V 0xFF 0xC0 (1octet) (1octet)

Parce que c'est arrondi à l'octet suivant. En binaire, la lecture de la mémoire à l'emplacement de l'image donnerait ça :
 11111111 11000000 (1ère lign

[edit]Edité par jackiechan91 le 25-03-2002 à 22:10:08[/edit]

longtemps que j'étais plus venu.....

Merci jackie pour ces infos !
Je vais essayer de comprendre tout ça... !
mais je m'y mettrai plus sérieusement cet été ...car maintenant ... le bac approche...!

heu... j'ai fait un petit prog qui ne sert qu'a afficher une image de 160x100 en gray4 (pour tester). ca me prend + de 5Ko sur la ti. C'est normal ? quelle routine prend le moins de place (au point de vue type d'image : bitmap, string en hex, bin, dec) et la routine d'affichage

meowcat
a écrit : heu... j'ai fait un petit prog qui ne sert qu'a afficher une image de 160x100 en gray4 (pour tester). ca me prend + de 5Ko sur la ti. C'est normal ?

Ben ça dépend, si ton image est inclue dans le prog, c'est normal que ça fasse un peu plus de 4ko (2 images en 160*100 font 4ko).

Hum hum... ya pas moyen de descendre la barre ? de compresser la taille (compresser, compresser, attention, je veux pas de zip non plus, mais que l'image saffiche qd meme instantanement)

Tu peux effectivement compresser ton prog en cochant Compress file dans la section Options du menu Project.

Pour afficher un PIC, rien ne va mieux que BitmapPut.
Dans le TICT-Explorer, il y a un viewer de PIC dont le source est (je l'ai modifié car il y a des lignes qui ne sont d'aucune utilité pour un programme simple):
void ViewPIC(HANDLE handle) {
BITMAP* src = (BITMAP *)(HeapDeref(handle));

// Ces lignes sont pour centrer le PIC sur l'écran.
// unsigned short offx;
// unsigned short offy;
// offy = (PIX_HEIGHT - ((BITMAP*)(src+2))->NumRows)>>1;
// offx = (PIX_WIDTH - ((BITMAP*)(src+2))->NumCols)>>1;

memset(LCD_MEM,0,LCD_SIZE);
BitmapPut(offx,offy,src+2,&(SCR_RECT){{0,0,239,127}},A_REPLACE);
GKeyIn(NULL,0);
}

(PIX_HEIGHT est 100 sur la 89 et 128 sur la 92+/V200, c'est la dénomination de tictex pour LCD_HEIGHT).