Okay, Chrono Cross Textures

[FaustWolf]

Looking at the RAW files with Tile Molester, it definitely appears there's tiled...somethings in here.



Since Tile Molester only allows you to pull palletts from 16-bit console savestates or the file itself, the next step is to stuff the pallette data into the RAW file as Ramsus suggested. When I get a chance to do that, I'll report back.

[Gemini]

The .act files are actually CLUTs converted into Photoshop palette format. Also, some backgrounds share the same CLUT, so it would be impossible to integrate them all with the appropriate clut-less TIMs, but I'm sure there must be some data to solve this issue in the folder containing the script among all the other data. In addition to that, the drp files *should* (not verified, but it must be like that because of the method used for loading all the data) contain the field 3D model depending on the room.

[Ramsus]

This is what we have when we combine the palettes with the images (via Photoshop). This was done by offsetting the pixel data by 20 bytes and reading it as a 128x256x8 pixel image.

[attachment deleted by admin]

[ZeaLitY]

Aha, no different from what the VRAM gives us, as expected. But, this is decisively important...

If I can succeed in ripping the rooms, I'll begin assembling these maps as a hobby, or at least institutionalize the effort.

In fact, we should probably keep a running log of what folders we've covered and whatnot. We're at a relatively early stage, so I'm sure in the coming days, we'll get much more organized.

[Ramsus]

Some more examples. There should be some data somewhere describing how these fit together, so we should try to identify what everything in the room files is.

[attachment deleted by admin]

[Ramsus]

It looks like the script isn't the only part of the Room file that's compressed...

[FaustWolf]

Sweetness! Ramsus, did you have to import the palettes from separate act files, or did you actually stuff the act file into the RAW image data? I don't have photoshop, but I might be able to reproduce the results in Tile Molester or find another image program capable of the task so I can help out with this over the coming weeks.

Zeality, shall we use the Cross File Structure wiki to keep track of which folders we've cleared and which files we've ID'd?

According to Gemini, the drp files in Rooms\Disk 1\####\unknown are probably 3D model data, so that leaves the "code" directories as the potential source of any other data.

[ZeaLitY]

Definitely.

Yeah, no telling where the instructions for laying out those 128x16 blocks are. Contiguous location blocks seem to be that width until black space or, in the case of Nadia's Bell, a continuous stretch of pure color is encountered 16x16 or longer. Then it skips that.

Overlay tiles, on the other hand, can be as small as 16x16 blocks.

It's cool that despite all the backup chances (VRAM, debug menu) for dealing with location stuff, we know have the true data. So we can be sure we've ripped everything one it's all processed.

[Vehek]

I guess the "MIM" thing was a false lead for the backgrounds.

[FaustWolf]

I hadn't gotten around to checking for .MIMs in the iso yet, Vehek. I *believe* Yazoo's tools may have used LZSS decompression on the room files, and the .MIMs are also LZSS compressed, aren't they?

After a quick check, it appears the compressed .OUT files in the Rooms directory may have 3D data first, then the palettes and textures, etc. The "drp" data comes first in these compressed files, anyway.

And as far as 3D data is concerned, since we're talking about 2D pre-rendered backgrounds, wouldn't the only 3D data involved just be walkmeshes? Do you remember if .MIM files include walkmeshes along with 2D pre-rendered background data, Vehek?

And a follow up question to Ramsus and Zeality: are you pulling palettes from the .act files or from the "#palette" file that's also in the Code directory? I've found a workaround with Tile Molester now that Ramsus has revealed the palette offset, but I used the #palette file and it looks just a bit screwy still.

[Ramsus]

I was using the act files, but I read up a bit on PSX textures and also figured out what the 20-byte header information was in the RAW images (or at least, how to get the width/height from it), so I should be able to write a program to just output bitmaps from the RAW images and the original CLUTs.

I'm also looking into the lzss compression used for some of the files and the script. It turns out Yazoo finished the lzss decompressor for the script as one of the other programs, so I'll figure out the specifics of it from his code and decompress everything to see what else we're missing.

EDIT: To be clear, the current "Room-decompress2.exe" doesn't decompress anything; it just breaks everything into separate files. The compressed parts are still compressed.

[FaustWolf]

Aha, thanks for the clearup on act files and the LZSS compression. So that means we might not be able to view the various 3D files yet, perhaps? I saw an LZSS-decompress function in Nemesis' tools IIRC; would we run that on files we suspect are compressed once we figure out how to get Nemesis' tools functioning?

BTW, does the room-decompress2.exe cut out for you before dumping everything, or is it just me?

Ramsus, you R awesome! Programmers make the world go 'round.

[Ramsus]

No, it crashes at room 503 for me too. I'll debug it later to pinpoint the exact problem, but I'm still too busy during the week, and even on the weekends...

[ZeaLitY]

I poked around in the room files and it looks like the monster, NPC, and other dynamic people / textures are stored per room. Guess I'm not used to that, since traditionally I've only seen things load independent objects in rooms rather than lump in planned objects with the room data. Anyway, that should explain the monster / NPC duplicates. I'm guessing the NPC models will also be in there? Seems like a redundant, bloated way of doing things in terms of data size...

[FaustWolf]

VERY NICE discovery, Zeality. Yes, it would explain the gazillion Cybot copies I keep seeing if one were stored per room / dungeon in which that enemy appears. All the ones you've seen are stored as normal .TIMs, right? And not CLUT-less TIMs or the weird format the character battle model textures are in?

I'm starting to believe that monsters (maybe all enemies in general) use the same textures both in and out of battle. However, I have yet to see Time Devourer TIM textures, so maybe this isn't the case after all (unless I'm wrong about the TD texes?).