EQEmulator Forums - WLD 0x04 Fragment Question

Hi, this fragment is completed but I am getting a different structure than what I see being used in azone and being used in the WLD documentation.

First off, just to make sure I am on the right page, bits are counted starting at zero. In the WLD documentation, the bits also start at zero. What confuses me is that in azone's handling of 0x04, they check the flags but are off by 1 each time.

For instance, here is the WLD documentation:

Code:

0x04 — Texture Bitmap Info — PLAIN 

 

Notes 

 

This fragment represents an entire texture rather than merely a bitmap used by that texture. The conceptual difference from 

0x03 fragments is that textures may be animated; the 0x04 fragment represents the entire texture including all bitmaps that it 

uses, whereas an 0x03 fragment would represent only a single bitmap in the animated sequence. 

 

Fields 

 

Flags : DWORD 

 

Bit 3........ If 1, texture is animated (has more than one 0x03 reference). Also means that Timer exists. 

Bit 4........ If 1, Params2 exists. Seems to always be set. 

 

Size : DWORD 

 

Contains the number of 0x03 fragment references. It will only reference one 0x03 fragment for most textures but should 

reference more than one for animated textures (e.g. water). 

 

Params1 : DWORD 

 

Only exists if Flags bit 3 is set to 1. 

 

Timer : DWORD 

 

Contains the delay in milliseconds before changing textures in animated textures. Only exists if Flags bit 4 is set to 1. 

 

References: DWORDs 

 

One or more references to 0x03 fragments.

Here is the azone handling:

Code:

if(flags & (1 << 2))

    buf += 4;

  if(flags & (1 << 3))

    buf += 4;

They seem to be off by one byte. I have tested this and found that the animation bit is actually as it says, on the 3rd bit, not the second. Furthermore, I found that as bit 4 is set, params2 don't exist.

Here is my code:

Code:

    // If the texture is animated, mark it as so and read in the animation delay

    if(temp04.flags & (1 << 3))

    {

                bmpInfo[cur_tex04].animated = true;

                bmpInfo[cur_tex04].delay = *temp_p;

                

                // Move past the delay

                temp_p += sizeof(long);

    }

   else

   {

   bmpInfo[cur_tex04].animated = false;

   }

After that, the references to 0x03 bitmaps are read in and they work perfectly. I assume this bug, if I am indeed correct, is unnoticed because they are checking the wrong bit and don't deal with animation in azone. Due to being off by one byte, it ends up still be aligned.

Here are my revisions to the 0x04 fragment documentation.

Code:

0x04 — Texture Bitmap Info — PLAIN 

 

Notes 

 

This fragment represents an entire texture rather than merely a bitmap used by that texture. The conceptual difference from 

0x03 fragments is that textures may be animated; the 0x04 fragment represents the entire texture including all bitmaps that it 

uses, whereas an 0x03 fragment would represent only a single bitmap in the animated sequence. 

 

Fields 

 

Flags : DWORD 

 

Bit 3........ If 1, texture is animated (has more than one 0x03 reference). It also means that texture change delay exists. 

 

Size : DWORD 

 

Contains the number of 0x03 fragment references. It will only reference one 0x03 fragment for most textures but should 

reference more than one for animated textures (e.g. water). 

 

Delay : DWORD 

 

Contains the delay in milliseconds between the texture switch in animation. Only exists if Flags bit 3 is set to 1. 



References: DWORDs 

 

One or more references to 0x03 fragments.

Can any developers please confirm this?

Cheers!