Chrono Compendium

Kajar Laboratories - Fan Works and Submissions => Chrono Cross Modification => Topic started by: FaustWolf on March 11, 2008, 11:16:16 pm

Title: Chrono Cross Pointer Investigation
Post by: FaustWolf on March 11, 2008, 11:16:16 pm
Alrighty, another CC thread to adorn Kajar Labs. This time I'm snooping for pointers, specifically those in the Table of Contents at the beginning of the first game CD (some will call this the Index File). I've decided that the Table of Contents reports everything in sectors (dec 2048; x800 bytes apiece). I'm still trying to figure out the "stride" of the data, i.e., how many bytes are needed to specify all the info for any one file in the TOC.

The TOC for the first CD at address 0xC000 and starts out like so:


0000C000  26 00 00 00 4E 01 00 F7-4F 01 80 00 4F 01 80 00  &...N...O...O...
0000C010  4F 01 00 33 D6 01 00 FC-D8 01 00 62 4E 02 00 4F  O..3.......bN..O
0000C020  51 02 00 25 5F 02 00 2B-77 02 00 28 7A 02 00 F1  Q..%_..+w..(z...
0000C030  9D 02 80 00 9D 02 80 00-9D 02 80 00 9D 02 80 00  ................
0000C040  9D 02 80 00 9D 02 80 00-9D 02 80 00 9D 02 80 00  ................
0000C050  9D 02 80 00 9D 02 00 74-AF 02 00 1C B5 02 00 BC  .......t........
0000C060  0C 03 00 13 98 03 80 00-98 03 80 00 98 03 80 00  ................
0000C070  98 03 80 00 98 03 80 00-98 03 80 00 98 03 80 00  ................


I want to focus on that first stride of four bytes. I'm not sure that it's a complete stride, but read in Little Endian, it would be 0x00000026. It's essentially a pointer to a file; multiply it by the sector size (x800) and you get the address x13000 -- that's the beginning of the game executable.

So we have some idea of what's going on here. But I'd be interested in input from hackers and programmers regarding a few questions:

1.) If I, say, shift the game executable one sector backward - from 0x13000 to 0x13800 - and enter in x27 as the first byte of the Table of Contents, have I just done a pointer change? Is that all there is to it? Like, will the game be hard-coded to look at address x13800 when it wants the game executable? This is assuming there's enough "free space" following the executable's original position to perform such a move without running into other data.

2.) Some files do NOT fall on sector boundaries, which really turns my world topsy-turvy. For example, Flea's overworld texture starts at address 0x0E196C98. When the game looks for a pointer to this texture, how the heck can it find it? Certainly fractional sectors can't be reported in the TOC, can they?
Title: Re: Chrono Cross Table of Contents Investigation
Post by: MDenham on March 11, 2008, 11:37:11 pm
Yes, everything seems to be four-byte entries.  Interestingly, there seems to be a lot of "xx xx 80 00" entries which repeat, followed by "xx xx 00 yy".  Presumably, therefore, it works as follows:

* 2 bytes: sector #.
* 1 byte: flags - 80 = deleted? extended information? Who knows?
* 1 byte: Not sure.

The "flags" byte may contain part of the sector number as well (if it does, it's going to be the high-order nibble of the sector number in the lower 4 bits; 20-bit sector numbers are enough to map out 2GB overall).

And as far as that fourth byte on every entry, when I say "not sure" I'm REALLY in the dark there. :lol: We'd need at least 9 bits to get a workable offset into a sector (and then just assume the bottom two bits are 0, which generally works - essentially, shift the number left two places).  Since we only have 8 viable bits there...  well, maybe it's an offset shifted right by three, but I wouldn't put money on it.
Title: Re: Chrono Cross Table of Contents Investigation
Post by: FaustWolf on March 11, 2008, 11:49:03 pm
Ah, thanks M. So it's possible to have a sector number and an offset within the sector communicated by four bytes.

I've confirmed a four-byte stride -- the next four bytes over, the ones that will show up in green shortly, point to something that looks like this:

BOOT   = cdrom:\SLUS_010.41;1
TCB      = 4
EVENT   = 16
STACK   = 801fe000

That begins at address 0xA7000, which is sector x014E. So, looking at the code posted above, the first two bytes, at least, definitely communicate whole sector starting addresses. Now to figure out what that xF7 does...

EDIT: The purple bytes point to an instruction set of some sort judging by the ASCII, at sector x014F. Then there's the x80 the next byte over.

All that I can see is that the sector "green" points to has data that is x45 bytes long, then 00 buffers fill the rest of the sector until the instruction set "purple" points to begins.

EDIT AGAIN: Hmm, this Table of Contents seems to be pointing into various instruction sets within the executable so far. I'll need to make sure that this TOC actually DOES point to the data eventually...
Title: Re: Chrono Cross Table of Contents Investigation
Post by: FaustWolf on March 12, 2008, 12:15:15 am
Here we go, I very strongly suspect this section of the TOC is pointing at data we've studied:


0000C390  42 16 00 00 44 16 00 00-48 16 00 89 4F 16 00 00  B...D...H...O...
0000C3A0  50 16 00 3B 60 16 00 A8-75 16 00 B9 A1 16 80 00  P..;`...u.......
0000C3B0  A1 16 80 00 A1 16 80 00-A1 16 80 00 A1 16 00 D2  ................
0000C3C0  AE 16 00 BC B7 16 00 BB-C3 16 00 BC CC 16 00 54  ...............T
0000C3D0  DB 16 00 BC E4 16 00 8B-F1 16 00 BC FA 16 00 22  ..............."
0000C3E0  06 17 00 BC 0F 17 00 82-1B 17 00 BC 24 17 00 B7  ............$...
0000C3F0  34 17 00 BC 3D 17 00 E7-4B 17 00 BC 54 17 00 DA  4...=...K...T...
0000C400  61 17 00 BC 6A 17 00 93-79 17 00 BC 82 17 00 52  a...j...y......R
0000C410  8D 17 00 BC 96 17 00 5D-A2 17 00 BC AB 17 00 4F  .......].......O
0000C420  B8 17 00 BC C1 17 00 B6-D0 17 00 BC D9 17 00 BC  ................
0000C430  E7 17 00 BC F0 17 00 B5-00 18 00 BC 09 18 00 4C  ...............L
0000C440  17 18 00 BC 20 18 00 31-2F 18 00 BC 38 18 00 B7  .... ..1/...8...
0000C450  46 18 00 BC 4F 18 00 2B-5D 18 00 BC 66 18 00 89  F...O..+]...f...
0000C460  74 18 00 BC 7D 18 00 ED-8C 18 00 BC 95 18 00 FF  t...}...........
0000C470  A3 18 00 BC AC 18 00 8D-BD 18 00 BC C6 18 00 E4  ................


Dudes and dudettes, get this.
Sector x1734 "Red" is Riddel's overworld texture. (fourth byte BC)
Sector x173D "Purple" is Riddel's overworld model. (fourth byte E7)
Sector x174B "Blue" is somebody's overworld texture. (fourth byte BC)
Secor x1754 "Green" is somebody's overworld model. (fourth byte DA)
Sector x1761 "Orange" is somebody's overworld texture. (fourth byte BC)

I'm becoming fairly confident that the last byte is a file type identifier. A similar scheme is used in FF9 according to the intrepid explorers over at Qhimm, so I think that's what we have here. What I can't reconcile yet are the different "labels" applied to the models...

SUPER EDIT: Alrighty, I've found the pointers to Serge's weapon and battle model. I'm coming back with either the Dark Serge Hack or utter, painful failure.

DISAPPOINTMENT EDIT: Meh. This is merely a list of files on the CD. They are not, I repeat, they are NOT active pointers as I was hoping for. For example, I replaced Serge's texture, battle model, and weapon model TOC entries with those for Dark Serge's data. Nothing. Zilch. Null. Nada. I'm left staring at our normal, run-of-the-mill Serge. I would have expected the game to freeze at least.

Thus, this list of files is extremely useful for dumping, but not for hacking. The active pointers are somewhere else further on in the data, I'm afraid to say. And I imagine they'll be relative pointers (and not absolute pointers), making them all the more difficult to find.

Can anyone confirm that a TOC is not a list of active pointers? I just want to make sure I'm not missing something huge.

PS: As an added bit of food for thought, it would appear that there is no other list of absolute pointers to particular models, textures, etc., anywhere on the CD. That is, the *real* pointers would have to be stored in some format other than in sectors counting from the beginning of the CD.
Title: Re: Chrono Cross Pointer Investigation
Post by: Gemini on March 12, 2008, 09:10:27 am
Consider those pointers as an array of unsigned int. So:
int lba=index[id]&0x7FFFFF;
int size=((index[id+1]&0x7FFFFF)-lba)*2048+(index[id]>>24)*8;

When byte 3 in index[id] contains 0x80 you can skip that value and go to the next one. Byte 4 is NOT a type classifier.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on March 12, 2008, 11:22:08 am
Yay! Gemini, I was about to look for you at Romhacking.net, so I might as well ask here.  :D

These pointers don't seem to be the ones the game uses to find model and texture data in real-time. How would we go about finding pointers for graphical data in a PlayStation game?

I've read Duo's PlayStation pointer doc (http://www.romhacking.net/docs/372/), which says that one needs to dump memory from pSX using the debugger. I dumped the r3000 processor memory, and got what appears to be 940kb of data from the game executable. Duo's doc was for text though, and I'm not sure how much it's going to help in finding graphical data.

In the game executable, I can see instructions like ()kzgetmodel in the ASCII sidebar of my hex editor. Pointers wouldn't directly follow these instruction sets by any chance, would they?
Title: Re: Chrono Cross Pointer Investigation
Post by: Gemini on March 12, 2008, 11:45:16 am
These pointers don't seem to be the ones the game uses to find model and texture data in real-time. How would we go about finding pointers for graphical data in a PlayStation game?
Pointers are pointers, no matter what they point to. No specific rule to find them, and they don't follow any specific format either. I guess you just have to cross your fingers and hope to find something.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on March 12, 2008, 11:52:19 am
Heh, heh, heh, that's what I was afraid of. From your experience, do pointers typically occur in a specific section of the game CD (like the executable) or do developers just throw pointers in wherever they want to? I think in SNES games pointers can be just about anywhere.
Title: Re: Chrono Cross Pointer Investigation
Post by: Gemini on March 12, 2008, 11:58:23 am
File pointers can be stored in the main exe, Parasite Eve is an example of them, but they are usually stored in other files if not in the archive itself (most frequent case). Games like Innocent Sin have files for dialogues and events and then the pointers to each subsegment stored inside the section module/exe.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on March 12, 2008, 12:15:27 pm
Alright, that gives me a starting point. Thanks Gemini!

EDIT: For the heck of it, and so I can dump this info from my memory for awhile, here's a pointer table for character names. It is stored in the executable, and comes just before the character names themselves.


0005BD60                                      84 00 8A 00              ....
0005BD70  8E 00 94 00 9B 00 A1 00-A7 00 AE 00 B4 00 B9 00  ................
0005BD80  BF 00 C6 00 CD 00 D4 00-DB 00 E1 00 E7 00 EE 00  ................
0005BD90  F4 00 FA 00 00 01 06 01-0B 01 11 01 18 01 1F 01  ................
0005BDA0  26 01 2D 01 32 01 39 01-40 01 46 01 4D 01 54 01  &.-.2.9.@.F.M.T.
0005BDB0  5B 01 5F 01 64 01 68 01-6E 01 75 01 79 01 80 01  [._.d.h.n.u.y...
0005BDC0  87 01 8D 01 91 01 95 01-99 01 9D 01 A1 01 A5 01  ................
0005BDD0  AA 01 AC 01 AE 01 B0 01-B2 01 B4 01 B6 01 B8 01  ................
0005BDE0  BA 01 BC 01 BE 01 C0 01-C2 01 C4 01 C6 01 C8 01  ................

Title: Re: Chrono Cross Pointer Investigation
Post by: Vehek on July 25, 2008, 07:41:09 pm
While I know you can't be around much right now, I want to ask something.
What were you doing to test pointer changes? I've tried messing with the pointers and I've gotten almost nothing but freezes.

edit-
My problem must be with what it does to determine the file size.

edit 2:
If you were testing by loading savestates, then that was why nothing seemed to happen.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on July 26, 2008, 08:03:13 pm
I had been altering the ISO itself, saving the file in a hex editor, and then loading the ISO. However, I should probably check that I was doing a fresh load from the actual load screen and not using save-states to test.

From my discussions with halkun and Cyberman, I gather that pointers to battle models are possibly stored in the LZSS-compressed battlescripts. However Vehek, could you provide an example of a pointer change you made that caused the game to freeze?
Title: Re: Chrono Cross Pointer Investigation
Post by: Vehek on July 26, 2008, 08:12:43 pm
Well, to be more accurate, I mostly got the battle screen stuck unable to load the PC battle models.
For example, I changed a pointer that was originally A5 29 02 84 to one of the later pointers. I can't remember what pointer changes actually crashed the game.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 21, 2008, 12:55:14 pm
BLAARGH! Turns out Vehek discovered that the table of contents is, indeed, the pointers we're looking for! :lee: I was testing with savestates all this time, but Vehek found out that these pointers work as long as you load up the game from scratch. If we get these working flawlessly, it'll be a major step in Chrono Cross hacking!!

Vehek's had some success in repointing battle and field models. I've successfully got Kid's battle model moved and repointed to make space for a Serge > Dark Serge hack. However, when I implement the changes necessary for Serge > Dark Serge I get a nasty red screen of death just as the battle model begins to load, so something's up.

Simply repointing Serge's battle model pointers to Dark Serge's causes the red screen of death as well.

To facilitate exploration of the pointers, I've attached a spreadsheet detailing where all the models and pointers are for the battle models on the first CD. The CD needs to be ripped in 2048 byte/sector format. Note that by looking at the spreadsheet, you can tell that the fourth byte we were wondering about before serves some kind of vital purpose -- it's got to be some kind of file identifier or a pointer to an instruction set that the game engine has to use to interpret the file, or something. Neither of those descriptions is qutie correct, however, because every unique model has its own identifier. Radius (both player and enemy) have 0xD2 for example, and all sword weapon packs have 0x18. All player character textures are assigned the fourth byte 0x73, and enemy textures are assigned 0xBA.

The most important rule I've discovered so far with the pointers is that no two pointers should ever overlap, even if one of the pointers applies to a character not being loaded. This is ridiculous because there's tons of duplicate pointers in the pointer table, but there are no duplicates within the range of pointers used for character battle models.

The above rule was kicking my ass while I tried in vain to move Kid's battle model for awhile. I erased Guile's battle model data, shoved Kid's backward in the ISO to make room for Dark Serge, altered the pointers accordingly, and the red screen of death occurred. The pointers for Kid's texture and model just happened to duplicate the pointers assigned to Guile at the time; when I repointered Guile's positions in the table of contents to blank sectors following Kid's, it finally worked!

However, I haven't been so lucky with Dark Serge. It *shouldn't* be a problem with model length because NeoFio happens to have the same amount of sectors for its model as Dark Serge does, believe it or not. I'll keep trying out various things I guess.

[attachment deleted by admin]
Title: Re: Chrono Cross Pointer Investigation
Post by: MDenham on December 21, 2008, 02:30:02 pm
However, when I implement the changes necessary for Serge > Dark Serge I get a nasty red screen of death just as the battle model begins to load, so something's up.
Okay, stupid question (and GRAAAAAAAA RETURN OF ME time also, been working on numerous other side projects entirely unrelated to CC, such as getting my server up and running): is this "red screen of death" just a flat red, same shade every time no matter what, or are there differences (flickers between several shades, different shade every time, etc.)?
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 21, 2008, 02:48:32 pm
Heeey, welcome back M! :lee: :lee: :lee:

Yeah, the "red screen of death" is the exact same shade every time. I think it indicates a specific problem, but not sure what. I do remember it happening when I tried to insert Dark Serge into someone's battle model space without repointering and hoped for the best way back when.

I should note that the "unknown fourth byte" for the battle model data is pretty darn important. If you alter it from its original, the model won't load. You don't get a red screen in that case -- the game keeps going, but gets stuck and doesn't load the model. Everything it's loaded up to that point seems to function correctly though, such as little animals that crawl around the battleground.
Title: Re: Chrono Cross Pointer Investigation
Post by: utunnels on December 21, 2008, 02:56:46 pm
Well, maybe I know nothing about CC hacking stuff.
But for FF9, each battle has a complete set of  text, script, font... Which means the game load all that are needed by this battle from a huge block of data(probably not including textures). A battle with 2 goblins and a battle with 3 goblins are 2 different sets, which means there are 2 almost duplicated data blocks(you can hack the script or text, give different names to the goblins, etc), the game just won't go fetching a single goblin data from somewhere of the CD.

Maybe Dark Serge's model is not actually loaded?
Title: Re: Chrono Cross Pointer Investigation
Post by: MDenham on December 21, 2008, 03:08:19 pm
Yeah, the "red screen of death" is the exact same shade every time. I think it indicates a specific problem, but not sure what.
Would be nice if I knew whether or not (for example) ePSXe supported dumping output from the external ports that would be on an old-style PS1 (specifically the serial port), and finding a devkit-PS1 BIOS would be a godsend for this as well.

I'm pretty sure there's still a substantial amount of the debug calls to help trace the program left in there - it would explain a lot of the odd text scattered throughout.

Off to look for the required information.
Title: Re: Chrono Cross Pointer Investigation
Post by: Vehek on December 21, 2008, 03:47:53 pm
An interesting note: I got Serge's field model to load a NPC model that was a sector larger by chhanging that fourth byte.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 21, 2008, 04:03:44 pm
AHA! Yes, it definitely has something to do with that darned fourth byte. It doesn't seem to matter for textures (at least in some cases) and weapons, but it definitely is important for the model. I'll test it out next time I fire the ISO up.

EDIT: utunnels, I happen to have a great interest in FF9 model research as well. Have you been to qhimm yet?

Oh, and Vehek, did you take notes on how you chose the value for the fourth byte? Did you make it match up with the fourth byte that larger model had originally. And did the game freeze up before you changed that fourth byte?
Title: Re: Chrono Cross Pointer Investigation
Post by: Vehek on December 21, 2008, 04:07:14 pm
In this case, I was testing with copying a NPC model to empty space. I think that before, it was freezing up. I changed the fourth byte to be the same as Kid's.
Title: Re: Chrono Cross Pointer Investigation
Post by: utunnels on December 21, 2008, 04:16:24 pm
EDIT: utunnels, I happen to have a great interest in FF9 model research as well. Have you been to qhimm yet?
No, I've never visited there before...
Yeah, I just spoke a possibility, as I said, I've not researched it at all.
I used to be one of the coders of a FF9 fan-translation project, but I'm not handy at ASM. :P
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 21, 2008, 08:43:00 pm
After a few preliminary tests...
 :picardno

Shit, guys. I've just (probably) conclusively confirmed that there is, indeed, a limit on the total amount of model data (texture, model, weapon pack) that can be fed into the game engine for any single model. Here's what I did:

Regular Serge texture, model, and weapon, but shoved the weapon back to the sector it would have to be in to make enough space for the Dark Serge model. Repointered as necessary. Result? Red Screen of Death.

Regular Serge texture, and model with pointers unchanged from above. Replaced Swallow weapon pack with the "glove" weapon pack, which is only one sector long because it's basically nothing. Result? Serge works fine, but weaponless.

Dark Serge texture, Dark Serge Model, glove weapon pack, with pointers unchanged from above. Result? Dark Serge works fine, but weaponless.

Of course I've already tried the pointer values with Dark Serge texture, Dark Serge model, and Scythe weapons pack.

Next thing to do is find a suggested upper bound on the size of a model's necessary data in sectors, so we can notify Chrono Cross fan projects of this technical limitation. Given that we're just now exploring Chrono Cross' internals, it seems kind of silly to try and change this bound via asm hacking, but I dunno. Ugh.  :evil:

The only hope for a perfect playable Dark Serge now is that either a.) changing the fourth byte somehow miraculously saves the day (I haven't tried this yet) or b.) the game will correctly load the enemy weapons pack given to Dark Serge as an enemy -- I've been trying with Scythe/Serge/Lynx's scythe weapons pack, which is what we used for the Magus Unmasked hack. I'll keep you updated...
Title: Re: Chrono Cross Pointer Investigation
Post by: MDenham on December 21, 2008, 09:19:29 pm
 :picardno x2.

I seem to have had my entire code disappear as far as the rewritten tools...  which does not help (it's not too bad to rewrite it, but it's work I don't particularly want to repeat :D).

However: the fourth byte does just state how much of the last sector is padding.  (0 = none, 1 = eight bytes, 2 = sixteen bytes, and so on.  Just multiply by 8.)

Keep in mind that if you're trying to "inject" a larger model into the middle of the ISO, you'd have to adjust EVERY ENTRY AFTERWARDS.  It's safer to drop them in at the end of the ISO for the time being, it seems.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 21, 2008, 09:48:34 pm
Oh man, you just totally figured it out M! Maybe that's the key after all. Jeez, your return is like this serious Christmas gift. Also --

Just ignore my post above, because I was dead wrong! It just so happens that the file size needed to load General Viper is waaay more than what would be needed to load a working Dark Serge theoretically.

General Viper (Player Character):
Texture: File 3070 = 0x9800
Model: File 3071 = 0xE800
Weapons Pack: File 3072 = 0x14800
Total: 0x2C800

Dark Serge (Theoretical Player Character):
Texture: File 3670 adapted with some placeholder blink textures and other framework = 0x9800
Model: File 3671 = 0x11000
Weapons Pack: File 3210 = 0x29800

So I was factually wrong. It must be the fourth byte then. Maybe everything loads correctly if you tell the game engine there's greater than/less than the true amount of buffer space, and things get screwed up if the alternative happens. That would explain Vehek's experience and my own. Now to figure this out once and for all! :twisted:
Title: Re: Chrono Cross Pointer Investigation
Post by: MDenham on December 21, 2008, 10:03:03 pm
So I was factually wrong. It must be the fourth byte then. Maybe everything loads correctly if you tell the game engine there's greater than/less than the true amount of buffer space, and things get screwed up if the alternative happens.
Most likely the errors occur when you're telling them there's more buffer space than there should be - because then you're chopping off the end of Section 5!
Title: Re: Chrono Cross Pointer Investigation
Post by: Shadow D. Darkman on December 21, 2008, 10:32:39 pm
Hey, question. Has anyone tried to hack a Serge (not as Lynx) VS Dark Serge battle?

(Sorry if this is a bit off-topic but this seems the most relevant place to ask this.) :oops:
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 21, 2008, 10:40:02 pm
@Shadow: We'll do better than that eventually.

Grrr, even specifying the fourth byte correctly isn't doing it for me. There's something about combining Dark Serge's model with Serge/Lynx's scythe that the game engine absolutely detests.

EDIT: Just so everyone knows I'm not completely crazy or anything, Dark Serge really does work when I assign a glove weapons pack to his model:
(http://img377.imageshack.us/img377/7856/image1hv5.th.png) (http://img377.imageshack.us/my.php?image=image1hv5.png)

It's got to be some kind of texture loading issue. That's the only thing I can think at this point.
Title: Re: Chrono Cross Pointer Investigation
Post by: Shadow D. Darkman on December 21, 2008, 11:08:06 pm
Ooh, cool! Dark Serge as a playable character! Sweet!
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 22, 2008, 02:15:36 am
The red screen of death still reigns supreme. I should probably try testing Dario, Flea, Slash, and Ozzie, but I'm too stubborn to let go of this just yet. I've tried the following:

Dark Serge Texture and Model, Glove Weapon pack: Works (without a weapon of course)
Dark Serte Texture and Model, any other weapon pack: Red screen of death
Regular Serge Texture and Dark Serge Model, any weapon pack: Red screen of death

What's actually fairly hilarious is that the game engine can load Dark Serge's "enemy scythe" weapon pack just fine -- it's a single scythe corresponding to the character's first equipped weapon, so you need to have Sea Swallow equipped or else the game will freeze when it tries to load the weapon. It can load on the status screen just fine, but red screens when it attempts to load in battle.

It's not a texture issue as I previously supposed -- the third experiment with Serge's regular texture would have solved that. Nor is it a total file size issue, nor is it a fourth byte issue. It's got to be something having to do with the interaction between the model and any weapon pack except the gloves weapon pack. It's like Dark Serge's model vehemently screams, "I can't handle a weapon!!"

Something interesting to note -- when Dark Serge attacks with gloves assigned as his weapon pack, his model performs all animations appropriately except normal attacks, which cause him to become discombobulated during the attack. I'm not sure what's up with that, because all attack animations are supposed to be stored in the model itself.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 22, 2008, 04:14:23 am
Ugh, my posts are more confusing than anything now; my theory of the minute is that the red screen problem is definitely associated with models of 0x11000 size and greater -- adding a non-glove weapon to such a model will produce the red screen. By "0x11000 size" here, I'm talking about models for which the pointer would indicate a size of 0x11000, not the model's actual size.

I say this because now I've got a normal Serge who gets the red screen if not assigned a glove weapons pack. I can give him swallows and it'll red screen now, because I've specified pointers leaving 0x11000 bytes' worth of room for the model. :)

I consider this slightly promising, at least for the prospect of playable Dario, Slash, Flea, and Ozzie. I'm toying with the idea of trimming down Dark Serge's model by getting rid of the "vestigial data that doesn't matter" (VDDM) section of the model, and seeing if I can get rid of a few sectors that way.

It should be noted that in the Viper example I used earlier to "prove" myself wrong that it was a size issue, Viper's model is smaller in terms of bytes than Dark Serge's; the total space devoted to Viper's weapon model comes mostly from the weapons pack. Ugh, confuzzling.

If I have immediate success getting Slash, Flea, Ozzie, and (hopefully) Dario playable, I'll chalk the Dark Serge problems up to a technical limitation of the routine used to load up player character models I guess. I'm still not quite satisifed with that explanation because it would be weird (?) for the game engine to use two separate routines for loading player models v. enemy models.
Title: Re: Chrono Cross Pointer Investigation
Post by: MDenham on December 22, 2008, 05:16:21 am
I suspect the limit is actually 0x10000 (64kB) for reasons that would be relatively obvious to anyone used to programming.

As far as the simple explanation...  there's only two bytes allowed for any pointer within a file, essentially.  (Exceptions are made for weapons packs for some reason, however.)
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 22, 2008, 08:15:18 pm
Aha, interesting. The models themselves can go over the 0x10000 limit, but no weapons can be attached to them (i.e., they must be assigned the "glove" weapon pack). That's my theory for the time being at least -- if I can get Flea, Slash, and Ozzie working using the knowledge we've gained so far, it will seem even more likely that that's the case. How the

Trying Dario out is going to be extremely interesting because he's got a double texture. The loading routine used for player characters has proven pretty resilient so far, so it might just work. Plus, Dario loads fine with Doppelgang whereas we could never get Dark Serge in the party that way -- I suppose Doppelgang uses the same loading routine that loads the player charactrs.

EDIT:
Well, I'll be damned! Look at this:
http://www.youtube.com/watch?v=_TRvrdHVAlU

It just so happens that regular attack animations are extrinsically applied to the model just like the techs! Argh! Defense, run away, and Element-casting animations are intrinsic to the model, but not innate techs (which was expected) and regular physical attacks. Flea's trying to attack with a damn swallow here. I've ruled out the possibility that it's because Serge is equipped with a swallow -- I used a gameshark code to give Serge a glove weapon. That was fairly useless anyways, seeing as the Magus Unmasked project pretty much proved that there's no animations associated with the weapons themselves.

Before shifting back to Chrono Trigger stuff, I'm going to test out Dario and hope like hell his texture works. Just the thought of it not working is giving me the creeps.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 22, 2008, 09:53:22 pm
YEEEAH, BABY!
http://www.youtube.com/watch?v=Y1Paj0r_DLw

Biggest success we've had so far in this thread. Surefire visual proof that not only have we hit paydirt in general with the Table of Contents, but that the game engine already handles dual textures for player characters. As expected, he's trying to execute Serge's swallow movements, which are probably applied externally to the model from some data we haven't studied yet.

Note: To get enemy textures working correctly, one *must* custom-build the texture to include the header normally appearing in the first 16 bytes of a player character's texture hex code. You can see glitches in Flea's and Dario's textures coinciding with the eyeblink -- that's because I still need to "custom fake" the eyeblink texture. Should work theoretically to get the texture working perfectly, but that's lower priority at the moment. The fact that enemy textures do not need the extra 16 bytes' worth of header pointers is proof that the routine that loads enemy models is different from that which loads player character models.

I was saving my celebratory pics for the instance in which we created a working Dark Serge hack, but this point in our research will suffice because it's a huge relief to me.
(http://img504.imageshack.us/img504/3012/dryst001af1.jpg)
(http://img504.imageshack.us/img504/8124/dryst002li2.jpg)

One fun fact about Dario's battle model is that his Masamune is incorporated into the model itself -- he actually has a glove weapons pack. So we haven't yet proven that the player character load routine can load both an enemy model and an enemy weapon. Tonight's final experiment will focus on Slash so as to eliminate the possibility that there's a "model with weapon" limitation on using enemy models.
Title: Re: Chrono Cross Pointer Investigation
Post by: Vehek on December 22, 2008, 10:03:12 pm
As far as the simple explanation...  there's only two bytes allowed for any pointer within a file, essentially.  (Exceptions are made for weapons packs for some reason, however.)
I'm not sure if this is right. The Character Battle Models documentation seems to show four bytes for the offsets in the header. Also, while it's not an individual file, Dario's field model is 79,728 bytes.
Title: Re: Chrono Cross Pointer Investigation
Post by: ZeaLitY on December 22, 2008, 10:53:58 pm
(http://chronofan.com/Zeality/Grimmjow___wip2_by_bucs3191.jpg)

(http://chronofan.com/Zeality/463bcec3c55fb9d6504e92fa36d3e72f.png)

(http://chronofan.com/Zeality/a6bec9ac4163e33afeef10e7cdc2c174.jpg)

Been a while since we've done this. Those Jester fan pieces are fantastic.
Title: Re: Chrono Cross Pointer Investigation
Post by: MDenham on December 23, 2008, 12:45:42 am
As far as the simple explanation...  there's only two bytes allowed for any pointer within a file, essentially.  (Exceptions are made for weapons packs for some reason, however.)
I'm not sure if this is right. The Character Battle Models documentation seems to show four bytes for the offsets in the header. Also, while it's not an individual file, Dario's field model is 79,728 bytes.
Well, there's two possibilities:

* Each individual section is limited to 64k; or
* The whole file is limited to 64k, and four bytes are used for architecture reasons.

Right now, either one seems equally likely.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 23, 2008, 12:54:06 am
I should note that Dario's texture is 0x10800 bytes and loads fine as shown.

Recently found out that enemy models can use weapons just fine, provided they were assigned a weapon originally of course. Barring the model length dilemma, of course. Slash works just like he should.
http://www.youtube.com/watch?v=KT6qemexlJ0

I'm having some difficulties though -- I haven't been able to successfully point to models at the end of the ISO like Vehek has for his field model tests. Also, the Time Devourer's freezing up for me. Hopefully my ISO is just borked from all the testing.

While we don't have a nice character-to-enemy mod to show for the recent developments, we've found out lots of important things along the way, so this was a successful venture. Before we can use enemy models perfectly, we'll need to finish investigation of the Chrono Cross model format and then move on to in-depth investigation of other types of data. Vehek's already got a head start on fieldscript.
Title: Re: Chrono Cross Pointer Investigation
Post by: Vehek on December 23, 2008, 01:05:50 am
I'm having some difficulties though -- I haven't been able to successfully point to models at the end of the ISO like Vehek has for his field model tests.
Where were you putting them? I put my tests starting at sector 0x4C6DC.
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 23, 2008, 01:34:55 am
Yeah, I used sector 0x4C6DC as my starting point as well. However, I've been testing exclusively battle models. It's also possible I made a mistake or something; I've kind of defaulted to testing with artificially-made room left over from deleting Guile's model. Not a long term solution obviously...
Title: Re: Chrono Cross Pointer Investigation
Post by: Cyberman on December 27, 2008, 07:34:58 pm
Well I see someone is back to some good... I suppose if these threads could be organized I don't know what I would call them myself.

I'm not positive but if sections were limited to 64K this would make sense in some way.  This limits pointers within the section to be 16 bits instead of 32 bits.  If pointers were to DWORD sized entities (PSX was a 32 bit machine and alignment was generally kept to that), it still would be easier to use 16 bit pointers (simpler instruction sequence).

Thoughts of the day .. or moment.

Cyb
Title: Re: Chrono Cross Pointer Investigation
Post by: FaustWolf on December 27, 2008, 07:46:05 pm
Hey, Cyb! The pointers are definitely three bytes long, plus an extra byte to denote the padding between the end of a file and the start of the next sector if that's consequential in any way. I suspect CC's table of contents works similarly to Xenogears' seeing as both are Square games and both have TOCs starting at address 0xC000 IIRC. But maybe that's industry standard for PSX.

Yeah, the Cross investigation threads have become slightly discombobulated, so I'll make a separate model thread when I get new discoveries wikified and begin working on the animation format.
Title: Re: Chrono Cross Pointer Investigation
Post by: Cyberman on December 28, 2008, 12:41:18 am
It's too bad one can make sub threads for these. I thought I was referring to pointers within a file (sigh) anyhow my 'cool' code I developed with virtual addressing of the data etc. etc.  Died horribly because I likely got too fancy with how I was doing things.  C++ is great as long as things don't get too obfuscated (the latter is what happened I suspect).

Let me dig a bit and see if I can remember a few things. I know I was able to get to the point of finding files with reasonable accuracy (reading them was the problem).

Cyb
Title: Re: Chrono Cross Pointer Investigation
Post by: MDenham on December 28, 2008, 04:16:37 am
Hey, Cyb! The pointers are definitely three bytes long, plus an extra byte to denote the padding between the end of a file and the start of the next sector if that's consequential in any way. I suspect CC's table of contents works similarly to Xenogears' seeing as both are Square games and both have TOCs starting at address 0xC000 IIRC. But maybe that's industry standard for PSX.
It's actually standard layout for a CD.  The thing is - as should be obvious if you've ever tried to look at the CDs using Windows Explorer - the discs are essentially multi-session discs, where all of the game data is in the second session (and Windows only likes to show the first session of multi-session discs).

I'm not sure if the game would properly handle the discs being redone as single-session discs, though.  It might be worth looking into to make things easier to work with (as we'd get filenames for everything on the disc, assuming they're still on the disc).
Title: Re: Chrono Cross Pointer Investigation
Post by: Cyberman on December 28, 2008, 02:54:08 pm
I would have to look into multisession information which book is that contain in the ISO9660 spec?

Cyb
Title: Re: Chrono Cross Pointer Investigation
Post by: MDenham on December 29, 2008, 04:18:43 am
I would have to look into multisession information which book is that contain in the ISO9660 spec?

Cyb
It'd be somewhere in the Orange Book (which is where mixed audio/data CDs lie as well).