Affichage des résultats 1 à 8 sur 8

Discussion: Les BAM

  1. #1
    Date d'inscription
    March 2010
    Localisation
    Paris
    Messages 
    1 043

    Les BAM

    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

  2. #2
    Date d'inscription
    July 2003
    Localisation
    Plaisir
    Messages 
    6 827
    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.

    Citation Envoyé par Cocrane Voir le message
    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.

    Citation Envoyé par Cocrane Voir le message
    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.
    Peu disponible
    Guide d'installation (et FAQ) de Baldur's Gate, Baldur's Gate II, Baldur's Gate Trilogy (BGT), BG1Tutu, Widescreen, BGEE
    Pensez à utiliser à la fonction Recherche pour trouver une réponse à votre question !

  3. #3
    Date d'inscription
    March 2010
    Localisation
    Paris
    Messages 
    1 043

    Idée

    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

  4. #4
    Date d'inscription
    July 2003
    Localisation
    Plaisir
    Messages 
    6 827
    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.
    Peu disponible
    Guide d'installation (et FAQ) de Baldur's Gate, Baldur's Gate II, Baldur's Gate Trilogy (BGT), BG1Tutu, Widescreen, BGEE
    Pensez à utiliser à la fonction Recherche pour trouver une réponse à votre question !

  5. #5
    Date d'inscription
    March 2010
    Localisation
    Paris
    Messages 
    1 043
    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

  6. #6
    Date d'inscription
    March 2010
    Localisation
    Paris
    Messages 
    1 043
    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

  7. #7
    Avatar de Luren
    Luren est déconnecté Barbare des terres gelées
    Date d'inscription
    June 2010
    Messages 
    552
    Tu veux parler de CURSORS.bam ?
    Nom : CURSORS.jpg
Affichages : 172
Taille : 1,7 Ko

    un projet de mod pour Icewind Dale 2

  8. #8
    Date d'inscription
    March 2010
    Localisation
    Paris
    Messages 
    1 043
    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

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256