Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Development

Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum)

Reply
 
Thread Tools Display Modes
  #1  
Old 12-07-2011, 08:07 AM
PixelEngineer
Sarnak
 
Join Date: May 2011
Posts: 96
Default 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:
Reply With Quote
  #2  
Old 12-07-2011, 08:16 AM
PixelEngineer
Sarnak
 
Join Date: May 2011
Posts: 96
Default

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.
Reply With Quote
  #3  
Old 12-08-2011, 11:20 PM
PixelEngineer
Sarnak
 
Join Date: May 2011
Posts: 96
Default

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.
Reply With Quote
  #4  
Old 12-09-2011, 09:24 AM
Tabasco's Avatar
Tabasco
Discordant
 
Join Date: Sep 2009
Posts: 270
Default

Do you have a source repository for this?
Reply With Quote
  #5  
Old 12-09-2011, 02:39 PM
PixelEngineer
Sarnak
 
Join Date: May 2011
Posts: 96
Default

I will as soon as the source is a bit more stable.
Reply With Quote
  #6  
Old 12-09-2011, 03:40 PM
Tabasco's Avatar
Tabasco
Discordant
 
Join Date: Sep 2009
Posts: 270
Default

Quote:
Originally Posted by PixelEngineer View Post
I will as soon as the source is a bit more stable.
Why wait? One of the greatest benefits of open source is collaboration.
Reply With Quote
  #7  
Old 12-10-2011, 12:16 AM
PixelEngineer
Sarnak
 
Join Date: May 2011
Posts: 96
Default

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.
Reply With Quote
  #8  
Old 12-10-2011, 10:52 AM
Tabasco's Avatar
Tabasco
Discordant
 
Join Date: Sep 2009
Posts: 270
Default

That sounds great, I'm looking forward to digging into it.
Reply With Quote
  #9  
Old 12-11-2011, 10:15 PM
PixelEngineer
Sarnak
 
Join Date: May 2011
Posts: 96
Default

Source:

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


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 06:42 AM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3