Salut,

Présentement j´essais de faire un algo qui parse un bitmap ( de 4bits per pixel -> Palette de 16 couleurs, pas de compression... ) et j´ai pas mal de difficulter pour extraire ( correctement ) la partie *data ( j´ai aucun problème pour le header et la palette ) . Je me demandais si l´un de vous avais pas fait un algo du genre que je pourrais yeuté ^^ )

Merci d´avance,

Psy³

Ps : si vous connaissez un endroit ou je pourrais trouver un exemple . .. ( j´ai déjà regardé sur wotsit.org )

En fait la grosse difficulté viens du fait que les rangé sont arrondies au DWORD et qu´il y a deux px par byte . .. Si vous avez une idée :S

personnelement je n´ai pas compris où se situait le probleme :-?

Le prob, c´est que j´suis une merde en algo M´enfin, j´vais m´y remettre . ... peut-être uqe je vais trouver.

Ok ça va j´ai trouvé

le BMP :
je l´ai fait ( si tu as encore des difficultés, parle m´en)

1078 octets de header

ensuite, les pixels balancés de gauche a droite, et de BAS EN HAUT ( pas de haut en bas)
chaque pixels ( 24 bits, car le BMP ne supporte pas le 32 bits) est composé de 3 octets, dans l´ordre " BGR" et non RGB.
il y a également un pitch a respecter me semble t il, mais je ne me rappelle plus comment le calculer, il me semble que c´est un arrondi multiple de 4 octets par ligne...

il y a également un pitch a respecter me semble t il, mais je ne me rappelle plus comment le calculer, il me semble que c´est un arrondi multiple de 4 octets par ligne...

--> Ouaipe, j´ai galérer la dessus

Bah pour l´instant, j´arrive à parser un . bmp de 4bpp sans compression, j´vais me mettre au 8bpp et au 24bpp après.

Quand j´aurais finis je metterai ma source sur un wall, peux-être que coté optim quelqu´un pourra me montrer un ou deux trucs . ..

Merci

Psy³

Tu dois te dire ( ça m´emmerde ce pitch ! !)
a quoi ça sert donc ?
pas vrai ?

faut bein en comprendre l´utilité :
quand tu BLIT un bitmap en mémoire ( en VRAM), il faut que ce soit super rapide, tu es ok ?

si ton processeur est en 32 bits ( on va dire pour le moment)
tu as envie de copier les lignes par paquets de 4 octets ( 32 bits pour aller a fond)

Or, si au bout de chaque ligne, il ne te reste que 2 octets a blitter, que vas tu faire ?
un if ( reste<4) alors tu n´en blit que 2...

- ça t´oblige a faire un if pour chaque fin de ligne
- ça t´oblige a programmer ton GPU ( processeur de carte graphique) pour qu´il sache prendre moins que 4 octets
- sachant que tu blit des lignes par dizaines de milliers par seconde, ça ralentit...

Donc l´idéal est que ça tombe toujours pile ! !
C´est a dire que chaque ligne fasse pile un multiple du nombre d´octets que peut manipuler le GPU...
Et pour cela, on rajoute des pixels en +, de couleurs transparente... Et ces pixels rajoutés sont faits pour que l´alignement mémoire soit respecté, pour que le GPU puisse bosser en pipeline rapidement sans tests ni cas particuliers...
Le nombre d´octets que fait une ligne en réalité donc, est appelé le pitch...

Je ne sais pas si j´ai été bien clair, mais bon...

Vi je me faisait bien une idée sur ça en lisant une doc sur les . bmp Donc, à l´époque de MS-DOS on arrondissait au WORD ? ( Juste pour savoir . . )

Autre question : Quand on load une image qui est pas un . bmp ( un png ou un jpg disont ) , avant d´être affiché, il est transformé en . bmp ?

Mici

seul le format de compression DXTC1 est supporte nativement par certaines cartes de derniere generation. Pour tout le reste ( donc oui, 99.99% des cas), c´est un vulgaire bitmap au final qui atterit qqpart en memoire. Le format exact depend de l´application et des cartes, mais ca reste une bete zone memoire type tableau de " pixels" ( ...), loin des formats evolues du png et autres jpeg.
Pour compter l´utilisation de VRAM de ton appli, il faut donc toujours compter en bitmap brut ( sans oublier les mipmaps...)