XeNTaX

Posted: **Wed Jul 05, 2017 4:50 pm**

Hello so i've been reversing the Spiderman 2000PC version of the game. The game stores all its content in a custom file format called pkr also used in tony hawks pro skater.

The models and its textures of each character are in a file with the extension PSX. PSX files may contain a lot of stuff, some are bitmaps and others models and textures in PSXPVR format which make it really hard. The textures are not a single archive, they're split through the file.

I can preview the textures using tile molester and setting view mode to 16bpp ARGB and 2-dimensional.
But the header of the structure is what i'm struggling with.

The first 0x10 bytes i dont't understand their purpose but modifying them doesn't have much impact in the game.
The following 2 words are width and height and the dword is palette related. Then until 0x18 i have no clue, it's there where the actual texture starts.

If you download the zip, each texture offset is:
1: 0005956C
2: 0005DD90
3: 000625B4
4: 00066DD8
5: 000685FC
6: 00069E20
7: 0006E644
8: 0006FE68

I got them using a tool i've coded, here's the source in case you want to check what it's done:
https://github.com/krystalgamer/spidey- ... /psx/psx.c

The reason i know the file name is PSXPVR is due to references in the code. Also there was also something related to VQ which i see might be PVR related but i'm a newbie in graphic file format so i'm seeking help.

Posted: **Thu Jul 06, 2017 12:56 pm**

I made some progress. The textures are compressed, i was able to decompressed them.
Open with tile molester and set codec to 16bpp RGB565.
Any ideia on the format??
It's not a zip, i just added it to upload.

Posted: **Fri Jul 07, 2017 5:08 am**

krystalgamer wrote:The textures are compressed, i was able to decompressed them.

how?

the 0x1c length header looks like this to me
4bytes - unk
4bytes - unk2
4bytes - zero
4bytes - zero2
2bytes - image width
2bytes - image height
1byte - flag //?
1byte - flag2 //?
1byte - flag3 //?
1byte - flag4 //?
4bytes - size of data until next file

Posted: **Fri Jul 07, 2017 3:29 pm**

AceWell wrote: 4bytes - size of data until next file

Thanks, didn't notice this

I'm not totally sure if it's compression but there's something weird going on.
Here's the interesting part of what i've reversed: https://github.com/krystalgamer/spidey- ... #L212-L215

I'll explain a bit of what's going on.
Right next to the header there's 0x800 bytes of RGA565 colors(lets call colorList). After that there's a big chunk of offsets(lets call them offsetList) that point each one point to a position inside the colorList.

The entry of offsetList to be used is calculated using the current location of the pixel being drawn(x,y coordinates that i called them curHeight and curWidth) and the width and the height of the uncompressed image(the v20 and v32 thing that i dont understand). The colors array i have no ideia of what it is, i called it that since i thought it was the palette.

After that it reads 8 consecutive bytes(4 colors) from the colorList and puts them on the the uncompressed texture but here's the interesting part, considering it's currently drawing the pixel at (x,y), it puts the first color at (x,y), the third at (x+1, y), the second at (x,y+1) and the fourth at (x+1,y+1). Also each loop related to the curWidth draws (uncompressed width)*4 bytes into the uncompressed texture.

My current problem is now compressing it again, i'll try and post something if i can.

By the way here's the the decompressed textures. They're raw RGB565.

Posted: **Sat Jul 08, 2017 4:55 pm**

The colorList that i've reference in the latest post is actually the Moser de Bruijn sequence which is used for data interleaving, so i'm now sure the textures are really compressed.

Posted: **Sun Jul 09, 2017 5:16 pm**

Texture extraction is completly done!
Here's a demonstration video: https://www.youtube.com/watch?v=N4WuFQAFnns
The code is here: https://github.com/krystalgamer/spidey- ... _extractor

I have to thank NoFate for telling me about the sequence, without him i'd still be poking around.
Also need to thank AceWell for noticing that important detail about the PSX files

Posted: **Sun Jul 09, 2017 6:45 pm**

Amazing! can't believe what someone made this.
Can you also made tool for a models? (if this is a possible of course)
Thanks!

Posted: **Sun Jul 09, 2017 7:10 pm**

Rutabaga wrote:Amazing! can't believe what someone made this.
Can you also made tool for a models? (if this is a possible of course)
Thanks!

After working on the texture repacker, for sure.

Posted: **Mon Jul 10, 2017 1:08 am**

hmm i can't seem to open the extracted bmp files with anything

i compiled the source with MinGW and everything else seems to work,
i can open the bmps with TextureFinder and the image data looks ok with the RGB565 setting,
i guess the issue is something with the header.

spidey.psx
0.bmp header

Code: Select all

42 4D 00 00 7C 00 02 00 00 00 00 00 7C 00 00 00 
6C 00 00 00 00 01 00 00 00 FF FF FF 01 00 10 00
03 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 F8 00 00 E0 07 00 00 
1F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00

Posted: **Mon Jul 10, 2017 1:02 pm**

AceWell wrote:hmm i can't seem to open the extracted bmp files with anything
i compiled the source with MinGW and everything else seems to work,
i can open the bmps with TextureFinder and the image data looks ok with the RGB565 setting,
i guess the issue is something with the header.

spidey.psx
0.bmp header
Code: Select all
42 4D 00 00 7C 00 02 00 00 00 00 00 7C 00 00 00 
6C 00 00 00 00 01 00 00 00 FF FF FF 01 00 10 00
03 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 F8 00 00 E0 07 00 00 
1F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00

Could you please post the bmp? The header seems indeed wrong. According to that header your bmp has the size of 7mb which is just wrong and the bit offset is 0x7C0000 which is also wrong. How did you compile the code and what's the system you compiled in?
Did you run make or simply gcc? Looks like your BmpHeader structures are 4 bytes padded which is causing the issue.

I'll post my psx.exe here.

Posted: **Mon Jul 10, 2017 2:56 pm**

Thanks a lot for the compiled exe,because i'm noob at this stuff.
Btw will your tool work with psx files from Enter Electro and First game for PS1?
And how i can use your load_from_disk tool?
Thanks.

Posted: **Mon Jul 10, 2017 4:55 pm**

Rutabaga wrote:Thanks a lot for the compiled exe,because i'm noob at this stuff.
Btw will your tool work with psx files from Enter Electro and First game for PS1?
And how i can use your load_from_disk tool?
Thanks.

Most likely not. Since the ps1 version uses a different format called rgb.
Rename your original binkw32 to binkw32_ and my binkw32_proxy to binkw32. It's a dll proxy.

Posted: **Mon Jul 10, 2017 5:42 pm**

krystalgamer wrote: Most likely not. Since the ps1 version uses a different format called rgb.
Rename your original binkw32 to binkw32_ and my binkw32_proxy to binkw32. It's a dll proxy.

Thanks,i renamed dll's,and tried to start the game.
When i running the game executable it pop ups me the VCRUMTIME140D dll error message,despite the fact what i have Microsoft Visual C++ 2015 Redistributable installed..
is this a fixable?
thanks!

Posted: **Mon Jul 10, 2017 6:38 pm**

Rutabaga wrote:
krystalgamer wrote: Most likely not. Since the ps1 version uses a different format called rgb.
Rename your original binkw32 to binkw32_ and my binkw32_proxy to binkw32. It's a dll proxy.
Thanks,i renamed dll's,and tried to start the game.
When i running the game executable it pop ups me the VCRUMTIME140D dll error message,despite the fact what i have Microsoft Visual C++ 2015 Redistributable installed..
is this a fixable?
thanks!

I compiled it in debug mode. If i were you i'd try to compile it myself, earlier was talking to a person with the same error and compiling in release mode didn't help him. Sorry.
Or you could wait for a newer version.

Posted: **Tue Jul 11, 2017 3:34 am**

krystalgamer wrote:How did you compile the code and what's the system you compiled in?
Did you run make or simply gcc?

i don't know how to use the "Makefile", i'm fairly new to compiling sources and i'm not a programmer

Code: Select all

gcc -std=c99 -o psx.exe psx.c psx.h bmp.c

edit
nevermind i got it working, i used the "CFLAGS" you had in the "Makefile" instead (although i've no idea what they mean)

Code: Select all

gcc -std=c11 -g -mno-ms-bitfields -o psx.exe psx.c psx.h bmp.c

my psx.exe is 70.2kb

XeNTaX

Spiderman custom PVR format

Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format

Re: Spiderman custom PVR format