Okay, Chrono Cross Textures

[ZeaLitY]

Well, nevermind. I don't have Cross with me and I'd have to rerip both discs by content to make it work.

If someone else wants to try, just make a savestate, load it in VRAM viewer, and find whatever NPC character model appears once the location data stops. For the final Dead Sea area (my savestate), this was going to be really easy because it's Marle (versus some random Termina woman who's hard to identify).

At that point, I was going to look in my dynamic texture BMP rip folder (which I haven't released yet), and find Marle's model to be at 0798. Then I'd scan Disc 1, find 0798, and rip the TIM file. Then I'd open the TIM file in a hex editor and copy the data. Then, I'd open the savestate and search for Marle's character model data. Since her model immediately follows the location tiles in the VRAM, whatever comes before her must be the location tiles. From there, I was going to take a sample of the location stuff and search it in the main ISO or try to perform other procedures.

I'll just have to finish the backlogged site update tonight and release the texture pack so someone else can do it.

[ZeaLitY]

I went ahead and took Van's room as a case study. Mapping it out was a real pain...it's not an exact science at all. There seem to be three layers; a background, outside background, and foreground objects (comparable to layer 1 in Temporal Flux). I couldn't even assemble all the foreground objects properly, but it's no big loss since they're rendered in the background. So, I mapped each layer it gave me, and then made a second "Perfect" image with the backgrounds placed upon one another as the game does it. I think this will be the way we present maps in the encyclopedia (one direct rip, one "perfect" image).

We know the VRAM always gives us the location, but I can't figure out what it chooses to give in the upper right quadrant. For instance, this time around, I got some blank space, menu / dynamic textures, four Pip thumbnails, Van / Korcha dialogue icons, and the textbox image. The bottom right also confuses me; here, at Van's place, I think I got Van in there, but I also saw a Porre soldier. Then, left of the bottom right but right of the actual location map (which is always bottom left), I got "layer 1" map parts of Termina and what looked like a background part of the SS Zelbess interior (which is docked at Termina). It's in the "Strangestuff.png". Interestingly, on my Dead Sea savestate I talked about in the last post, I was able to view huge Norris / Lynx / Harle textures (my party at the time). However, Harle's full face wasn't there; same for Lynx. Norris was, though, and this proves that the model sheets stored as TIM are overworld and NOT the real main character textures for the field map.

So, my conclusion is, it looks like the VRAM at any given time shows all the past data it's accumulated until overwritten. This is a pretty simple conclusion and sort of a "duh" moment, but it's good to know for sure. So if you just came from Earth Dragon Isle and go to Arni, some Earth Dragon Isle tiles might still show up in the cracks. Moving on, I just savestate'd a battle. Sure enough, better, more-detailed character model textures are showing up. Not much else of interest, since all the battle locations / rooms are already ripped as TIM textures. I've noticed that sometimes you can't find the correct CLUT (I'm just going to call them 'palettes') for the "junk" data that accumulates in the cracks, and that makes sense since the palettes loaded don't correspond to those past areas. I'm guessing I just got lucky with that table in Strangestuff.png, and it makes sense because I was unable to find the correct Termina palette for the other junk that showed up.

Anyway, Faust, you might be able to take my previous plan and open a savestate of a battle in VRAM viewer and somehow isolate or copy a chunk of those higher quality character models. It might lead us back to the full set if that chunk's searched in the ISO.

[attachment deleted by admin]

[FaustWolf]

Certainly will do when I get a chance. I haven't done a VRAM dump during battle yet, so this should be interesting. The higher-quality character textures that appear in VRAM during battle haven't been captured in TIMViewer, is that correct Zeality? If that's the case they must be stored as something other than .TIMs?

[ZeaLitY]

Yeah, that's what irks me...maybe they're the same format as location maps.

[jono]

So, my conclusion is, it looks like the VRAM at any given time shows all the past data it's accumulated until overwritten. This is a pretty simple conclusion and sort of a "duh" moment, but it's good to know for sure. So if you just came from Earth Dragon Isle and go to Arni, some Earth Dragon Isle tiles might still show up in the cracks. Moving on, I just savestate'd a battle. Sure enough, better, more-detailed character model textures are showing up. Not much else of interest, since all the battle locations / rooms are already ripped as TIM textures. I've noticed that sometimes you can't find the correct CLUT (I'm just going to call them 'palettes') for the "junk" data that accumulates in the cracks, and that makes sense since the palettes loaded don't correspond to those past areas. I'm guessing I just got lucky with that table in Strangestuff.png, and it makes sense because I was unable to find the correct Termina palette for the other junk that showed up.

Yeah this is how memory is managed in many programming languages, as soon as the application no longer requires a chunk of memory it simply 'frees' it for use later. The free'ing process doesn't actually re-initialise the memory to zero, it just lets it be re-alloacted and overwritten when required.
Also, it's quite random just where the images you want are likely to show up. This is because when the game allocates memory for a texture it will just look for the first peice of sequential memory big enough to satisfy the allocation size in vram. It's possible that if the vram is exhausted, the texture could even be placed in the slower main system ram. If you take a save state and the image you want isn't in vram that is probably what happened.

If it's possible with your tools you guys should try looking in the 2MB of main ram that the psx has. If you are missing textures that are actually on screen in the save state but arn't in vram this is where they will be, along with other goodies like character/battle area/collision geometry and game code.

[FaustWolf]

Gotcha Zeality, and I'll check it out now. At the moment, I'd like to follow up on a previous investigation of Kid's dungeon map texture. This is what happens when I replace her texture with a solid aqua color:

http://img134.imageshack.us/img134/815/kidoverworldyd3.jpg

This makes it clear that character shading is separate from the textures, but then again everyone already knows that probably, since that's the way all character models are I assume.

@jono: That's extremely useful to know. When you speak of viewing main RAM, do you think that's something that would show up in the savestate elsewhere, or would we need to move on to viewing the game code live through a debugger? Zeality found a debugger/emulator earlier and I think it shows RAM IIRC.

[ZeaLitY]

Not to flood a bunch of posts, but I'll go ahead and release the two texture packs tonight and finish the Chrono Cross Beta page. I guess it's just the size of the site now, but all the updates these days turn into huge mega posts. The last one was a record, and this one won't be a pushover since I'll be talking about the Cross developments.

[jono]

Yeah I'm pretty sure that a save state from epsxe will contain the main ram aswell, but thats only because I can't think of a way to save the state of the emulation without the main ram.

So I'd say that it will definitly be within the save state, just a matter of finding at what offset it starts, it will be 2MB long I think I think I read somewhere. Like I said, there will be all sorts of cool things in there, just a matter of figuring out which parts are what.

I don't have one with me at the moment but if the save states are larger than 3MB then I'd say that they contain main ram as well. (1 MB VRAM + 2 MB RAM + sound RAM + other bits and bobs > 3.5 MB I'm guessing)

[FaustWolf]

Well I'll be hot-damned, the battle textures are really different from the .TIMs we ripped!

For folks who haven't seen this sort of thing yet, here's Glenn's in-battle texture side-by-side with his field texture:



Yet another type of data we'll have to worry about! One possible way of locating the data, as Zeality has already theorized, is to find something that appears to be one of the .TIM textures we've already ripped in close proximity to the unknown battle texture type. Below, for example, I'll look for the .TIM texture of the menu window and possibly the "Fast Forward" button, see what that looks like in hex, then compare it to the savestate in hex. Maybe whatever comes just before those confirmed .TIMs will be the in-battle texture of this bug enemy in the Hyrda Marshes.



But the possibility that the in-battle textures are compressed darkens our prospects for success. But hopefully they're in another uncompressed format that PSicture and TIMViewer can't detect.

@jono: Yes, the uncompressed epsxe savestates are about 4MB in length. Shall I post one (if attachment size permits) for you to look at? Though I'm not sure there's any way of telling what's RAM, what's VRAM, and what everything else is.

Ooh, Sound RAM. I didn't know there was such a thing. Maybe that'll help us rip sound effects.

[ZeaLitY]

Attachment size dies at 1 MB. Here's a savestate of mine:

http://chronofan.com/Black/Cross/SLUS_010.41.001

Damn, I probably should have converted all the BMPs to PNGs before sorting them...and Irfanview doesn't seem to have an option to directly rewrite files by each folder. So the update may have to come tomorrow. But once these textures are in PNG format, the texture archives will shrink from something like 12 MB and 30 MB to very small sizes.

[FaustWolf]

Finding battle textures is *not* going well. Mainly because the .TIMs seem to be stored in a really screwy way in the savestate I'm pulling VRAM from (the one with the Hydra Marsh bug enemy). It seems that chunks of the .TIMs are in there, but they are interrupted by other data. I'll use as an example my comparison of the menu window seen in my post above on this page with the savestate hex:

http://img155.imageshack.us/img155/2963/hexcomparewe8.gif
See how there's a chunk of congruous data, then the hex strings go their separate ways before and after?

There are no .TIM headers at all in the savestate data.  Waitaminute, I see one. I'll see if I can't find which .TIM it corresponds to.

However, several things must be noted:

When you open VRAM, you have to carefully search for the right color scheme in the color lookup table (CLUT), which is stored in a different place visually from the graphic you're trying to capture. Therefore, the color schemes may be separated from the .TIM images VRAM pulls from the disc, meaning the .TIM data is still in there but it'll look totally different from a .TIM we pull from the game with TIMViewer.

Also, I've investigated only one savestate taken during battle so far. Perhaps all the textures used during battle are in a different format from .TIM altogether, meaning we can't use .TIM references at all for battle savestates. That text window exhibited above sure looked like one of the .TIMs we pulled, though, so I doubt this is the case for now.

Any thoughts regarding this finding, folks?

EDIT: Okay, it appears some weapon textures are stored as uncompressed .TIMs in VRAM, and even then they're just a bit screwed up. This is exactly what I pulled from my battle savestate with TIMViewer:
http://img340.imageshack.us/img340/9725/weapontexesws0.gif

I have yet to Cross-reference these with .TIMs we've pulled. If they are indeed the same, these, at least, could be used as references in battle savestates for finding other data perhaps.

EDIT: Pure and utter weirdness ahoy! It just so happens that the textures TIMViewer was perfectly capable of pulling whole from the savestate do not appear whole in the savestate. W T F. I'm moving on to other things for now, but Zeality, when you have some spare time see if you're getting the same vibe as I am from your own savestates, especially the Marle NPC one. Maybe my brain's just fried from midterms.

If worse comes to worst, we can always rip the battle textures along with the pre-rendered backgrounds manually with VRAM viewer, though that'll take lots of time and the resulting images will be difficult if not impossible to map on the game CD since we don't have them in their native formats.

[ZeaLitY]

Well, this is unexpected. The crushed PNGs took it down to 15 MB, but 7zip really can't compress it further than that. Yet it has no problem compressing the BMPs to 12 MB. Guess we'll be sticking with the BMPs.

Track_01_6703 (or #6703, or whatever) matches the dagger in that savestate. Guess it doesn't mean much, since the weapons are probably stored right next to each other anyway.

[FaustWolf]

PSXMultiripper produces 13000+ textures, so maybe there's some extra stuff in there we haven't uncovered yet.

[attachment deleted by admin]

[ZeaLitY]

Here are the textures I've uploaded to the encyclopedia as "interesting":

http://www.chronocompendium.com/Term/Current_events.html

For now, they're centralized at that temporary page. I'll link to them in the new update.

[FaustWolf]

Interesting indeed. I've gone through the PSXMultiripper TIMs a little more closely, and as long as you've already got the "long" monster textures and the Garai set I'd say there's nothing more to be had. There's about 8 "fake" TIMs multiripper produces that apparently have invalid headers, though the reason for this isn't really obvious to me when I view them in a hex editor. As for why there's so many more files with PSXMultiripper, there may be a greater number of spell textures. But nothing really noteworthy.