MAT files - Solving the Unknown - Jedi Knight and Mysteries of the Sith Editing Forum

This is the static archive of the Massassi Forums. The forums are closed indefinitely. Thanks for all the memories!

You can also download Super Old Archived Message Boards from when Massassi first started.

"View" counts are as of the day the forums were archived, and will no longer increase.

MAT files - Solving the Unknown

2005-04-04, 12:14 AM #1

Jon`C

Admiral of Awesome

Posts: 18,626

This has been my mini-project starting last night.

So far I've deduced the functions of two 'unknowns':

Code:

struct MATHEADER
{
	int Version;

	int Type;
	int NumOfTextures;
	int NumOfTextures1;

	int NonPalettized; // Enable 16-bit, 24-bit, 32-bit, ...?

	int BitDepth;

	int BlueBitDepth;
	int GreenBitDepth;
	int RedBitDepth;

	int RedShiftLeft;
	int GreenShiftLeft;
	int BlueShiftLeft;

	int RedShiftRight;
	int GreenShiftRight;
	int BlueShiftRight;

	int Unk1; // Alpha depth?
	int Unk2; // Alpha shift left?
	int Unk3; // Alpha shift right?
};

The two I've been tinkering with are 'NonPalettized' and 'BitDepth'.

NonPalettized seems to be a boolean value that flips between using nonpalettized textures and palettized ones. I'm pretty sure the resulting surface uses the same properties as the display surface. This means that if there's ever a 32-bit display depth exe hack 16-bit textures won't work anymore.

BitDepth serves a different function. As best as I can tell, it's used solely in buffer allocation. I was able to get JK to load a 256x512x16 MAT file by using '32' as the bitdepth, but it seems to be scaled down to fit a 256x256 surface.

I'm still determined to solve all of the unknowns in spite of these enraging setbacks.

2005-04-04, 5:01 AM #2

Friend14

Armchair Fysiks Expert

Posts: 1,489

I've got 1024x1024x16 mats to load in JK by playing with one of the options (some type of texture size option if I remember correctly) in the JK options. I think by default, it clips the texture down to 256x256. However, by playing with the option, I got it to render the texture at 1024x1024. The only problem was that only the top left 256x256 was displayed, the rest of the texture was blacked out (it also dramatically reduced the frame rate down to 1-3fps when the texture 'area' was in view (blacked-out or rendered didn't matter)).

Math is infinitely finite, while the universe is finitely infinite. PI = QED

2005-04-04, 11:13 AM #3

Sige

Registered User

Posts: 239

I think I used a 4096x4096 texture once. It just displayed a 256x256 corner of it.
I'm not sure why you think a non palettized texture must be the of the same format as the primary surface. The primary surface is 565, but JK uses both 565 and 5551 texture formats. Also, all palettized textures are converted into 565 or 5551 (depending on whether they have alpha or not). I think it's more likely the per-channel bit depths determine the format, or JK itself determines the format and only uses those for conversion to 565 or 5551.
BitDepth, like you said, is probably just for determining the size of the texture data in the file. So if you set bitdepth to 32 instead of 16 and loaded a texture twice as large it would only take up half the room...was there corruption of the texture colors?

Air Master 3D (my iPhone game)
My Programming Website

2005-04-04, 5:39 PM #4

Sige

Registered User

Posts: 239

I just forced jk to render in 32-bit mode with my wrapper, and 16 bit mats work fine. I will see if I can get a 32bit mat to render. The hud and text are messed up, since jk expects a 16 bit primary surface for those...

Air Master 3D (my iPhone game)
My Programming Website

2005-04-04, 8:04 PM #5

Sige

Registered User

Posts: 239

Well, can't seem to get JK to load a 32bit texture. It always reads in 16 bits, regardless of whether the bit depth is 24 or 32. Also, jk seems to more or less ignore those color depth and shift values and just goes by whether it is transparent or not, from what I could tell.

Air Master 3D (my iPhone game)
My Programming Website

2005-04-05, 4:38 AM #6

BoBo_Fett

Registered User

Posts: 132

Jedi Knight Ignores most of the header values:

Code:

TMatHeader = record
tag:array[0..3] of char; {'MAT ' - notice space after MAT}
ver:Longint;             {Apparently - version = 0x32 ('2')}
mat_Type:Longint;        {0 = colors(TColorHeader) , 1= ?, 2= texture(TTextureHeader)}
NumOfTextures:Longint;   {number of textures or colors}
NumOfTextures1: Longint; { In color MATs, it's 0, in TX ones, it's equal to numOfTextures }
unk0:Longint;            { = 1 } {unknown use}
bits:LongInt;            { = 16} {bits/pixel}
redbits:longint;        { = 5 } {blue bits per pixel}   {ignored by game engine}
greenbits:longint;       { = 6 or 5 } {green bits per pixel} {ignored by game engine}
bluebits:longint;         { = 5 } {red bits per pixel} {ignored by game engine}
shiftR:longint;          { = 11 or 8} {shift left blue} {ignored by game engine}
shiftG:longint;          { = 5 or 4} {shift left green} {ignored by game engine}
shiftB:longint;          { = 0 } {shift left red} {ignored by game engine}
RedBitDif: longint;  //=3   {ignored by game engine}
GreenBitDif: longint;  //=2  {ignored by game engine}
BlueBitDif: longint;  //=3   {ignored by game engine}

unk4h:longint;  //=0 {ignored by game engine}
unk5h:longint;  //=0 {ignored by game engine}
unk6h:longint;  //=0 {ignored by game engine}

end;


Texture Type Header:
The texture Type Header is repeated number of Texture times

 TTextureHeader = record
    textype: longint;         {0 = color, 8= texture}
    colornum: longint; {With 8-bit images, is an index into the palette. .}
    pads: array[0..2] of longint;
    unk1tha: word; //= 16256  {ignored by game engine}
    unk1thb: word;
    unk2th: longint; //=0
    unk3th: longint; //=4  {ignored by game engine}
    unk4th: longint; //=4  {ignored by game engine}
    TexNum: longint; //=0 for first texture. Inc. for every texture in mat
  end;


Texture Data header:
Each Texture in the Mat file has this header before it

 TTextureData = record
    SizeX: longint;             {horizontal size of first MipMap, must be divisable by 2}
    SizeY: longint;             {Vertical size of first MipMap ,must be divisable by 2}
    Transparent: longint;  {1: transparent on, else 0: transparent off}
    Pad: array[0..1] of longint;{padding = 0 }
    {padding = 0 }
    NumMipMaps: longint;        {Number of mipmaps in texture largest one first.}
  end;

JediDreams

2005-06-08, 5:34 PM #7

Xzero Phoenix

el oh el

Posts: 316

Try changing the mipmaps, remove them or something, the surface may actually not change, it didnt for me anyway..

2005-06-08, 7:19 PM #8

JediKirby

GoY's Pessimistic Soy Boy Toy

Posts: 17,361

Quote:

Originally posted by Friend14
I've got 1024x1024x16 mats to load in JK by playing with one of the options (some type of texture size option if I remember correctly) in the JK options. I think by default, it clips the texture down to 256x256. However, by playing with the option, I got it to render the texture at 1024x1024. The only problem was that only the top left 256x256 was displayed, the rest of the texture was blacked out (it also dramatically reduced the frame rate down to 1-3fps when the texture 'area' was in view (blacked-out or rendered didn't matter)).

I can confirm this as I've done the exact same thing. I want to know why framerate tends to dramatically drop on any machine in this situation. Is JK using vurtual memory more this way or what?

JediKirby

ᵗʰᵉᵇˢᵍ๒ᵍᵐᵃᶥᶫ∙ᶜᵒᵐ
ᴸᶥᵛᵉ ᴼᵑ ᴬᵈᵃᵐ

2005-06-08, 8:24 PM #9

SG-fan

Really a MacGyver fan.

Posts: 1,561

I got it to load a full 1024x1024 (or was it 512, eh doesn't matter) without the black or frame loss. However it requires that you have the worst mipmap on, so it looks horrible anyway and isn't worth it.

Sam: "Sir we can't call it 'The Enterprise'"
Jack: "Why not!"

2005-06-09, 9:13 AM #10

Stormtrooper

Loves His Stormie

Posts: 2,068

This is probably extreme lethargy and Mt. Dew induced thinking, but maybe the JK.exe has some sort of cap put on the amount of memory any one mat file can use, and anything above 256x256x16 (or 512x512x8) withouht mips uses more memory than JK allows.

Just a thought.

2005-06-10, 6:19 PM #11

SG-fan

Really a MacGyver fan.

Posts: 1,561

I have a theory on why the mips work. I think they actually shrink the texture (ex. mip level 3 would shrink a 1024x1024 into a 256x256 or a 256x256 into a 64x64), thus you lose quality and size from the shrinking (making it less computer intensive) and the engine can display it.

Sam: "Sir we can't call it 'The Enterprise'"
Jack: "Why not!"