Chrono Compendium
Kajar Laboratories - Fan Works and Submissions => Chrono Cross Modification => Topic started by: FaustWolf on October 10, 2007, 01:03:50 am
-
Hallo alles! <- Me practicing German.
Just completed a dump of the Chrono Cross CD image and I believe I *might* have found a considerable number of textures stored as .bmp files. Take a gander at some of these:
(http://img69.imageshack.us/img69/537/glenntexds4.png) (http://imageshack.us)
Glenn's face.
(http://img69.imageshack.us/img69/9945/riddeltexkh7.png) (http://imageshack.us)
Riddel's face.
(http://img69.imageshack.us/img69/8081/harletexuu9.png) (http://imageshack.us)
Harle's face.
(http://img408.imageshack.us/img408/2776/scythetexid3.png) (http://imageshack.us)
Lynx's Scythe, perhaps?
(http://img69.imageshack.us/img69/6339/komodotexrc8.png) (http://imageshack.us)
Komodo Dragon
Now I must ask the Chrono Community three questions:
1. Has anyone seen these before? Could anyone with some expertise confirm that these are, indeed, model textures?
2. Does anyone know how to view the file structure on the Chrono Cross CDs? These are all messed up because they were ripped from a .bin file of IsoBuster's creation, but they'd be clear as day if they could be ripped directly from the CD. If previous image ripping experience serves me correctly, that is.
3. Would these be useful in any way, say, for 3D modeling practice or re-creating the Chrono Cross models if someone could get their geometry separately?
I'm not sure that *all* Chrono Cross textures are this readily accessible. I haven't gotten anywhere close to sifting through all 6000+ images viewable in the ripped game image, but so far I've only found face and weapon textures as you see above along with what might be spell textures.
EDIT: Er, on second glance, maybe there's more than just faces in there. Is it possible that a character's entire model texture could fit in so small a space?
-
1. Yes, I've gone through all of them before to try and find the blue-bodied, green-haired portrait at Lucca's manor which is partially obscured (and I couldn't find it on either disc).
2. No, we have no idea how to fix that stupid problem...it's a tragedy because there's actual beta art of certain characters on the Chrono Cross demo disc which can't be correctly ripped with all that junk in there. There's also these from the final:
http://www.chronocompendium.com/Forums/index.php/topic,2359.0.html
-
Alot of those can be pieced together easily. Just reverse the two in the row then reverse them 1 by 1, it should match up with the image pretty closely. I'll do that right since I have nothing better to do :S
Edit; There are bits and pieces kinda missing because they're scrambled into something else, either that, or you have to move them up and down to fit in.
Edit 2: the weird letter looks like it says Pon7 or Pan7... cm7 You must come or You must room or something..Really hard to tell
-
But like the Frozen Flame in that other thread, the bottom's missing. I don't think all of the data is making it, or some of it is scrambled.
-
Yea, some of it gets lost or it's placed into another area. I'll post the unscrambled bits I got, it's really weird to setup..
Repost: HEre's what I have.
Top left is a letter...obviously. The next one i'm not so sure, maybe a door in Viper Manor or Fort DRagonia, then there's the area where I believe you get the corrupted Masamune.
Next is Frozen Flame, followed by a Swallow and then that stained glass window.
[attachment deleted by admin]
-
Looks like "don't eat yed mushroom".
-
XD! Now that you say it...it does
-
Is anyone familiar with a program called cutcut.exe made by an individual known as Audigy? It's supposed to get rid of junk data like what's plaguing these textures, but the only link to it I can find is long since broken.
Both IsoBuster and CDRWin are giving me this gobledegook. And PSicture apparently needs a visible file structure before it can scan an entire directory for image data.
Anyone know of a CD backup program that preserves the original CD's file structure? Might have more luck with something like that, perhaps, if it exists. It's probably possible to get textures via VRAM dumps as well, but that would just be a pain in the arse.
-
Well, here's our progress before we stopped due to this problem:
http://www.chronocompendium.com/Forums/index.php/topic,3872.15.html
-
(http://img255.imageshack.us/img255/1481/track010292uq8.png) (http://imageshack.us)
(http://img255.imageshack.us/img255/3695/track010297hx9.png) (http://imageshack.us)
Are we in business?
I hope you like your .rar files big. 'Cuz there's way more than I expected in here.
{Upload Pending}
Though I'm not sure that this is everything in the game. I mean, does it look to you ladies and gents like all of Kidd and Riddel are actually in those teeny weenie squares? Upper half of them at most. Maybe the rest of 'em are tucked somewhere within the .rar's 9000 images.
-
No way; you solved that issue somehow without loss of image data? I mean, I can throw up the demo ISO again...
And I just can't figure out if it's all there myself. I scrolled through all...seven thousand, I think, textures on BOTH discs TWICE to try and find that blue portrait to see if it's Frog or something (or a Nu), and I couldn't locate it anywhere, even with the Lucca's orphanage textures (which did give me all the other portraits).
Somehow, Chrono'99 successfully ripped the character portraits and status screen art without that problem, and he wanted to try and remember how he did it before his computer problems began.
-
Heh heh. I just happened upon a feature in IsoBuster that says, like, "click me if you want to get clean iso data." I ripped the first CD as "content" instead of as an "image." Then I used PSicture as per usual.
I could rip the demo iso images real quick for ya tomorrow morning if you want to throw it up on rapidshare or some other place.
Here's the textures I've got:
http://rapidshare.com/files/61728893/CCTexFiles.rar.html
It'll be 110~130MB when it's uncompressed.
Oh, and this is only the first CD. I'd expect the second to have exactly the same stuff, but do you think there's anything different on #2, Zeality?
-
YEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH
EXTREME PASSION OF YOUTH
(http://narutofan.blog.playersrepublic.fr/album/rock_lee/cover-naruto_lee0048.jpg)
(http://chronofan.com/Zeality/grimmjowyouth1.png)
(http://chronofan.com/Zeality/grimmjowyouth2.png)
(http://chronofan.com/Zeality/grimmjowyouth3.png)
(http://chronofan.com/Zeality/leenight.png)
(http://img287.imageshack.us/img287/140/hollowichigoogcolorqs2.png)
(http://www.cs.uic.edu/~yhuang1/zell.jpg)
It'll take a while to upload the ISO. Maybe it'll be done by late tomorrow. So you've ripped all seven thousand or so each, eh? This calls for some major analysis...oh, what a beautiful turn of events...
The second disc will have some duplicates, but also some different stuff. The hard part in both cases will be sifting through all the boring element effect textures.
ALL RIIIIIIIIIIIIIIIIIGHT!! I must seem crazy for posts like this, but this is too awesome.
-
This is awesome, I can't wait to get my hands on a few of these textures :)
Fantastic work. I'll download as soon as I get a chance.
EDIT: Ahh, I can't seem to download, would it be ok if someone e-mailed this archive to me.
-
Let me get the second disc ripped, Jono, and then I'll throw it all onto MediaMax for you to download with a direct link. That should work. Zeality, did you have any problems with Rapidshare?
THE CHRONO COMMUNITY IS STILL IN THE SPRINGTIME OF YOUTH
MAY CHRONO LIVE ON FOREVER! HUZZAH!!
-
It's been forever since I've seen these textures in game.
They look even better here, unfiltered and not stretched.
(http://img.photobucket.com/albums/v109/Chickenlump/luccawall.png)
-
There's about 10,000 images on Disc 2. Though in reality, Disc 2's .rar is slightly smaller than disc 1's.
Here's the Rapidshare links for both CDs.
http://rapidshare.com/files/61728893/CCTexFiles.rar.html
http://rapidshare.com/files/61819917/CCTexFiles2.rar.html
I hope this stuff will be of some service to the Compendium.
For anyone who would like to duplicate what I've done and rip your own Chrono Cross stuff, you will need a game CD on hand, IsoBuster (freeware version is sufficient, and is available at http://www.isobuster.com), and PSicture (check http://www.zophar.net/utilities/psxutil.html for that).
There's a right way and a wrong way to rip an iso. Here's the right way:
1.) Open IsoBuster once you've got your game CD in and navigate to your CD drive. The following should show up:
(http://img443.imageshack.us/img443/215/step1rq3.gif) (http://imageshack.us)
2.) Now right-click the "CD" icon in the left gui panel and select "Extract CD <Content>" and "Extract User Data" as per below:
(http://img341.imageshack.us/img341/1263/step2ow0.gif) (http://imageshack.us)
Select your file path and things should go smoothly. Let IsoBuster give you a .cue sheet too, though I'm not exactly sure how important that is to viewing images and whatever other files may be on here. Basically, I just wanted to point out the distinction between "Extract CD <Content>" and "Extract CD <Image>." Only the latter ripping routine gives you junk data. Have PSicture run a scan on the resulting file and save what you like from there. Warning: Your PC will be sluggish for a few minutes while PSicture wrangles with the behemoth that is Chrono Cross' innards.
Zeality, you or whoever has physical access to the demo CD will have to do this to get at the unadulterated pictures and textures within the Chrono Cross demo. I don't know of any way to convert a junky iso to a clean one; it just has to be ripped clean. I misspoke (misstyped?) when I said I'd rip the images if you put up the iso. Don't waste the effort of uploading.
Jono, I've not forgotten about you. MediaMax is being pissy about letting me upload stuff right now, so that option's out for hosting these. Do you know of any file sharing site that works with your personal firewall setup or whatever's keeping you from grabbing these on Rapidshare?
-
Okay, I'll rip the demo textures.
Can't wait...
I'll just dump both final discs to the same folder and use checksums to remove the duplicates. Then I'll sort them. Already, I can see that location backgrounds are coming in clearly...this is a major coup for the Compendium and Chrono fans.
-
Okay, around 4000 unique images on disc one, and 77 unique images on disc two.
After my horrible midterms and other nightmarish classes, I can begin analysis. Sadly, the graphs in Chronopolis seem to be generated dynamically...
-
Yeah unfortunately most don't seem to work as I am using the computers at university (I only have dial up at home). The Uni restricts access to most file sharing sites so no go.
If you could e-mail it to brookebackman@yahoo.com.au it would be fantastic, if you can't for what ever reason I'll just try ripping my self.
Thanks either way mate, this is really great for the community.
-
In that case jono, I'd recommend ripping these from your CDs or waiting for the completion of Zeality's duplication-ridding process. The .rars are just over 40MB apiece, so I'd have to stuff your mailbox with 10 separate emails due to Yahoo's 10MB file upload limit per email. I estimate Zeality will get it down to a single 30~35MB archive once he's finished, and perhaps the Compendium will even host it - does the Compendium have that kind of server space?
-
Thats fine :)
Yeah, sorry if I sounded pushy, I'll try and rip them later on. Thanks again for this great find.
-
Yeah, the Chronofan media server will take care of it. My plan is to review all the textures and sort them into different folders. Then, all can be released as a single texture pack.
I'll go ahead and dump the demo to a subfolder, so the duplication checking program will delete all the duplicates found in the final disc and leave us with material exclusive to the Cross demo.
-
Sweetness. Once it's all sorted, maybe we'll be able to tell whether these are indeed ALL the game's textures, or if the collection is still incomplete. As far as characters go, it appears to me like we've got at least two or three sides of everyone's face, upper torso, and weapons, but not their legs or feet. Hopefully I'll be proven wrong on that, as I haven't looked at the files thoroughly yet.
I suppose the completeness of the texture collection will determine how much work needs to be done to get character models, i.e., whether we have to find a way to capture the model geometry only or if we need the textures, shading, etc., to go along with it.
-
Amazingly, after removing the demo's own duplicates, it has no identical data to the final. At least, going by the program's checksum verification...that's weird.
Anyway, things are going smoothly. It seems my memory was correct; Kato snuck in a picture of himself among the characters. So, perhaps HE was the member of the development team at Terra Tower?
More tomorrow. Enjoy reverse-Harle and beta-Janice.
Edit:
HOLY CRAP, THE QUADFFID and a BEACH BUM / NU WERE PLANNED TO BE IN THE PARTY
[attachment deleted by admin]
-
Whoa, is this Toma XIV?
Edit: Here's the stuff on the demo disc I wasn't able to identify. There seem to be a lot of Elements flash / graphical effects in there, along with one real location I can't identify, plus some test images. Once we get these categorized, I'll upload the entire sorted demo stuff and update the demo page. Then it's on to the final version.
http://chronofan.com/Zeality/Demo.zip
[attachment deleted by admin]
-
I narrowed it down to these unknown images. If we can categorize these by location or application, the demo texture pack will be ready to go and I can begin analysis of the character icons and other things I've found.
It's attached. If you've ever played Chrono Cross, then open this and give it a look.
Edit: It's curious that apart from Front Mission 3 and Chrono Cross, PSicture and TIMViewer find no other textures. Yet, one can also play Dewprism and Vagrant Story demos...
[attachment deleted by admin]
-
It looks like 2570 could have been Opassa Beach the only Island close enough to get that view, Could they have planed to have fights at Opassa beach? And 2573 might be atop Mount Pyre only high enough place to get that view that I remember.
-
Thanks; more volunteers are needed, so everyone get into gear! This is amazing.
I've begun updating the demo page and putting together the character analysis:
http://www.chronocompendium.com/images/wiki/5/50/Demo_Cross_Characters.png
I'm going to compare the relation of those images to the final to try and learn more about that Toma-ish character.
I went ahead and went through all 4,000 final Cross textures, with about 600 Element effects / unknown pictures left, which I'll probably get down to about 150-200 unknowns. A neat discovery so far is what appears to be a second cave in the Hydra Marshes.
-
I'm convinced that TIMViewer / PSicture aren't getting all there is to get. I haven't seen the other picture in Lucca's house, much of Termina at all (including the bar's sign or the 100th anniversary sign), the mural at Fort Dragonia...is there a way we could be missing stuff?
Anyway, I saved the interesting textures I've found and will finish updating the demo page now. I'll try to narrow down the unknowns as much as I can, and then release the two texture packs.
If someone wants to make beautiful lightning strike twice...
http://www.chronocompendium.com/Forums/index.php?topic=4187
The room modifier code might help us in this search, and is also a topic of interest all to itself. The kid who made it's notes are in that thread, but good luck trying to decode them.
-
I agree with the observation that PSicture isn't ripping everything there is to rip. The missing stuff might be in a different format than the stuff we've got (which would necessitate a new plugin for PSicture, and the person who coded the program has vanished from the Internet as far as I know).
On an interesting side note, PSicture can only see 8385 files on Disc 1 when it's ripped the "wrong" way and 9743 files on Disc 1 when it's ripped the "right" way. I'm not sure what's causing this phenomenon, though. This is all before duplication removal, of course.
Zeality, can you remind me real quick how far you have to be in the game to see the signs in Termina? Is it in Home or Another, or both perhaps? I'm going to snatch some gamesaves from GameFAQs and examine a VRAM dump when I can see the signs. There is a very slight chance some textures might show up in a VRAM dump. Usually I only do this for sprite ripping and the like.
I wonder if 3D images are also stored in VRAM, simply waiting for a program capable of viewing them. Is anyone around here familiar enough with VRAM to know?
If the .iso could somehow be decompressed, we'd be able to get at everything - models, textures, animations, and all. Only problem is figuring out what compression routine Square used on this game. Bah, I should have majored in Computer Science after all. :x
-
Shouldn't be that far in. IIRC, somewhere on Gamefaqs is a save on Opassa Beach at the end of the game.
-
Maybe I won't have to try the VRAM out after all -- check out the .BIK file thread Zeality.
Though PSicture wasn't able to rip quite as many files from the disc 1 .BIKs as from the entire disc 1 iso taken as a whole.
-
Woah, interesting stuff. The unknown character seems to wear different cloths than Toma XIV; he wears an armor and is missing the hat. He looks kind of like an older version of Tata though; could it be him? How dramatic for us that the face is undrawn (not that it would help us identify him but...).
-
BREAKING NEWS
Click on the first image's URL to view. Didn't want to make 56k users suffer. Here's what I found in a VRAM dump taken during time spent in Termina...
http://img441.imageshack.us/img441/1940/example1zv5.jpg
First up, looks like we should be able to access the prerendered backgrounds, though they're choppy in VRAM. If we can get an army of VRAM explorers going, the Compendium could have "Rebuild Termina! Week" and "Rebuild Opassa Beach! Week," etc., and possibly use the building materials available to expand on these locales without having to take screenshot after screenshot. But maybe my idea of fun isn't compatible with everyone else's. :)
(http://img441.imageshack.us/img441/6499/example3nr3.jpg) (http://imageshack.us)
I wanted to post this dragon emblem thingy because I thought it looked cool. Don't worry about the color; I couldn't take the time to find the right scheme in the VRAM's color lookup table.
(http://img441.imageshack.us/img441/628/example5yw7.jpg) (http://imageshack.us)
OMG! Do you see Glenn's boot in that image? Do you see Glenn's boot!? Zeality, did PSicture grab that already, or is this slightly new? Perhaps we can get all of everyone's textures after all.
(http://img208.imageshack.us/img208/8241/example6da2.jpg) (http://imageshack.us)
Stuff PSicture already pulled, but in a nice sepia color because I didn't find the right position in the color lookup table (CLUT) quickly.
(http://img91.imageshack.us/img91/8259/example7po2.jpg) (http://imageshack.us)
Some random stuff. Just wanted to make sure we've already got all this through PSicture.
If anyone's interested in pursuing the fine art of ePSXe VRAM exploration and doesn't mind working with THE MOST USER-UNFRIENDLY PROGRAM EVER, then take a look at this thread at DragonTear.net for the tutorial from which I learned:
http://www.dragon-tear.net/forum/showpost.php?p=188751&postcount=23
And if I may insert a shameless plug, will everybody please, please oh please look at the .BIK file thread who hasn't done so already? I'm still on the fence as to whether it represents a Chrono Cross breakthrough or not, but it has proven quite tantalizing so far.
-
Craaap, another curse that I can't look at this until late tonight! I'm going to be thinking about it constantly for several hours.
Getting those prerendered backgrounds is a major coup. I guess this means that the blue / green picture in Lucca's house can't be magnified like the others, and will forever remain a low-resolution memory.
BUT FINALLY, LOCATIONS CAN BE ADDED TO THE ENCYCLOPEDIA! We can finally GRAPHICALLY explore and archive Chrono Cross to the point of perfection! Now I'm glad I didn't try and make a sacrificial effort to make a bunch of printscreen shots. We're really deconstructing the game here and it's paying off extreme dividends.
-
Zeality, if we can't find a way to rip backgrounds straight from the iso soon, I'd happily collect the "tiles" from Chrono Cross' various pre-rendered locations - maybe one location per week. It's really not too much work at all now that I'm practiced in VRAM dumping - a half hour every Saturday morning should be sufficient. We'll need several people willing to invest the time in assembling the locations, however, as that's the meat of the work to be done. Anyone who owns a copy of PaintShop Pro, Adobe Photoshop or another high-end image editing application would be a good candidate; I don't know about using Microsoft Paint, since I find it so unwieldy personally. I can provide reference screenshots for the assemblers of course, since those come with the VRAM dump anyway.
If we get a good system going, we can get all the locations without those pesky NPCs in the way of the scenery. Recruitment drive time?
-
I'll definitely take anything you throw at me. I've been putting together Termina as a proof of concept, and it's snapping together nicely. But some of the Termina data was omitted in the example, right? Because like the middle of Lisa's shop door is nowhere to be found...
Yep, that menu stuff and Glenn's model are in there. I'm guessing TIM files = all the dynamic textures. It explains why all the menu stuff, lighting, element effects, and battle textures are in there, yet nothing for the actual locations (except dynamic stuff in itself, like the computer / brain displays in Chronopolis).
Sooo, it looks like the main textures are stored somewhere else, perhaps in a different format. We might be able to extort some information out of Terminus Traduction (or Yazoo, who left them I think). They managed to rip and retranslate the entire script of Chrono Cross, so that means they know something about decompression. In fact, here's the utilities they used:
http://chronofan.com/Black/Other/Chrono_Cross_-_Translation_tools.zip
-
Don't know if this helps, but FF7 used MIM files for its field backgrounds, and I think FF8 also uses MIM files.
(MIM is some format Square made; QhimmWiki says it's a truncated TIM file.)
http://wiki.qhimm.com/PSX/TIM_file
-
Yeah Zeality, the Termina VRAM dump example I posted was just a taste. There's more to be had. I'll get a complete rip of Termina next Saturday morning unless we magically solve the .BIK conundrum before then and find everything in there. If you need it before next Saturday, though, for a site update or anything, I can shift my Hexadecimal exploration schedule to accomodate.
I'll be taking a look at those Chrono Cross tools as well. Thanks for the link.
Vehek, that's extremely helpful to know. You don't happen to have a .MIM on hand, do you? Or is there some way to tell what the hex would look like on a .MIM based on what's in the wiki? The Qhimm wiki gives some generalities about how many bytes to expect in a header, etc., etc., but I'd like to get a concrete example if possible.
-
http://wiki.qhimm.com/FF7/Field/MIMfile
Don't know if you saw that, but I'm posting it anyway.
I don't own the PSX version of FF7, so the only FF7 MIM files I have are from Q-gears (before they were removed to avoid copyright infringement.)
Hope there isn't too much trouble if I post it here as an attachment. It's compressed with LZSS compression.
[attachment deleted by admin]
-
Okay. Well, don't worry about it for now. If push comes to shove, that method is sure proof for mapping the entire game. However...to do it properly, we'd have to solve that room modifier code so we could make sure we've accessed every last room in the game.
Ah, so many new developments.
-
Thanks Vehek!
-
I'm going to try http://www.chronocompendium.com/Forums/index.php/topic,4187.msg72985.html#msg72985 again, and maybe pass it around the hacking community.
-
I'll get my ePSXe going with a Gameshark-compatible cheat program / plugin to make VRAM dumps of whatever otherwise-inaccessible locations you find, Zeality. And we could probably use the program to make background ripping quicker in general.
-
Maybe it's worth you guys looking for vertex arrays in vram/system ram of the emulator, you may just find model geometry. Just a thought, if theres tools to do it, the models will definitely be in the emulators ram somewhere, we just don't know what format.
Wrong thread I know but I could be worth a go.
-
Ooh, I like the sound of that jono. And I agree - why shouldn't model data be in VRAM, darnit? If I gave you a VRAM dump, do you think you'd be able to locate model data? I know I can't myself, haha. But that's definitely something I'd like to explore. We just need the right tools.
EDIT: ...Unless the models would be decompressed in VRAM if it turns out that they're compressed in the .iso. Then I suppose looking for model data in VRAM might be easier than looking for it in the CD data itself.
-
Sorry still wrong topic :)
I'll make sure this is my last post about modelling in the texture thread.
Even if we get exapmles of the model files, reverse engineering a model format would be very difficult, especialy if it is compressed and has a confusing animation format like ffvii models had. I think looking in system ram in an epsxe save state could be the way to go, I posted a bit more in depth about it in the model thread.
We'll hopefully get there eventually, I can't wait to finish uni this semester and have a really good look at this if it hasn't already been solved.
-
I'm going to tinker with the VRAM viewer. Did you guys see this? It's supposedly an emulator with a debugger built in. You're probably already aware of it, but:
http://www.romhacking.net/utils/311/
-
Oh-hoh-hoh-hoh. VERY nice find Zeality; no, I wasn't familiar with that emulator. That could at least point us in the right direction for model and other data, depending on whether the debugger tells where on the disc/iso it's pulling data from. I'll take a look at this later.
Yeah, once this semester is done for us all, we are so tearing Cross apart, and in a good way. :)
-
Took a good 30 minutes to put this together. It's the Dragon Tail Bar, attached. Putting those 128x16 tiles together is a little quirky, so I'll type out the rules for future reference. I've left the transparent areas white, but I've attached another "proper" version.
1. VRAM Viewer naturally lists about 4 columns of tiles. The map itself starts with the first tile and goes right as it looks at tiles down the column. Under OPTIMAL conditions, you could take the very first tile (upper left), place it, take the second (directly below the first, still on the leftmost column), place it to the right. Do this until you know you've reached the rightmost part of the map and start a new row. (For instance, the Dragon Tail Bar is five tiles wide; under optimal conditions, I'd just go down the columns placing five tiles per row).
2. Black space is the first quirk. At the top of inside maps is mostly black, and Cross skips texturing this. For the Dragon Tail Bar example, the top was almost totally transparent. However, above those chandeliers, there was some tiny, tiny light, meaning Cross went ahead and gave that uppermost row two tiles (as you can see in the image). You have to feel it out. So, for most inside maps, you usually can't just start plugging away left to right.
3. Doors and other openings also have transparent space. Instead of having a black texture, Cross just skips this (you can see the white space in the doorway). What you have to do in this case is break the tile in half, because once you hit the transparent space line, the graphics AFTER the space follow and won't line up with the rest of the map. So you have to copy and paste the portion after that transparent line to the right and line it up manually.
4. But this has a catch: at the end of the row, your final tile might have data intended for the left side of the map on it. Check out the bottom right portion of the Dragon Tail Bar: see those squares? They don't line up like the window because data for the left side of the map followed them, so I had to chop up the tiles and paste that stuff on the left side of the map where it belonged before continuing the new row they created with new, full tiles.
5. There may be other surprises. Play it conservatively, and zoom in as much as you can if needed to try and link up those hard to see light effects.
Now I just have to figure out what this other stuff is in the viewer.
Edit: I got it now. Looks like some of Termina's data is in there to the right...I'll post what I see in a minute so we can try and figure out what the viewer gives us in total.
[attachment deleted by admin]
-
Nice work Zeality! Are you using the VRAM viewer I referred to earlier with the DragonTear forum link, or have you found a better one? I'd really like to see something where the documentation isn't in Chinese.
And to take up more space with this post, I've got a question for people familiar with the inner workings of 2D image files. Let's say I have a .TIM file and a .BMP file showing the exact same picture. The file headers would be radically different I expect, but would the internal data be different as well? I'm asking in the hope that it might be possible to identify pre-rendered background data by hexadecimal strings regardless of the format, provided that background data is uncompressed in the .iso. The pre-rendered backgrounds are 2D images with invisible geometry overlaid, or am I understanding that wrong? And if so, I wonder if the overlaid geometry is included in the prerendered background file or stored separately.
-
Yeah, I'm using the one with the Chinese readme.
I'll post the full thing later so we can figure out every last thing the viewer shows us.
-
Zeality, I've done some exploration with PSMPlay (nightmare of a program!) and found lots of .TIM and .STR files. The .STR subject I'll save for another time and another thread, but I was wondering if you know offhand whether we've got the following images yet.
(http://img80.imageshack.us/img80/6274/randomtimsnq4.gif) (http://imageshack.us)
The upper ones are text windows. I wasn't sure we had accessed the little leaf and skull icons on the bottom of each of those images. We probably also have the Time Devourer's portrait (I'd forgotten it even had one). But is that a pre-rendered background image of Arni Village I'm seeing!? I have no idea why it would be stored / detected as a .TIM, and this is its natural image size, so it can't be blown up without becoming pixelated. I came across a very similar phenomenon with background graphics in Front Mission 3, where it seems that these little backdrops are either extraneous data that are perfectly meaningless or that the console/emulator somehow makes them bigger in-game without pixelation.
-
Unfortunately, that's the battle background image (and we do have those icons). For some reason, thumbnails like that are kept among the TIM data. So regrettably, PSMPlay isn't finding anything new...
But it's good that it can rip the STR files. Hopefully it can give us offsets for those.
-
Thanks for checking that out. I'm still having issues ripping pure .STRs (PSMPlay can detect them, but can't read or output them for some reason), but I've been able to get compressed STRs (.CSTRs) from PSXMc. The latter are still useful for tracing where the .STR data in Chrono Cross is, though the .CSTR files seem to have way different headers, which makes things icky. Using the .CSTRs will be my backup plan in case I'm totally unable to extract pure .STRs; I've got a thread on ROMHacking.net regarding the topic now, so I'm keeping my fingers Crossed.
*SPECIAL UPDATE EDIT*
Hey guys and gals, check this out. I've done a bit of experimenting with textures in the .iso, and I've found that replacing Kid's first clone texture (offsets 00B61800 ~ 00B65A20) with a totally black .TIM makes her map model disappear entirely but has no effect on her battle model. See below...
http://img258.imageshack.us/img258/6217/kidoverworldjm6.jpg
This is invisible Kid on a dungeon map. You can clearly see her shadow though. I expected Kid to turn a nice midnight hue, but the game may be interpreting all the 00 bytes in the black-colored .TIM as wiping the data away entirely. I'll try with a different color next time and see what happens. Also, I might have gone about this in a n00bish way; I think you're supposed to have TIMViewer or another program re-insert a texture, but I simply copied and pasted hex code from the black .TIM to the .iso. :mrgreen: That may make a difference.
But this tells us something perhaps - maybe all of the characters' textures are stored in those .TIMs we've gotten our hands on. I mean, I expected to see legs and shoes running around because those didn't seem to be present in the texture; but maybe the game does re-use parts of the texture all over character models. Either that, or screwing with the texture file made the game not even try to pull Kid's shoes out of wherever they should be elsewhere on the .iso.
http://img258.imageshack.us/img258/4571/kidbattleta9.jpg
And here's Kid in battle, perfectly normal. This means that the game's battle textures and dungeon/town map textures are stored separately. Thus, one of two things is true - either the clone textures we've pulled are used in different situations (perhaps one clone in battle, one on the overworld map, and one on dungeon maps) or we haven't even been able to pull in-battle textures yet. Only one way to find out - I'll replace all of Kid's textures in the .iso sometime.
Seeing this phenomenon kind of reminds me of that floor shadow that appears when Kid reads Lucca's letter. Is it possible there's actually a model for some kind of ghostly Janus in the .iso, but no texture was ever done so the model itself doesn't appear? Weird.
-
Yeah, black may not have been the best choice:
The red, green and blue samples behave like any RGB-defined color, but the STP (special transparency processing) bit has varying special meanings. Depending on the current transparency processing mode, it denotes if pixels of this color should be treated as transparent or not. If transparency processing is enabled, pixels of this color will be rendered transparent if the STP bit is set. A special case is black pixels (RGB 0,0,0), which by default are treated as transparent by the PlayStation unless the STP bit is set.
Above from http://wiki.qhimm.com/PSX/TIM_file (emphasis mine).
* Note that colors are 16-bit, with 5 each for red, green, and blue, and the last for alpha (transparency).
-
:lol: Thanks for confirming that, Luminaire. I'll go with a nice, soft blue next time.
-
After my insane-o tests are done later today, I'm going to open a savestate with VRAM and then in a hex editor. Using the menu TIMs and a character model TIM (the location tiles are shown between), I'm going to see if the graphics really are all together in one part of the savestate as they appear in the VRAM viewer. If it's true, then we can take the block between (the location tiles) and search them out through hex in the main ISO (or try to find a header).
Unfortunately, this won't work if the VRAM viewer is taking graphics from a lot of different parts of the savestate. But on the other hand, if that's true, we know the viewer has some way of recognizing MIM textures or their output.
-
Sounds good. That way we can also narrow down where model data might be in the savestate and in VRAM, if it is indeed in there. Too bad there isn't a VRAM utility to dump the data in its native format; I just take screenies of what appears in the viewer. Unless there's a dumping function I haven't found yet...
I'll continue playing around with character textures to test some of my own theories as to how things work.
Good luck on tests!
-
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.
-
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]
-
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?
-
Yeah, that's what irks me...maybe they're the same format as location maps.
-
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.
-
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.
-
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.
-
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)
-
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:
(http://img520.imageshack.us/img520/3333/glenntexesoz5.jpg) (http://imageshack.us)
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.
(http://img520.imageshack.us/img520/8082/bugtexle9.jpg) (http://imageshack.us)
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.
-
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.
-
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.
-
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.
-
PSXMultiripper produces 13000+ textures, so maybe there's some extra stuff in there we haven't uncovered yet.
[attachment deleted by admin]
-
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.
-
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.
-
A while back at romhacking.net, Cyberman suggested that Xenogears and Chrono Cross might have similar file structures.
http://wiki.qhimm.com/Xeno/IndexFileFormat
Do you think this will help?
-
This could be a major breakthrough; Chrono Cross definitely seems to have the same deal, what with the SLUS file and SYSTEM.CNF being the only things Windows can see.
I'll see if I can't rip some hex strings from the iso based on that wiki tonight. Others are welcome to try before I get to it, of course. Any ideas on what we would view a Table of Contents with? Just throw it into Notepad, maybe? Terminus Traductions' notes will help here.
EDIT: Before I try to find Chrono Cross' index file, I'm going to try it with Xenogears first so I can get a sense of what I'm looking for. According to the info Vehek posted above, Xeno's index file starts on the 24th disc sector and is 16 sectors long. I *think* that means it should start on offset DC80 assuming each sector is 2352 bytes long (i.e., 2352 * 24 -> Hex). Can anyone tell me if my understanding of the qhimm wiki entry Vehek posted is correct? I'll see if I can register at qhimm too and ask there for advice.
EDIT: Oh-hoh-hoh. It seems the disc sectors in Xenogears are 2048 bytes long, not 2352 (which I thought was the iso standard). If 2048 is the magic number, then everything seems to be shaping up with what's in the qhimm wiki reference on Xeno. That makes the index file's starting offset in Xenogears C000, BTW. Not sure what it'll be in Cross, though the PlayStation logo model is stored at the same offset in both Cross and Xeno.
Anyone familiar enough with disc sectors to tell me if 2048 sounds like a reasonable number of bytes per sector on a PlayStation CD, and if it's likely that Cross has the same number of bytes per sector?
IMPORTANT EDIT
Okay, I've attached what I think is the Xenogears index file. I didn't put a file extension on it yet; it's raw hex. I'll leave it with the Community for a few hours to ponder how this can be viewed (as a .dat file, perhaps?) I'll return to the matter once I get a few things done outside the Chrono world.
If this works, then I'll move onto Cross and see if I can find a similar index file.
[attachment deleted by admin]
-
Ooh, before I forget -
The file above has a very long string of 00 bytes I find suspicious at the tail end of it; I'm not sure if that would affect our ability to view it or not. So if anyone wants to investigate before I return to it, feel free to shave that off the end of the file if nothing seems to work.
EDIT: Tried opening it in notepad under various conditions, but no go.
-
Probably not the reply you're looking for at the moment...
I've determined that arranging the layer one stuff is ridiculously futile. I'll still make Perfect and Complete versions of each map, but the Complete image will now feature the layer one stuff as it appears in the VRAM viewer. While arranging it isn't TOO difficult, it is time-consuming because a lot of that stuff is very dark and it can take a lot of guesswork to align it correctly.
Anyway, here are the Complete and Perfect versions of one of Cross's most famous scenes:
[attachment deleted by admin]
-
I'd forgotten just how beautiful Cross' environments could be. Brings a tear to my eye. Er, well, almost. Nice work as always, Zeality. I wonder if the separate layers for each environment are stored as different files on the Cross CD? That would be sweet if so, because it would allow for slightly different or expanded environments to be made once the Compendium gets to the point of Cross fangames and hacks.
I'm not going to have time to join in on the VRAM dumping frenzy this weekend after all, unfortunately. Anyone who'd like to recapture Cross environments like what Zeality's doing, please see the tutorial on DragonTear.net. I've linked to it already in this thread, but here it is again: http://www.dragon-tear.net/forum/showpost.php?p=188751&postcount=23
In other news, I'm attaching a hex string that might just be the Chrono Cross table of contents. It is significantly different from its Xenogears counterpart; for one thing, it's only 13 sectors long as opposed to 16, and secondly, the byte repeat pattern* happens every four bytes as opposed to every seven bytes. But I believe it may be what we're looking for.
Still no idea on how to open it. I'm still awaiting an account confirmation email from qhimm.com; I think it doesn't like Yahoo. If anyone has an account at qhimm, please inquire there as to how one would go about viewing a Table of Contents / Index file from a Playstation CD.
*Byte repeat pattern: My term for a repetitious pattern within a hex string. For example, a four-byte repeat pattern might look like @...@v..@...@...zd..zx..z, etc, in ASCII. Not completely consistent, but the pattern is still obvious. I'm not quite sure what it means, exactly, other than that the hex string looks interesting.
[attachment deleted by admin]
-
Yeah, it doesn't like your Yahoo. I just registered with my Gmail account, and will proceed to post about it.
I also threw out an update of what we're doing on Gamefaqs's Cross board.
-
Thanks for that Zeality. I'm posting about it on xentax and I'll also toss these at Romhacking.net for what it's worth.
-
http://forums.qhimm.com/index.php?topic=7133.0
-
Beautiful. Many thanks, Zeality. My threads at xentax and romhacking.net are the same as always:
http://forum.xentax.com/viewtopic.php?p=23412#23412
http://www.romhacking.net/forum/index.php/topic,4829.0.html
Hopefully something very, very good will come of all this.
-
Interesting. The demo disc has the demos in different folders. Chrono Cross's (folder is named Kid) has this in it:
KID.EXE
CRONO.HED
CROCRO.IMG
TITLE.XAM
BLOOD.XAM
TIDAL.XAM
END.DAT
Anyone know what the hell these are? I tried mounting Crocro.img as a CD, but I could not browse it. Kid.exe just terminates, of course.
-
Looks extremely interesting. Now, the demo has gameplay and not just video in it, right? I wonder if some of these same files might be on the final. Are any of them small enough to attach, or are they all very large?
-
I'll upload tomorrow and edit this post (it'll display the "New" icon on the kajar Labs thread listing). The XAMs are 6 mb each, and then a 16 mb one's in there. The HED is only 30 kb, and the END.dat is like 3 bytes. Crocro.img is 101 MB, and KID.EXE is 1.89 mb.
-
Anybody read/speak Italian here? I've been directed to this site:
http://www.sadnescity.it/utilita.php
by Akari at the qhimm forums. I'm going to try out their program TOC Changer, but I'd be interested to know what their documentation on the program says.
EDIT: Okay, forget that. It appears TOC Changer only changes the Table of Conents file and doesn't view it. Go me. :roll:
Anyway, here's a guide in Italian that might prove useful:
http://www.romhacking.it/downloads/guide/saffo/modifica_toc.pdf
The author, Sephiroth 1311, has also posted in English at romhacking.net, so hopefully he'll be a huge help in this area. We're coming along, folks!
-
Damn, I can't copy those XAM files from the CD-ROM for some reason. I get "Invalid MS-DOS function".
The others:
http://chronofan.com/Black/Cross/CRONO.HED
http://chronofan.com/Black/Cross/END.DAT
http://chronofan.com/Black/Cross/KID.EXE
And of course, there's still CROCRO.IMG, but I haven't uploaded it. Maybe it'd be easy to find a comparable TOC on a small demo file like this?
-
I shall take a look at those, Zeality, and see if they're in the final version. Even if the same file's different in the final version, I should be able to detect its existence by looking for the header's hex signature.
I think I've got enough source material for the folks at various other forums to look at regarding the Chrono Cross TOC. I'm not sure where it would be on the demo; my guess is it might start at offset C000 of the full demo iso just as with Xenogears and Chrono Cross.
BTW, http://www.sadnescity.it/ has a whole forum subsection devoted to Cross. Woe unto me that my Spanish isn't helping me out too much with the Italian, or I'd ask there too. EDIT: They've got an English forum, though it doesn't look all that active. I've started a thread there; we'll see if we get any help from Italy: http://lnx.sadnescity.it/forum/index.php?topic=66.msg351#msg351
EDIT: There's an EXE similar to KID.EXE on the final, starting at offset 13000 (for my own information - I'll map it). I wonder if CRONO.HED might be an index file; I say that only because of the strong byte repeat pattern I'm seeing when I view it in hex.
Actually, while doing a bit of exploration regarding KID.EXE, I found a section of the final iso that reads in ASCII:
(http://img143.imageshack.us/img143/9891/image1vw0.gif) (http://imageshack.us)
Offsets 1F0320 ~ 1F036F. Maybe this is referring to file archives in the iso? Do the extensions .WAA, .WEP, or .KMD look familiar to anyone?
-
Argh, it's another post with no good news for cracking the file structure.
Anyway, I think I got the room modifier working. The results I'm getting don't correspond to that weird guy's notes, but oh well. I contacted the guy who hacked the code on the GSHI forum to see if he remembered any extra information.
Hopefully I'll find a debug room or something.
-
:shock:
And so you did. Self-fulfilling prophecy time!
In a moment of beautiful, beautiful mental clarity, I re-discovered a .zip file called "cctools" that's been sitting in a folder on my desktop since two days ago. It has a .txt file called "Main Disk Dump"!! :shock: :shock:
It says: "Dump the complete content of Chrono Chross CD1/CD2 US and Japanese version"
Then it's got a bunch of Computer Science speak, and I'm an economist, so --
I'm attaching the .txt to this post b/c I'd like some confirmation as to whether the code contained within is C/C++ and if anyone knows of a good compiler if that's the case. This might just save us a lot of work!
EDIT: Actually, its a .CCP file, not txt. And if it works, we owe it to the great Yazoo, wherever he is.
EDIT: Oh, it is C/C++, I think. Anyone know of an appropriate compiler for the code contained within?
[attachment deleted by admin]
-
I am pretty well versed in C/C++, so I downloaded cctools from romhacking.net and have been trying to compile it in Visual Studio for ~15 minutes without success. It looks like someone will need to go through and clean up the code first, which I will try to work on when I can. Even if we can't get it compiled, there may still be useful information about the structure of the ISO in the cctools source code that we can exploit.
If you want to try it, there are two free IDEs/compilers I can suggest: Dev-C++ (http://www.bloodshed.net/dev/devcpp.html) and MS Visual Studio Express (http://msdn2.microsoft.com/en-us/express/default.aspx).
-
I made a few minor edits so it uses the "chrono.iso" file in the same folder that you run the program and places the dumped output there too... OR you can also run it from the commandline with the filename of the ISO image as the first argument.
Other than that, I only skimmed the source, but it should make a bunch of folders containing numbered ".out" files from the files in the ISO along with an index file.
[attachment deleted by admin]
-
Thanks for compiling! I'm trying it out now, Ramsus. Tells me I've got an invalid iso file, so I'll try re-ripping and see if the results are different.
I'm attaching other tools that look interesting; decompression routines and such that Yazoo apparently used. These will come in handy for viewing a lot of the files. Maybe you and Luminaire can take a look at the code in these as well?
EDIT: My guess is it's the way I ripped my iso. I'll try various methods till something works.
[attachment deleted by admin]
-
It's still dumping. Interestingly, I fed a .bin rip into it and not an .iso rip, and it worked. BUT - we'll still have to see if the files are viewable, or if I did a bad thing. I'll attach examples of each file type here once it stops.
EDIT: Blarrgh, I've no clue where all the output went. Anyone else willing to give it a try? I'm using Ramsus' modified code attached to his post.
EDIT: I see I've got 336 bytes of .OUT files sitting on my C:\ drive. When I open them up, they tell me:
"It's CDMAKE, Dummy !"
Gee, thanks, Yazoo. :lol:
Anyone have an idea as to how it's supposed to work? I'm attaching the entire cctools for people to view; keep in mind Ramsus has compiled a modified version of the dumper.
[attachment deleted by admin]
-
If you ran it in the C drive, then it's probably in c:\disk1 or just in c:\. Sorry about that.
Anyway, here's an update with source.
[attachment deleted by admin]
-
You da man, Ramsus. All I've got in that location are the .OUT files, but I'm going to try with a real .iso file this time and see if I get all the files.
-
It's still dumping. Interestingly, I fed a .bin rip into it and not an .iso rip, and it worked. BUT - we'll still have to see if the files are viewable, or if I did a bad thing. I'll attach examples of each file type here once it stops.
EDIT: Blarrgh, I've no clue where all the output went. Anyone else willing to give it a try? I'm using Ramsus' modified code attached to his post.
EDIT: I see I've got 336 bytes of .OUT files sitting on my C:\ drive. When I open them up, they tell me:
"It's CDMAKE, Dummy !"
Gee, thanks, Yazoo. :lol:
Anyone have an idea as to how it's supposed to work? I'm attaching the entire cctools for people to view; keep in mind Ramsus has compiled a modified version of the dumper.
What do you mean? That string isn't anywhere in the source, and it's probably not in the ISO.
Also, try converting it to an actual ISO image first. The code doesn't have a lot of error detection, so you could feed it anything about the right file size and it'll probably look like it's working until it's finished.
-
Still getting an invalid iso warning when I rip to iso. The corresponding C++ code is this, I think:
if (check_iso(f_iso)==1)
{
fclose(f_iso);
printf("Warning:INVALID CHRONO CROSS ISO FILE!!!\n");
printf("Make sure you are using a Genuine Chrono Cross CD1 iso.");
}
Does the (check_iso(f_iso)==1) argument tell me anything about what the expected iso should look like, Ramsus?
-
It should be 736651104 bytes long. What's it say when you run the program?
EDIT: And yes, it's just a length check.
-
My iso is 641,437,696 bytes in length. When I rip it to .bin, I get the right size (736,651,104 bytes) though and it goes through - it's just that it doesn't produce any files other than the .OUTs in C:\Disk 1
I'm running it on my .bin again to double-check, and it says things like "dumped file number yyyy", so it should be producing the files, no? Maybe they're getting stuck somewhere else on my PC other than C:\Disk 1?
Oh, and I'll try converting my .bin to iso once that's done. Is there a certain program you'd recommend for that, or should I just rename it to a .iso extension?
-
Delete those and try running the new dump.exe in the latest attachment. It should create a subfolder in the current folder.
EDIT: And after you do that, post a random selection of the resulting .OUT files from different folders. Also report as to the complete file structure (i.e. does it make folders, what the filenames are, etc.) and look for a ".tbl" file and attach that too.
EDIT2: And if you can't find the output, make sure you've deleted all of the old stuff first, then use the Windows Search function for anything with a .OUT extension.
Also, file extensions don't matter to computers. The "BIN" you're using might actually be in the right format (i.e. it might be an ISO, or at least, the "ISO" Yazoo used), based on the size, but it's hard to say without checksums. Simply renaming it won't "convert" anything, and since the actual ISO you mentioned is the wrong size, we'll have to assume the BIN is probably what we want.
On a similar note, the program is supposed to produce ".OUT" files, but whether or not they have the right contents and what filetype they are is totally dependent on having the same exact input file that Yazoo used.
-
Hm, the new dump.exe gets only so far before crashing; pic below.
http://img148.imageshack.us/img148/3673/image1he6.gif
I'm a Windows XP, Service Pack 2 user BTW. That doesn't make a difference, does it?
-
Hm, the new dump.exe gets only so far before crashing; pic below.
http://img148.imageshack.us/img148/3673/image1he6.gif
I'm a Windows XP, Service Pack 2 user BTW. That doesn't make a difference, does it?
Probably a buffer overflow with making the filename strings. Try this.
EDIT: Also, sorry to leave you hanging, but it's brunch time. If it still doesn't work, run the original working copy and analyze/post the results like I described in my previous post. When I come back, I'll try to figure it out.
[attachment deleted by admin]
-
Will do; thanks!
-
I got dump.exe to run on a Disk 1 "bin" (although it's 736,651,104 bytes also). It produced a bunch of files in the same directory as dump.exe since I put the Disk 1 file in the same location. Also, I called it from the command prompt using the command `dump.exe ccdisk1.bin`.
It created folders BF, BS, CD, CF, CTF, MISC, OAM, OMCM, Rooms, ROT, SCL, V, WF in the directory where dump.exe and ccdisk1.bin are located. In each of these is a single folder named disk1, and the .out files are within these disk1 subfolders. Each .out file has a 4-digit filename; my guess is this is based on where in the iso/bin it was found. There is also a file.tbl file in the top directory, which I have attached along with the first .out file in each folder*. I have also preserved the folder structure in the attached file.
*I left out the .out file in the V/disk1 directory because it was 1300 KB in size. Based on what dump.exe said and the size of the .out files I think "V" stands for video.
[attachment deleted by admin]
-
YEAH!! :lee:
When I looked for those folders I found them laying in a directory I didn't expect; thanks for telling me what to look out for! We've got'em.
LET IT BE KNOWN FROM THIS DAY FORTH: THAT ON SUNDAY, OCTOBER 21, AROUND 2:00PM OHIO TIME, RAMSUS, LUMINAIRE85, AND FAUSTWOLF BLEW CHRONO CROSS WIDE OPEN THANKS TO TOOLS CREATED BY YAZOO OF TERMINUS TRADUCTIONS.
Now we'll need to assess which files are what type and how to use the various decompressors.
:D THANX RAMSUS AND LUMINAIRE! :D
With this and the debug room Zeality discovered, 'tis a good day for Cross fandom.
I've gotta do some things outside the Chrono world all this week, so I'll not get a chance to look at this stuff too in-depth for awhile.
-
BTW, Luminaire, did you use Ramsus' first corrected version of dump.exe? I couldn't get the second or third versions to work for me without crashing.
-
Guys, guys, make sure that what it dumped aren't just the scripts!
-
Yeah, I used the original dump.exe that Ramsus posted. I've been following the discussion since I posted before, but I've been distracted so I've always been a step behind you guys.
I should point out that there's 605 MB of data in these .out files. And that's just disk 1.
-
Yeah, its 605MB, so it's not just scripts. I think...
Zeality, check your PMs for my cursory findings so far.
-
(http://miiplaza.net/imgcache/t17-640-480-scale-1165793325868.jpeg)
YEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHH
(http://chronofan.com/Zeality/First_Strike____Initial_Lotus.jpg)
(http://chronofan.com/Zeality/laguna.png)
(http://chronofan.com/Zeality/rockthis2.gif)
(http://chronofan.com/Zeality/rufustrans.png)
(http://chronofan.com/Zeality/Zell2.png)
-
The script is probably in there somewhere, but here's a breakdown of what it's supposed to be:
BF = 2415-2513 BattleFields
BS = 2543-3054 Battlescript
CD = 75- 125 Character Descriptions
CF = 25- 74 Character Faces
CTF = 1993-2084 Character talking face
MISC = 0- 24 Misc
MISC = 179- 185 Misc
MISC = 190- 203 Misc
MISC = 332- 355 Misc
MISC = 1967-1977 Misc
MISC = 2085-2416 Misc
MISC = 2514-2542 Misc
MISC = 3054-3707 Misc
MISC = 3760-5597 Misc
OAM = 322- 331 OverWorld Alternate Models
OMCM = 204- 321 OverWorld Main Characters Models
ROT = 126- 178 Rare objects TIM
ROT = 186- 189 Rare objects TIM
Rooms = 356-1966 Rooms
SCL = 3708-3759 Small Character Layer
WF = 1978-1992 Windows frame
V = 5598-5918 Video
The numbers just correspond to the order of the files on the disc (so there should be 5619 files starting at file 0). When I have an ISO to work with I'll go back over the code and compare it to the data and double-check/possibly fix/improve a few things.
-
Compendium life without Ramsus would be impossible! All riiiiiight. I'm still plagued with coursework, but rest assured, I will rush out an update later tonight based on the findings of this afternoon. I'm also going to test the method I used to access the Hydra Marshes and get that debug menu to see if we can replicate it.
I spoke to LiquidManZero, who hacked the room modifier code. It's been a long time, but he did give us some suggestions for debugging emulation tools (if we still have a need).
http://psxemulator.gazaxian.com/
http://www.romhacking.net/?category=&Platform=17&game=&author=&os=&level=&perpage=20&page=utilities&utilsearch=Go&title=&desc=
-
From the samples, I'd say it worked.
To Luminaire: Please install hashtab (http://beeblebrox.org/hashtab/), then right click your ISOs and check the Properties. Go to the "File Hashes" tab and post the MD5 and SHA1 hashes of your ISOs.
-
Ramsus, would you be able to take a look at Yazoo's decompressors for these files when you've got some spare time? I've attached all his tools here. BTW, what compiler are you using? I've been having the worst time with the .CPP scripts Yazoo made for some reason.
Oh, and, ahem...
(http://img143.imageshack.us/img143/7264/image1zn8.gif) (http://imageshack.us)
EDIT: For what it's worth, I've got some hash checks for the Disc 1 .bin file I used for the dump:
MD5: 3B29EE931DF29F51ECF0817F30E103D7
SHA1: 91CE7726D264111C068A0BEE89784F6EBD42AC54
I've also got hash checks for the Disc 1 .iso that failed to work because it's the wrong file size for Yazoo's dumper:
MD5: 8A20EEA3B210A92AD38B7E823A1BB5EF
SHA1: F5A69127713F4290791AD6E9FE9FC46D88F80AEA
[attachment deleted by admin]
-
Disc 1:
MD5 = 1205C5FFD905D42278AE399A23360405
SHA1 = 22906F9A2FD102FEE62CDC7389B26EC6F51DEE56
Disc 2:
MD5 = 6463D040AAE5156AC146D34402A7988D
SHA1 = 0AD65D093B36AE9ECF02AA9ABB15952503CB5ADF
-
Does it matter that our hashes are so different, Luminaire, or does the hash signature vary with each copy of a file?
-
I'm using the Digital Mars C, C++, and D compilers.
Yazoo's code should just work as C++. He was aiming for plain ANSI C, but there's a few syntax and feature differences he missed since he was using a C++ compiler. Anyway, since he avoided using any C++ stuff, his code should pretty much work as is (Fortunate for us too, because C++ had a lot of feature/syntax/library changes several years back, and so new major compiler releases are always breaking old code, especially on other platforms, and it took forever for programmers and software books to catch up to the new standards...).
When I get an ISO to play with, I'll run through the code and fix any loose ends and make the code more portable and reliable, as well as buildable in any C89 compiler. I'll also probably use Luminaire's checksums to determine whether or not the right file is used and which disc it is.
FaustWalf: If two files have the same contents, the hashes should match. That's what hashes are used for. It seems that Luminaire has the same format and version of the games that Yazoo had, and that your copy is different.
-
I wonder if that's related to the fact that FaustWolf dumped his as Extract Image (Content) rather than (Raw), which I'm assuming Luminaire did (although...my assumption could be dead wrong).
I wonder what the difference is between those, anyway. Raw produces screwed up TIMs, so maybe raw is somehow interleaved?
-
I wonder if that's related to the fact that FaustWolf dumped his as Extract Image (Content) rather than (Raw), which I'm assuming Luminaire did (although...my assumption could be dead wrong).
I wonder what the difference is between those, anyway. Raw produces screwed up TIMs, so maybe raw is somehow interleaved?
What software are these options in reference to? If I can track it down and figure it out, I might be able to write a converter, or modify the dump program to work on the other type as well.
That might also mean the TIMs extracted by the dump program might be screwed up, since it works on the RAW version of the ISO. You'll have to check Luminaire's output files yourself, since I don't have a TIM viewer. There should be some under character faces.
Later I'll add some magic filetype detection support that can give some of the files the correct file extension, but for now just try the obvious once (like character faces).
-
For my own part, I use IsoBuster. The .bin file I ripped was produced through "Extract CD <Image> -> RAW", whereas the iso was produced through "Extract CD <Content> -> Extract User Data". There's also other ripping options in IsoBuster, but I'm not familiar with them.
Since the .bin method messes up the dynamic .TIM textures, I'm kinda worried about how the results will turn out since we used .bins with your updtated dumper. But maybe it turned out okay; no way to tell for sure until I do some hex checking and see if I can find some way to view the various .OUT files.
EDIT: I'm doing some scans with PSicture...BRB.
EDIT: The results are B-E-A-U-T-I-F-U-L!
BF contains scannable image data. Various textures, not screwy, not sure we've got them all. And there's a 2D snapshot of Kid's character model in here.
BS contains no scannable image data.
CD contains scannable image data - eye textures.
CF contains the long character portraits. They're broken in half though. Zeality, is that the way things were to begin with?
CTF contains character face portraits. Not screwy.
MISC produced some stuff but makes PSicture crash. :shock:
OAM contains three dynamic character textures - two cats and one Acacia soldier I think. Not screwy, but not sure why PSicture isn't seeing the others.
OMCM has more dynamic textures.
Rooms has the rest of our textures, oddly enough. Though I worry about the unseemly number of "Invalid files" contained within. But PSXMultiripper gave me the same kind of .TIM files too, so maybe there's no incongruity here at all.
ROT has the rare objects, as can be expected.
SCL contains the full character portraits, assembled this time.
V has no scannable images, but that's because it should only contain the .SRT vids.
WF is just the window frames, as Ramsus has already surmised.
In short, I can't confirm that we've got everything, but I can confirm that what we have is in good shape.
-
I checked the headers of a few of Luminaire's samples earlier, and some are TIM files. I suggest trying to open them and posting the results. Also, File 0000.out is the game's executable binary (or at least the first part of it). I don't know much about PSX development, but a MIPS pro could probably use that as a starting point to reverse engineer the game's code.
And lastly, there should be a lot of other files that go in MISC that probably come in a variety of formats that Yazoo just didn't have time or the interest to identify. There might even be 3D models in there somewhere, so definitely check it out.
-
Yeah, I just used the CD image I had "acquired" from long ago, so I don't really know which way it was made.
EDIT: I downloaded PSicture and looked at a random sampling of the .out/.tim files, including some of the character model textures, and they don't appear to be scrambled at all. Maybe I do have a "good" iso. :)
-
My guess is that Yazoo's dumper corrects for the junk data that gets put into the iso/bin when it's ripped a certain way. That would explain why we're only getting 605MB versus our 700+MB .bin files -- the dumper cuts out 100+MB of junk data that's injected during the ripping process.
EDIT: Er, waitaminute -- I'm not sure I ever asked you Luminaire, are you using a .bin or an .iso? I've got a .bin that's 700+MB. Maybe you've got an .iso that's the same size, and our hashes are different because the two disc images were ripped in different ways?
-
I am using CD images labeled as .bin (there's .cue files with them too), but the images are >700 MB.
-
The length is the same, but there's something different with the arrangement inside. Whatever the case, Luminaire's images probably match what Yazoo used, so I'll use his checksum as the "correct" checksum. I suggest trying to rip images with different options and different formats until we find out how to get an image with a checksum that match's his.
-
How weird. I should go back and reread all this to grasp the logic.
Anyway, yeah, the main character images are broken in half. For some reason, there are a second set of identical but smaller menu images. No idea where those are used.
-
Yeah, it's odd. I've got a .bin with the same file size as Luminaire's but a different hash. Whatever - as long as we've got all the files, that's what matters. I'll do some different rips during the week and see what I come up with.
-
I wouldn't worry about the images. I checked and ImageMagick handles the TIMs correctly. If other programs aren't, then it's probably just a variation they aren't able to handle right now. Later I'll write a script to auto-convert them to our format of choice using ImageMagick's library.
[attachment deleted by admin]
-
The other two...
[attachment deleted by admin]
-
Also, here are some compiled versions of those cctools. The filenames are hardcoded, and the setup that Yazoo seemed to use was:
Somefolder (name it Cross):
Cross\iso\ <- This folder had the iso files in it. Name the one you want to extract cd1.iso
Cross\cctools\ <- This has the .exe files in it.
Cross\WHATEVER\disk1 <- This is where the dump program extracts everything, where WHATEVER is MISC, V, WF, CTF, etc. depending on the type of file.
Then you just run the programs from Cross\cctools. This way, once you extract everything, the other programs should be able to find the extracted files without modification.
Also, since I don't have a copy of the game, I can't test these tools for bugs, so be warned. Later, when I get a copy, I'll go back and be able to test everything and debug stuff, so just be patient.
EDIT: Also, there's a missing source file that was originally named lzss-dec.cpp. Maybe Yazoo never got around to writing it, but then that means the Room-decompressor program was never finished. Either that, or it got lost somewhere.
EDIT2: I'll probably start work on this stuff next weekend when I'm up in San Francisco. Post as many problems/requests as you can before then, and explore as many of the files as possible. I'll also try to look up information on possible file formats used and try to "auto-detect" them and give the correct extensions where possible.
[attachment deleted by admin]
-
I wonder what all these other decompression .exes are. I hope they're in English.
I'm dumping the contents myself now for exploration. I'll sick TIMViewer on everything if I can and see if it generates the same amount of unique TIMs as it does when used on an ISO.
Yeah, sounds pretty redundant, but I've become obsessive.
-
Can anyone get PSXMC or PSMPlay to play the video files? PSXMC isn't taking them.
Edit: WOW! The battle fields have all the images organized BY location within each .OUT file. This is...this is beautiful. Now I can make a new TIM texture pack and PROPERLY organize them.
-
@Ramsus: Thanks for compiling those!
@Zeality: I'm going to do some hex comparisons between the video files dump.exe produced and the .STRs I ripped recently with PSXMedia Player (updated version of PSMPlay). I already know that the video .OUTs are 30MB less in size altogether than the .STRs. However, this isn't necessarily a problem at all, because PSXMediaPlayer's rip function seemed to stuff some extra gobbledegook in toward the end of the files. I'll report my findings when I've checked them out. It's possible there's an .OUT file header of some sort perhaps that prevens the PSX movie players from recognizing the .STR files.
-
Okay. And I guess the general idea is that main_disc_dump.exe uses the other .exes to dump particular assets right? So if some of the other .exes are flawed, we won't get the entire thing?
-
Okay. And I guess the general idea is that main_disc_dump.exe uses the other .exes to dump particular assets right? So if some of the other .exes are flawed, we won't get the entire thing?
No. They're all separate programs. First you extract all the files with main_disc_dump.exe. main_disc_dump.exe is standalone, independent, and by itself 100% complete. Anyway, doing that creates the filetree that the other programs use to do their thing.
That is, all the other programs are written with the assumption that you already ripped all the CD files out use those OUT files to generate decrypted or decompressed versions that you can further work with.
-
To be more simple and clear:
The main_disk_dump.exe program extracts everything, but some of the files are compressed/encrypted. You can unencrypt and decompress them using the other programs so you can work with them, and also do the reverse in order to reinsert them.
-
It's possible there's an .OUT file header of some sort perhaps that prevents the PSX movie players from recognizing the .STR files.
Yeah, they have a non-standard header, so PSM Play can't detect the format when reading from an actual file instead of scanning the whole iso. I had to make a custom application just for handling that stupid format (used in Legend of Mana, too). >_> Here a picture of the tool:
(http://img153.imageshack.us/img153/7249/immagine3qo6.png)
Also, iirc, you guys mentioned the room TIM files, some of which seems corrupted of something. Yazoo's tools use an incorrect method of detection, so it dumps are .TIM or .RAW completely random. Some of them are just simple TIMs, other are clut-less TIMs, and the rest are compressed images. I made a tool for those, too, but it's totally incomplete and can only open the clut-less TIMs (no editor supports them correctly for some reason). Here an image of this tool:
(http://img153.imageshack.us/img153/9339/immagine5jq8.png)
If you need any addition info about the file formats, I can give you a hand, otherwise never mind. :D
-
Thanks for confirmation on the .STR headers, Gemini. The Ramsus/Yazoo dumper seems to cut the .STRs directly from the disc image, but PSMPlayer doesn't recognize raw .STRs. Just for my own curiosity, do you know how PSMPlay and other programs are able to detect the .STRs when it's actually scanning the entire disc image? Does it need the Table of Contents to detect the STRs or something?
And I'm very interested in that tool you made that supports the CLUT-less TIM files. Have you taken a look through the Compendium's texture pack that Zeality made? The image you've posted strikes me as if it might be part of a pre-rendered background, which we haven't been able to capture with either PSicture or TIMViewer.
And BTW Gemini, could you tell us the file size of the CD image you ripped that CLUT-less TIM from? We've had problems with the images being split if we rip our iso/bins a certain way, and I'm wondering if we can get that image you posted any clearer if we use your utility on a differently-ripped CD image.
So many questions, but thanks for any answers you provide Gemini!
-
Does it need the Table of Contents to detect the STRs or something?
I dunno why it doesn't work correctly with an actual file, but it must be using part of the sector header+subheader in the iso while scanning. The actual movie file doesn't contain any of those segments.
The image you've posted strikes me as if it might be part of a pre-rendered background, which we haven't been able to capture with either PSicture or TIMViewer.
Well, it IS part of a background. It is the teleport room in the Ancient Fort of the Dragons in Serge's dream, to be exact.
And BTW Gemini, could you tell us the file size of the CD image you ripped that CLUT-less TIM from?
Size doesn't matter in this case. My ISO size doesn't match at all Yazoo's, and yet I can extract, change content and reinsert everything fine. Just rip the ISO with Alcohol 120% or CD-R Win.
-
If you need any addition info about the file formats, I can give you a hand, otherwise never mind. :D
Could you post everything you know? I know jack squat about the PSX and PSX games, and I'm not even really involved in this project, so experienced people are more than welcome to join in.
-
Well, judging from the toher thread, we really need to get this dumper working:
http://chronofan.com/Black/Other/Chrono_Cross_-_Translation_tools.zip
It probably works better than Yazoo's, now that FaustWolf has found bad .TIM files. Once that's done, we can see what we have.
I'm VERY interested in a way to view the prerendered background images. Right now, the only way to get them is to make savestates in all the areas and use VRAM viewer. If we could just extract them normally, we might even find unused textures and other weird stuff.
-
Yes Gemini, post everything you've got. Including that CLUT-less TIM viewer you programmed, if you don't mind; if it rips and views pre-rendered backgrounds, it is officially amazing.
-
Yes Gemini, post everything you've got. Including that CLUT-less TIM viewer you programmed, if you don't mind; if it rips and views pre-rendered backgrounds, it is officially amazing.
Sorry, but I don't usually release any of my WIP programs. As for the information I've got, I don't have any notes on them, so trying to write a mini-doc with all the stuff I know would be quite difficult, not to mention that I'm totally lazy at writing anything. If you want you can still ask questions to me, I won't deny an answer.
It probably works better than Yazoo's, now that FaustWolf has found bad .TIM files.
Those are not bad TIMs. Some are just compressed, that's all.
-
Sorry, but I don't usually release any of my WIP programs. As for the information I've got, I don't have any notes on them, so trying to write a mini-doc with all the stuff I know would be quite difficult, not to mention that I'm totally lazy at writing anything. If you want you can still ask questions to me, I won't deny an answer.
Do you release your programs once they're finished? In any case, your decision is fully respected.
And take a look at the CHRONO CROSS FILE EXPLORATION THREAD; I've got a question for you there.
Thanks Gemini!
-
Do you release your programs once they're finished?
Yep, I do, but this is not the case. That program was created just for MFC practice and I haven't been working on it for almost 2 years now. I really don't have any interest in finishing it.
-
Would it be possible to use these texture in a 3D program (say, Maya?) if so, I think I'm going to have a field day.
-
What format do you need them in, Nightmare? I'm giving them to Zeality in .BMP format, so I hope that'll do.
EDIT: Ripping done. Thanks Gemini for paving the way!
Zeality will probably release the new textures as a Compendium download, so stay tuned.
Now this opens up another can of worms: where's the battle textures for Dark Serge, the Mystics, the Time Devourer, etc. etc.? Could it be that enemies simply use the textures we've already ripped via PSicture and TIMViewer?
-
Hey Gemini, do you have any info about the file format the CLUT-less TIMs are in? I assume they have a .TIM header, but without CLUT data I suppose. You wouldn't be able to post an example of one of the pre-rendered background files your viewer found, would you, either as raw data attached to a post or a snapshot of one of the file headers in hex?
Also, provided you used the dump.exe to get at the CLUT-less TIMs, could you tell us which directory they get put in? Not in CD\ obviously, but perhaps in Rooms\ ?
-
Zeality will probably release the new textures as a Compendium download, so stay tuned.
Isn't that illegal? Textures are copyrighted material after all.
Also, provided you used the dump.exe to get at the CLUT-less TIMs, could you tell us which directory they get put in? Not in CD\ obviously, but perhaps in Rooms\ ?
Rooms\Disk 1\XXXX\GFX.
-
Thanks Gemini! Zeality will have to decide about the textures, I suppose; maybe it's a good thing I didn't post them publicly myself.
EDIT:
Rooms\Disk 1\XXXX\GFX.
Oh, hey, Gemini or anyone else - I assume you have to use a roomdecompress.exe to get that directory structure? Where IS roomdecompress.exe? Is it available on the Compendium?
-
I know it's in Nemesis's improved Chrono Cross Translation Tools, with the .bats that no one's figured out yet. I tried the main dumping program again last night to no avail.
If I heard correctly, Yazoo's main dumping program produces some junk TIMs? Then we should really get Nemesis's CC Translation Tools working...
This entire website is illegal, right down to the core. Almost all fan sites are...The textures would be a very small drop in the ocean. We just don't host ROMs, since that's asking for trouble. We don't really host the videos either.
-
I still haven't had a chance to take a good look at Nemesis' tools, though I've got them extracted properly I think. It may be a matter of putting the CD image in CD1\Image Avant and running the main Chrono Cross.exe wth the right dump, etc. arguments. The CD image may have to have a certain name too.
In Yazoo tools news, I've found a "roomdecompress2.c" and "roomdecompress2.src"
I've tried compiling the C file with Miracle C Workbench, but no go because cctools (Yazoo's stuff) seems to be missing an "lzss-dec.h" file, which may be the key to getting the room decompression tool to work.
I'm attaching both the roomdecompress2.c and roomdecompress2.src for the perusal of any Computer Science wizards who happen along. Is there any way we can create an executable straight from the src source file?
Also, Gemini, if you happen along can you post a copy of your roomdecompress.exe if you've got one?
[attachment deleted by admin]
-
If I heard correctly, Yazoo's main dumping program produces some junk TIMs? Then we should really get Nemesis's CC Translation Tools working...
I said that already twice, but here it goes one more time: those TIMs are totally fine, but compressed. You can still get the actual images decompressing all the "junked" files.
Also, Gemini, if you happen along can you post a copy of your roomdecompress.exe if you've got one?
Unfortunately, no. But since you have the original source, you can create a working room decompressor. First of all remove that #include "lzss-dec-h" line or whatever it was, then compile again and look at the error log. It should say something about a wrong instruction. IIRC, commenting it and recompiling everything should produce a working room-decompressor.exe.
-
Okay, I'm giving this a try.
Here's the things I removed from the .c file, with black boxes around them. My compiler didn't like the extra "string.h" line, so I deleted it as well:
http://img106.imageshack.us/img106/7129/step1ht5.gif
When I compile, I get the following message: line 44: Parse Error, expecting `SEP'
'short int valeur'
aborting compile
Line 44 of the .c file looks like this:
http://img153.imageshack.us/img153/5227/step2xm1.gif
Any ideas on how to proceed, or am I doing things totally wrong?
-
I don't get the error (SEP?) at line 44. And for string.h, you need that header, so you are missing it. I'd suggest you to change compiler at all or to get the whole SDK (I dunno what you are using, so I can't tell you exactly what you need in your case). I had not such a problem with Visual Studio.
-
Okay, thanks Gemini. I'll try out a few different compilers and update my SDK runtime environment and see if I can get anything to work.
-
Okay, I'm giving this a try.
Here's the things I removed from the .c file, with black boxes around them. My compiler didn't like the extra "string.h" line, so I deleted it as well:
http://img106.imageshack.us/img106/7129/step1ht5.gif
When I compile, I get the following message: line 44: Parse Error, expecting `SEP'
'short int valeur'
aborting compile
Line 44 of the .c file looks like this:
http://img153.imageshack.us/img153/5227/step2xm1.gif
Any ideas on how to proceed, or am I doing things totally wrong?
[attachment deleted by admin]
-
Once again, Ramsus saves my sorry arse!
EDIT: Ramsus, it appears that the decompressor cuts out for me after reaching room #503. Stack overflow, perhaps? But I'm just tossing around computer terms.
For what it's worth, I'm linking to some headers of the files this decompressor produces. The first few bytes would suggest that they are TIMs of some sort, which lead me to believe these are Gemini's pre-rendered environments. My Irfanview is associating itself automatically with these as .RAW files. They don't open up in PSicture at all; looks like it might be a job for Tile Molester perhaps. But if there's no CLUTs...
http://img526.imageshack.us/img526/7059/image1rr9.gif
The other images in the GFX\ directory are regular .TIMs that we've already seen from what I can tell.
-
Oh! Here's an error report too:
http://img91.imageshack.us/img91/6668/errreportll6.gif
-
The one you were looking for was "buffer overflow." I'll debug it later if I get the same result. The input room data is probably just shorter than expected for some reason.
Anyway, after looking at the source, it looks like the decompression routines are only used on the room's script, and maybe a few things that weren't finished. Also, the CLUT information should be stored in ".act" files. Later I'll read a bit about the TIM format and look at the output to see for myself what's going on, and maybe modify the room decompressor to just put the CLUT information in the TIM files it dumps. In the meantime, you can try inserting the contents of the .act files (assuming they're even there, but I'm just going off the code...) in between the start of the TIM header and the image block.
-
Thanks. If we're lucky, the maps will be stored individually as "giant TIMs" like the guy on QHIMM might have suggested.
Leads me to wonder, though...like for Nadia's Bell, there was the huge palette in VRAM Viewer that the main stuff used, but the plaque required a different, smaller palette way off to the right. Happens with overlay in other locations, too. I wonder if that'll complicate things.
-
I just received another room decompress util from Sephiroth 1311 at sadnescity.it
Still dumping; will report.
EDIT: This one gets to room 536 before cutting out. Blargh. All the tools Sephiroth emailed to me are attached.
EDIT: And there's .act files as Ramsus predicted. Each room folder has its own .act in Rooms\####\Code. Some rooms have more than one.
[attachment deleted by admin]
-
Looking at the RAW files with Tile Molester, it definitely appears there's tiled...somethings in here.
(http://img137.imageshack.us/img137/1016/tilesgn1.gif) (http://imageshack.us)
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.
-
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.
-
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]
-
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.
-
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]
-
It looks like the script isn't the only part of the Room file that's compressed...
-
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.
-
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.
-
I guess the "MIM" thing was a false lead for the backgrounds.
-
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.
-
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.
-
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.
-
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...
-
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...
-
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?).
-
Yeah, it's stuff TIMViewer can pick up. Ditto for the TD; I never saw his textures during our earlier runs with TIMViewer.
I wonder what these 544-byte headers are preceding the character dialogue portraits?
00000000 10 00 00 00 09 00 00 00 0c 02 00 00 00 00 e0 01 00 01 01 00 ..............à.....
00000014 00 00 21 08 42 0c 43 10 43 0c 43 10 44 0c 44 18 64 10 45 0c ..!.B.C.C.C.D.D.d.E.
00000028 44 1c 64 18 64 10 65 18 46 0c 65 10 65 20 65 18 66 14 47 10 D.d.d.e.F.e.e e.f.G.
0000003c 48 10 65 24 66 10 66 28 4a 10 86 14 4a 10 86 20 68 10 66 30 H.e$f.f(J...J.. h.f0
00000050 6a 10 66 34 6b 10 66 30 89 10 66 34 87 24 88 18 a7 14 4d 10 j.f4k.f0..f4.$..§.M.
00000064 87 2c 6a 10 89 10 6b 0c 87 34 6d 10 a9 14 aa 14 50 14 88 34 .,j...k..4m.©.ª.P..4
00000078 a8 28 6e 14 8d 10 a6 38 6f 14 a8 38 c9 14 ab 1c a8 30 cb 10 ¨(n...¦8o.¨8É.«.¨0Ë.
0000008c a8 38 c9 24 52 14 ca 18 cc 10 ab 24 ad 14 71 14 c9 38 cb 14 ¨8É$R.Ê.Ì.«$.q.É8Ë.
000000a0 cc 10 72 14 ca 30 c9 3c cf 14 73 14 ed 10 ea 24 ec 1c ec 10 Ì.r.Ê0É<Ï.s.í.ê$ì.ì.
000000b4 ea 3c 94 14 0c 19 ed 14 b2 18 eb 30 ce 20 95 18 eb 3c f0 10 ê<....í.².ë0Î ..ë<ð.
000000c8 0d 19 0d 21 0e 15 ef 14 eb 3c 2b 29 29 3d 2f 11 b6 18 2c 39 ...!..ï.ë<+))=/.¶.,9
000000dc 0f 19 f2 18 2e 1d 0c 41 2f 11 4d 25 2f 19 4f 15 2d 41 13 19 ..ò....A/.M%/.O.-A..
000000f0 50 19 4d 45 d8 1c 50 1d 6b 45 70 15 33 19 70 1d 4e 45 71 19 P.MEØ.P.kEp.3.p.NEq.
00000104 36 15 8e 2d 54 19 71 21 18 21 92 19 6f 49 55 19 92 19 19 21 6..-T.q!.!’.oIU.’..!
00000118 74 1d 76 19 93 21 75 19 b3 19 b1 31 90 49 39 25 96 19 b3 19 t.v..!u.³.±1.I9%..³.
0000012c 94 21 b0 4d 96 21 d1 31 b4 25 d4 19 d4 19 98 19 f5 1d d1 51 .!°M.!Ñ1´%Ô.Ô...õ.ÑQ
00000140 d5 29 b7 21 ba 19 f5 21 f5 2d b9 21 da 19 16 22 bb 2d f6 2d Õ)·!º.õ!õ-¹!Ú.."»-ö-
00000154 f2 4d d9 25 f7 29 16 22 da 25 16 32 17 26 fb 19 14 56 db 31 òMÙ%÷)."Ú%.2.&û..VÛ1
00000168 fa 25 18 32 37 26 1b 26 36 36 19 2e 54 46 58 2a fb 39 3b 26 ú%.27&.&66..TFX*û9;&
0000017c 1c 1e 58 2a 3a 32 3c 22 1b 3e 75 4a 59 36 77 3e 79 2e 75 5e ..X*:2<".>uJY6w>y.u^
00000190 5c 32 5c 22 3c 42 99 32 7c 32 96 5e 7d 2a ba 32 7d 4a 9d 36 \2\"<B.2|2.^}*º2}J.6
000001a4 9d 2a b7 62 ba 3a db 36 bd 3a bd 2e 9d 4a b9 62 bd 2e db 3a .*·bº:Û6½:½..J¹b½.Û:
000001b8 bd 3a fc 42 de 32 bd 4e fc 3e fe 36 1c 43 fe 3e dd 5a 1c 3b ½:üBÞ2½Nü>þ6.Cþ>ÝZ.;
000001cc 19 67 1d 47 1e 43 1e 3b 3e 43 3d 47 1e 5f 5e 43 5d 4b 5e 47 .g.G.C.;>C=G._^C]K^G
000001e0 5e 4f 7c 5b 7f 43 3e 6b 7e 4f 9e 57 9f 4b 7e 6f 9f 57 bf 4b ^O|[.C>k~O.W.K~o.W¿K
000001f4 bf 63 bf 57 9f 77 bf 67 df 57 df 5f bf 77 df 63 df 6f df 67 ¿c¿W.w¿gßWß_¿wßcßoßg
00000208 df 77 ff 6b ff 73 ff 7b ff 7b ff 7f 0c 10 00 00 00 00 00 00 ßwÿkÿsÿ{ÿ{ÿ.........
0000021c 20 00 40 00 00 00 00 00 00 0e 1a 27 09 0e 14 14 14 14 13 13 .@........'........
-
544 bytes is big for a header. At least from my limited experience. That's worthy of investigation. It's the same for all the dialogue portraits?
Do you recall if we have the TD's Dragon God form texture, Zeality? I think that one's on both the "dungeon" map in Terra Tower as well as in battle. Should be the same for the various colored Dragons. The Lavos form of the Time Devourer only appears in battle I think, so if we lack only the texture for that last boss, it would suggest that some bosses, at least, have different textures in and out of battle. How bothersome!
-
Seems like a redundant, bloated way of doing things in terms of data size...
It's redundant, but reduces seek time for loading stuff from several files located in different zones of the ISO. Instead, you have everything in 3 consecutive files, which makes CD loading really fast and organized.
-
Aha, I see.
Well, good news. I did my favorite hobby of feeding things into TIMViewer, and I've got two hunches now:
1) The rooms are in the same map order as listed in the debug menu / room modifier GS code.
2) The rooms each use three files with the following inside: A) Unknown B) Lighting textures C) NPC textures.
This is probably common knowledge, but I'm guessing A) could be the walk mesh. It's pretty fresh, and I'll know more once I weed out the TIMs and see if TileMolester knows what's left. For the Doc's house (Home), it's 1007, 1008, and 1009.
Okay, 1009's TIMs had no headers inside the file. Here are 1008's. Each is 12 bytes long:
00000bcc 00 00 00 00 6e 6d 31 31 04 00 4c 00 00 00 00 00 ....nm11..L.....
00000be0 6e 6d 31 30 04 00 4c 00 00 00 00 00 6e 6d 30 39 04 00 4c 00 nm10..L.....nm09..L.
00000bf4 00 00 00 00 68 69 6b 32 04 00 24 00 00 00 00 00 68 69 6b 31 ....hik2..$.....hik1
00000c08 04 00 24 00 00 00 00 00 6e 6d 30 38 04 00 4c 00 00 00 00 00 ..$.....nm08..L.....
00000c1c 68 69 6b 36 04 00 24 00 00 00 00 00 68 69 6b 33 04 00 24 00 hik6..$.....hik3..$.
Now let's examine the remaining files.
1007 - No idea.
1008 - 3,120 bytes remaining (including the TIM headers): Stars with "drp". Just has a lot of "hik3"s in it. The data has a lot of .......s.
1009 - No idea. I'm guessing it has NPC / enemy models and battle animations.
I've attached the resulting files; 1008 still has the TIM headers, but no TIMs of course.
Hey wait, you guys have subdirectories in your /Rooms/ folder? I just get Rooms, not GFX or other stuff.
[attachment deleted by admin]
-
The drp files are just archives. All those names you see inside them are the subfile names (4 chars each, no extension). In Yazoo's private tool package there is a program called DRP Decompressor or something like that, which can extract all the entries in a more or less accurate way (file size is wrong and dup files cease to exist).
-
Oohh, I understand what all that was now...god, writing three papers is really killing me here...
Okay, yeah. From the amount of room files, 537 is the perfect number.
Well, guess that takes care of rooms until probably Thanksgiving, when classes will finally let up. The CF portraits also seem to have a big piece of something unrelated to the TIMs in them like the CFTs.