Chrono Cross Pointer Investigation

[FaustWolf]

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.

[MDenham]

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.)

[FaustWolf]

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.

[FaustWolf]

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.



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.

[Vehek]

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.

[ZeaLitY]

Been a while since we've done this. Those Jester fan pieces are fantastic.

[MDenham]

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.

[FaustWolf]

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.

[Vehek]

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.

[FaustWolf]

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...

[Cyberman]

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

[FaustWolf]

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.

[Cyberman]

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

[MDenham]

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).

[Cyberman]

I would have to look into multisession information which book is that contain in the ISO9660 spec?

Cyb