EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Development::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=590)
-   -   WLD 0x30 Fragment Question (https://www.eqemulator.org/forums/showthread.php?t=34576)

PixelEngineer 12-07-2011 08:07 AM

WLD 0x30 Fragment Question
 
I know this is more about development for the server and my client has fully working textures, but this is just bugging me. It seems azone handles the 0x30 fragment perfectly although the undocumented nature makes it difficult to figure out.

According to Windcatcher's WLD documentation which I have been updating, it is implied that the reference for reference fragments directly follow the header. Take the documentation of 0x30.

Quote:

0x30 — Texture — REFERENCE

Reference points to a 0x05 Texture Bitmap Info Reference fragment.

Fields

Flags : DWORD

Bit 1........ Typically 1. If set to 1, then the Pair field exists.

Params1 : DWORD

Bit 0........ Apparently must be 1 if the texture isn’t transparent.
Bit 1........ Set to 1 if the texture is masked (e.g. tree leaves).
Bit 2........ Set to 1 if the texture is semi-transparent but not masked.
Bit 3........ Set to 1 if the texture is masked and semi-transparent.
Bit 4........ Set to 1 if the texture is masked but not semi-transparent.
Bit 31...... Apparently must be 1 if the texture isn’t transparent.

To make a fully transparent texture, set Params1 to 0.

Params2 : DWORD

Typically contains 0x004E4E4E, but I’ve also seen 0xB2B2B2. Could this be an RGB reflectivity value?

Params3[0] : FLOAT

Typically contains 0. Its purpose is unknown.

Params3[1] : FLOAT

Typically contains 0 for transparent textures and 0.75 for all others. Its purpose is unknown.

Pair : DATAPAIR

Only exists if Bit 1 of Flags is set. Typically contains 0 in both fields. Its purpose is unknown.


--------------------------------

Now it seems that it would be the first item but if I am understanding correctly, the 0x05 reference appears to be the last item.

Can anyone confirm this or explain what the heck this code from azone is doing in relation to this fragment.

Code:

FRAGMENT_FUNC(Data30) {
        Texture *temp;
        int params;
        params = *((long *) (buf + 4));
        if(!params || !*((long *) (buf + 20))) {
                *obj = (void *) malloc(sizeof(Texture));
                temp = (Texture *) *obj;
                temp->count = 1;
                temp->filenames = (char **) malloc(sizeof(char *));
                temp->filenames[0] = "collide.dds";
                temp->flags = (int *) malloc(sizeof(int));
                temp->flags[0] = 0;
        }
        else {
                if(!*((long *) buf))
                        *obj = wld->frags[*((long *) (buf + 28)) - 1]->frag;
                else
                        *obj = wld->frags[*((long *) (buf + 20)) - 1]->frag;
                ((Texture *) *obj)->params = params;
        }

#ifdef FRAG_DEBUG
        printf("Data30: %p %p\n", obj, *obj);
#endif

        return 0;
}

I assume it is simply grabbing the parameters and not handling them but the advancement of the pointer by 4 bytes (which should account for the reference) is throwing me off. I have decoded it to my own coding method (still sloppy as I am unclear about what it all does).


Code:

// If parameters were 0 (should indicate an invible poly)? and then OR and the it checks to see if the next 20 byte cast is 0 as well?
if(!params || !*((long *) (temp_p + 20)))
    {
                // I am pretty sure that this refers to a texture that is supposed to be invisible
                // It could be applied to geometry like barriers that are not supposed to be seen
                textures[current_tex30].fragRef = frag_num;
                textures[current_tex30].textureRef = NULL;
    }
else
{
        // Again, not sure what this if statement is checking for. To see if the memory is zero again?
        if(!*((long *) temp_p))
        {
                errorLog.writeError("0x30 - Got to this weird area. Not sure what it is for!");
        }
        else
        {
                // The texture reference itself
                reference = *((long *) (temp_p + 20)) - 1;
        }
}


Can any EQEmu devs or knowledgeable people comment on what I may be missing here?

Thank you.

Also, a teaser: http://i.imgur.com/T4zBD.png

PixelEngineer 12-07-2011 08:16 AM

Went back and looked over the newer azone source (thought I had the latest), my apologies. This is how the fragment is handled.

Just the beginning:
Code:

FRAG_CONSTRUCTOR(Data30) {
  struct_Data30 *data;
  uint32 ref;
  Texture *tex;

  data = (struct_Data30 *) buf;

  buf += sizeof(struct_Data30);

  if(!data->flags)
    buf += 8;

  ref = uint32(buf);

Looks like a struct is made and the data is copied into it. Then we move past the size of the struct.

Code:

struct struct_Data30 {
  uint32 flags, params1, params2;
  float params3[2];
} typedef struct_Data30;

Then it looks like if the flags are 0, which I think means the texture is completely transparent, we move past the datapair which appears to be 8 bytes and then we can read in the reference.

I will try this tomorrow. I am also working on an updated version of the WLD documentation which I will release with the source of the client.

PixelEngineer 12-08-2011 11:20 PM

I guess I was a bit tired when I was first looking at this because I seem to have added unnecissary confusion myself. The fragment is documented correctly but the reference does appear to be at the end of the fragment.

Cheers.

Tabasco 12-09-2011 09:24 AM

Do you have a source repository for this?

PixelEngineer 12-09-2011 02:39 PM

I will as soon as the source is a bit more stable.

Tabasco 12-09-2011 03:40 PM

Quote:

Originally Posted by PixelEngineer (Post 205219)
I will as soon as the source is a bit more stable.

Why wait? One of the greatest benefits of open source is collaboration.

PixelEngineer 12-10-2011 12:16 AM

Point taken. Give me to the end of the weekend to cleanup some things and write a bit of documentation and I will post the SVN details. This will not be an ideal release for people who want to explore zones. This is mainly an unstable zone loader thus far with quite a few zones that won't load and a handful of bugs I am slowly eliminating.

Tabasco 12-10-2011 10:52 AM

That sounds great, I'm looking forward to digging into it.

PixelEngineer 12-11-2011 10:15 PM

Source:

http://www.eqemulator.org/forums/sho...8&postcount=29


All times are GMT -4. The time now is 02:55 PM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.