These tools are VERY cool Mr. Mouse
Just having some trouble with the 32 bit bmp textures... just using the Texture Finder to "look" at them, then save them and then open in Photoshop...
Any idea of a prog that can open them directly? I couldn't get this DTX plug in to work...
Cheers for now
Important information: this site is currently scheduled to go offline indefinitely by end of the year.
SXWad format - Counterstrike Xbox
every time i put the mc.mrf file i downloaded in Commander data/config dir and then i try and open the program it say MEX Open MRF Failed can anyone help me with this.Mr.Mouse wrote:Okay, please backup your old MC.MRF file in the MultiEx Commander data/config dir, and replace with attached. You can now open xpr files and extract the stuff, EXCEPT for the last file in there. I haven't found a way yet to overcome the format for the last one.
Will release anyway in the next version.
- tschumann
- advanced
- Posts: 57
- Joined: Sat Jun 03, 2017 9:35 am
- Location: Australia
- Has thanked: 7 times
- Been thanked: 4 times
- Contact:
Re: SXWad format - Counterstrike Xbox
I know it's a little late but does anyone know the .xpr format?
There is documentation at http://wiki.xentax.com/index.php/Counterstrike_XBox_XPR which is mostly right but it doesn't give any details about how to get the actual texture information out in a usable form. Slapping a .dds header on the texture data creates images which you can see are roughly correct but they are not usable. I can't work out how to get the texture dimensions and it looks like the textures are stored in such a way that the data is duplicated (each block of texture data has two instances of the image side-by-side).
Possibly the second uint32 in the unknown uint64 is DDS_HEADER.dwFlags but I'm really not sure.
There is documentation at http://wiki.xentax.com/index.php/Counterstrike_XBox_XPR which is mostly right but it doesn't give any details about how to get the actual texture information out in a usable form. Slapping a .dds header on the texture data creates images which you can see are roughly correct but they are not usable. I can't work out how to get the texture dimensions and it looks like the textures are stored in such a way that the data is duplicated (each block of texture data has two instances of the image side-by-side).
Possibly the second uint32 in the unknown uint64 is DDS_HEADER.dwFlags but I'm really not sure.
- tschumann
- advanced
- Posts: 57
- Joined: Sat Jun 03, 2017 9:35 am
- Location: Australia
- Has thanked: 7 times
- Been thanked: 4 times
- Contact:
Re: SXWad format - Counterstrike Xbox
With some other documentation I was able to work out the structure:
iFormat can be 12 (DXT1), 14 (DXT3) or 15 (DXT3) and you can the usable values like so:
Code: Select all
struct xprFileData
{
__int32 iType;
__int32 iOffset;
__int32 iLock;
__int16 iFormat; // one of these bytes is the format, and the other is always empty?
byte iWidthComponent;
byte iHeightComponent;
__int32 iSize; // unused?
};
Code: Select all
int iFormat = (m_pFileData[i].iFormat >> 8) & 0xFF;
int iWidth = (int)pow(2, (m_pFileData[i].iWidthComponent - (m_pFileData[i].iWidthComponent % 16)) / 16);
int iHeight = (int)pow(2, m_pFileData[i].iHeightComponent);
- tschumann
- advanced
- Posts: 57
- Joined: Sat Jun 03, 2017 9:35 am
- Location: Australia
- Has thanked: 7 times
- Been thanked: 4 times
- Contact:
Re: SXWad format - Counterstrike Xbox
As a follow up, the .xpr format is meant to be a standard XDK format but the Counter-Strike Xbox .xpr files don't seem to conform. There is any interesting quote from one of the developers at http://www.ritualistic.com/forums/showp ... stcount=27
The textures are not stored in the model files (well, they are, but those are the old crappy 8-bit PC counter-strike textures which are never loaded by the engine) but in separate 32-bit resource bundles that are embedded in the sxwad. again, the resource bundles are substantially different from the ones generated by the bundling tool that ships with xbox XDK (we needed added functionality so we ended up writing our own exporter).