La Couronne de Cuivre

Certaines BAM ne ressemblent à rien à l'affichage car la partie data est visiblement compressé 'RLE':

Structure du fichier BAM décompressé
"
0x0008 4 (dword) Offset frame data|Compressed
* bits 30-0: Offset to frame data
* bit 31: 0=Compressed (RLE), 1=Uncompressed
"
Exemple: ILEAT16.BAM / Armure cuir Orc +3

Si je lis 2 Dword parmis les 4, j'obtiens une position à 1084 soit '0000010000111100'

Si les 2 dword suivant, j'obtiens pas 0 comme c'est le cas souvent mais 32768 soit '1000000000000000'.

J'ai donc en bit 31, un '1' qui signifie compression RLE:
Structure du fichier BAM décompressé
"
//Frame Data
* If this is not a compressed frame, then this is simply width*height bytes, which are pixel values using the palette
* specified earlier.
* If this is a compressed frame, the data is compressed with a run-length-encoding scheme. The scheme
* is as follows:
* Any byte which is not the transparent index from the header represents itself
* The transparent index followed by a byte x represents (x+1) copies of the transparent index
0x0000 1 (byte) position_palette
"

La gestion de la palette de couleur est visiblement différente (je confirme le rendu sans rien changer à la lecture est très moche ).

Questions:
"RLE"?

La partie data commence bien en position 1084? Si je lis à partir de là, les valeurs sont toutes à '0'.

Coco

Coco

Après avoir utilisé Near Infinity pour obtenir le fichier BAM ILEAT16.BAM décompressé et l'avoir ouvert dans un éditeur hexadécimal, je me demande si tu ne fais pas une erreur dans la manipulation que tu décris. Sans conséquence dans le cas présent, mais potentiellement dommageable avec certains fichiers.

Cocrane a écrit :Structure du fichier BAM décompressé
"
0x0008 4 (dword) Offset frame data|Compressed
* bits 30-0: Offset to frame data
* bit 31: 0=Compressed (RLE), 1=Uncompressed
"
Exemple: ILEAT16.BAM / Armure cuir Orc +3

Si je lis 2 Dword parmis les 4, j'obtiens une position à 1084 soit '0000010000111100'

Si les 2 dword suivant, j'obtiens pas 0 comme c'est le cas souvent mais 32768 soit '1000000000000000'.

J'ai donc en bit 31, un '1' qui signifie compression RLE:

Une fois lu l'en-tête de fichier de 24 octets, je constate que la première Frame Entry est à l'adresse 0x18, soit juste après l'en-tête. Après avoir passé 8 octets, je lis bien la même chose que toi.

Tu as interprété complètement à l'envers le bit 31. Le 1 signifie Uncompressed, donc sans RLE.

Par ailleurs je ne comprends pas pourquoi tu coupes en 2 mots de 16 bits. La documentation explique bien que seul le bit 31 est particulier. Les autres forment l'offset dans le fichier. Donc il ne faut pas que tu t'arrêtes aux 16 premiers bits pour la connaître car elle pourrait fort bien dépasser les 16 bits sur de gros fichiers BAM.

Cocrane a écrit :Structure du fichier BAM décompressé
"
//Frame Data
* If this is not a compressed frame, then this is simply width*height bytes, which are pixel values using the palette
* specified earlier.
* If this is a compressed frame, the data is compressed with a run-length-encoding scheme. The scheme
* is as follows:
* Any byte which is not the transparent index from the header represents itself
* The transparent index followed by a byte x represents (x+1) copies of the transparent index
0x0000 1 (byte) position_palette
"

La gestion de la palette de couleur est visiblement différente (je confirme le rendu sans rien changer à la lecture est très moche ).

Questions:
"RLE"?

La partie data commence bien en position 1084? Si je lis à partir de là, les valeurs sont toutes à '0'.

J'ai déjà évoqué la décompression RLE dans nos échanges dans l'ancien sujet unique, à partir de là.
La question de la palette est aussi traitée.

Mais vu que l'image n'a pas de compression RLE, l'usage du buffer devrait être direct et exploiter directement la palette. Le cas échéant, méfie-toi de la couleur transparente, qui dépend du contenu de la palette (son index est la première valeur de la palette qui vaut RGB(0,255,0)) et qui peut varier d'un fichier à l'autre.

Si à la lecture des informations de l'autre sujet, tu as toujours des questions, n'hésite pas.

Une fois la discussion lancée, je propose de déplacer les messages de l'autre sujet dans celui-ci. Vu que c'est classé par date, ils apparaîtront avant ta question, mais qu'importe.
Tu peux le faire toi-même en tant que modérateur. Je peux m'en charger, si tu préfères, j'ai l'habitude.

Salut,
je lis en temps normal le champ en une fois pas en deux. Mais c le second cas où j'ai un problème de valeur après lecture.

Si je lis le champ Dword sur 4 en une fois j'ai une valeur négative pour certaines BAM.

J'ai le même problème avec l'info Kit dans le CRE. Edwin a pour valeur 128 et j'obtiens autre chose. Si je lis le champ en deux fois, j'obtiens '128'...

Exemple: ILEAT16.BAM / Armure cuir Orc +3
Valeur si lue en une fois: '-2147482564'

Les autres BAM d'itm me renvoient '1084'.

Je te donne mon code simplifié au cas où tu constates une erreur sur la lecture de la valeur:

// Variable
SSCar4 est un entier sans signe sur 4 octet
num,num2 est un entier

//Code
SELON type
...
CAS "strref", "byte","word","dword":
fLit(id_fic,tail,&SSCar4)
num=Val(NumériqueVersChaîne(SSCar4,"o"),"o")
RENVOYER num
...

Coco

Quand le bit de poids fort d'un entier est à 1 et que ton langage lit les entiers comme des entiers relatifs (pas seulement positifs), il est normal que la valeur soit vu comme un nombre négatif. C'est dû au principe du codage en complément à deux, qui est à ma connaissance à peu près universel en informatique et en électronique.

A partir du moment où tu identifies un nombre négatif, dans le cas du bit indiquant l'usage du RLE, il te suffit de conserver le signe du nombre pour déterminer si le bit est à 1. Si le nombre est négatif, le bit est à 1, donc il n'y pas de codage RLE. Si le nombre est positif, le bit est à 0 et donc il y a un codage RLE.

De même, si le nombre est positif, il donne l'offset. Pour un nombre négatif, il suffit d'annuler le bit de poids par un masque binaire, si le langage dispose d'un ET binaire, et je suis à peu près sûr qu'il doit l'avoir (je pense qu'on en avait déjà parlé ou que j'avais cherché si WinDev en disposait quand il était question d'autre chose). En appliquant un ET binaire avec la valeur 0x7FFFFFFF, tu vas faire disparaître le bit correspondant à RLE et récupérer simplement la valeur de l'offset.

En lisant ton code, je ne comprends pas pourquoi tu fais toutes ces opérations. On dirait que tu lis bien un nombre entier non signé de 4 octets (SSCar4). Mais ensuite tu le convertis en chaine de caractère, pour ensuite convertir de la chaine vers un entier (je suppose signé). Si je comprends bien, c'est là que tu passes la valeur en négatif, alors qu'elle serait positive si tu exploitais SSCar4.
Avec un nombre forcément positif, il te suffirait de tester si le nombre est supérieur ou égal à 2147483648 (2^31) pour savoir si le bit de poids fort est à 1.

Les nombres binaires, hexadécimaux etc..

J'avoue mes dernières conversions datent de mes cours et ça fait un bail.

En gros, je ne maitrise plus grand chose.

Au niveau du code, effectivement, je me complique la vie. J'ai cherché le mot clé pouvant m'aider et la bonne syntaxe à l'époque.

Finalement, j'ai le même résultat avec:

num=Val(SSCar4,"d")

"Pourquoi faire simple qd je peux faire compliqué!"
(allez on dira que le jour où j'ai codé cette partie, gt très fatigué).

J'ai forcé les valeurs négatives comme tu l'as signalé et j'obtiens un offset Data à 1084 comme pour les autres. Cependant, j'ai tj une Bam très moche à l'écran (saleté de Bam).

Dès que une bam mal lue, j'ai une valeur négative qui est tj la même. En enlevant, le signe négatif j'ai 1084.

"
BAM V1 Données d'image

S'il ne s'agit pas d'une image compressée, il s'agit simplement de largeur * hauteur octets, qui désignent les valeurs pour chaque pixel à l'aide de la palette définie juste avant.
S'il s'agit d'une image compressée, les données sont compressées suivant un principe Run-Lenght-Encoding. Ce principe est le suivant :
- tout octet qui diffère de l'index de transparence défini dans l'en-tête représente sa propre couleur
- l'index de transparence suivi d'un octet x représente (x + 1) copies de l'index de transparence


Remarque : le principe du codage RLE est notamment expliqué ici. Il ne présente aucune grosse difficulté de codage dans le cas présent. Il s'agit simplement de répéter x + 1 fois un pixel de la couleur transparente.

Le point important non explicité est le fait que la palette comporte 256 couleurs, puisque la couleur de chaque pixel est codée sur 8 bits.
La fameuse couleur transparente est éventuellement définie dans l'en-tête. Si elle n'est pas définie, elle prendra pour valeur (dans la palette de 256 couleurs) la première entrée de la palette qui a un code RGB correspondant au vert (0, 255, 0). C'est pour ça que le vert apparaît fréquemment dans l'affichage des BAM dans les outils. Ce choix n'est sûrement pas anodin car il correspond à la couleur de transparence utilisée en fond au cinéma pour découper les acteurs afin de les superposer à d'autres images.
"

"
Structure du fichier BAM décompressé
"
0x0008 4 (dword) Offset frame data|Compressed
* bits 30-0: Offset to frame data
* bit 31: 0=Compressed (RLE), 1=Uncompressed
"

Dans le cas où j'ai une valeur négative on est donc en mode non compressé. Mon code est axé sur le compressé. J'ai fait un test rapide. C'est bon j'ai ma bam d'armure Orc.

J'avais pas vu de cas Non RLE à l'époque et j'ai du coup pas géré la partie code.

Existe t'il un hopital pour ceux que BG rend fou?

Merci de ton coup de main!


Au sujet de faire une partie claire sur les BAM, je suis toujours d'accord mais en ce moment, j'ai pas bcp de temps et j'essaie de tenir mon planning pour l'éditeur.

Coco

Je cherche le nom de la bam, si elle existe, de l'icone de la main pour la souris dans le jeu.

J'ai cherché via NI mais sans succès.

Qui aurait le nom de cette BAM?

Coco

Tu veux parler de CURSORS.bam ?

Dans le mille Luren!

Je l'ai raté en consultant NI.

Je te remercie. Maintenant, il n'y a plus qu'à l'utiliser dans l'éditeur.

Coco