Hi,
So with the public release of the Crash Bandicoot Prototype, I've decided to try ripping each unused screen/map and their accompanying elements from the game. So far, I have used a method which involves a combination of 3D Ripper DX, ePSXe and the Next 3D 1.5 video plugin (the details on my method can be found here). I have tried using other programs like Dragon UnPACKer 5's Hyperripper, Iceberg's Texture Finder, and SnowBro's Tile Molester on the archives within the prototype disk image to extract the textures easier, but only Texture Finder incorrectly read the textures and the other programs gave nothing but false positives. Also, using a VRAM viewer to extract the textures would be a method just as hard if not harder for what I'm trying to do. Anyway, I've been using this method up until now.

My work so far:

Next, I would like to rip the level/island maps. However, I've run into a problem. The sheets are so complex that I wouldn't be able to rip the maps without some kind of algorithm to sort them out. This is how the sheets work:

• The sheets are in a .DDS image format.
• Each sheet has a maximum of 256 colours, and typically has 50% less opacity then it should.
• In each sheet, pure black typically indicates empty opacity.
• There are 15*15 tiles on each sheet (excluding the rightmost column of tiles, which is on a separate sheet.)
• The rightmost column's sheet of tiles are arranged from top to bottom in 32*32 pixel sized groups of 4 tiles, with each top-right tile moved below the top-left tile, and each bottom-left tile moved above the bottom-right tile.
• Each tile is 16*16 pixels in size.
• Each tile on each sheet that uses all colours on the sheet is a correct tile in that sheet. All others tiles should be removed from the sheet.

Sheet-Map Comparison:

Rightmost column layout:

As the example sheets are unmodified, they may be hard to see due to opacity issues. In that case, you could open them up in a program such as Microsoft Paint to understand them better.

In order to finish ripping the maps, does anyone know of a way to make this process simpler?
Thanks.

I recently had similar problems dealing with 32x32 jumbled textures blocks while ripping the textures from King's Field. But I was able to 'convert' those textures to standard TIMs by using search/replace in a hex editor to convert their headers to standard TIMs. I still had to match each 32x32 tile up to its model manually though.

I think the palletes for all 'tiles' are loaded into VRAM- it's just that 3D Ripper is applying one pallete to the entire sheet. I would try P V V or, if maybe "PSX Vram'" (PVV is better). It will still take some work, but it should be easier than 3D Ripper method- especially if you can find the pattern for which palletes go to which tiles.

Playstation makes pure black invisible by default, but they should come out as black in a texture rip. If your textures are coming out semi-translucent, it's caused by the DDS format that 3D Ripper is saving in. Just convert the DDS to a different format that doesn't support an 'alpha channel' (BMP etc).

Crash games don't use standard TIM files so TIM rippers won't help.

I had a wacky afterthought- if you can figure a repeatable pattern to the procedure needed for extracting/converting the tiles, there is a tool called AutoIt AU3Recorder that might help. It records mouse/keyboard movements/clicks to a script and replays them on demand. It could theoretically automate something like splitting/reassembling tiles.  :crazy: