Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
1
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: May 09, 2009, 01:09:40 am »
Have we broken open section 3 of the models yet? It's not in the wiki (other than the fact that it affects shading and model positioning), and a quick search over the forums didn't turn up anything useful, so I did some poking around in there over the last couple of days. I think I've managed to figure out a fair bit of this section from examining Serge, Kid, and Guile's models. Here's what I've got. (If we DO already have this and I just missed it, let me know so I can delete this post. It's kinda long, probably due to my tendency to ramble.)
Section 3 is 0x160 bytes long, no matter how complex the model is. It seems to have three distinct segments of constant lengths, so it doesn't have any sort of header.
The first 0x100 bytes of it define points around the model. Each point is made up of 8 byte long chunks which look something like this:
XX XX YY YY ZZ ZZ AA AA
The X's, Y's, and Z's define a coordinate in 3D space like we've already seen in section 2 (as well as pretty much the same thing in section 4). As I've said before, I have problems thinking in 3D, so I may have the axes out of order. (I'm guessing it's the same order as section 2, but I could be wrong.) The A's contain the ID of whatever articulation the coordinate is relative to.
A few of these are in roughly the same position on all the models I've looked at. (Remember that I'm getting this from Serge, Kid, and Guile. These are, notably, humanoid models. Non-humanoids like Poshul or Pip might differ.) Here are the indexes of the coordinates, which are useful in the third segment. Multiply them by 8 to get the actual offsets into section 3:
00 - Top of head
01 - Front of face
02 - Neck
03 - Right shoulder
04 - Left shoulder
05 - Right elbow
06 - Left elbow
07 - Right hand
08 - Left hand
09 - Waist
0A - Right knee
0B - Left knee
0C - Right ankle
0D - Left ankle
0x0E defines the height the camera sits at when it rotates around the character during their idle animation. Only the vertical component of this one seems to matter.
0x0F defines the distance between the character and whatever enemy they happen to be attacking at the time. Only one of the horizontal axes seems to matter here, and only the magnitude of the distance, not its direction, so you can't do something funny like have the character go charging past their opponent in preparation for an attack. Um, not that that was the first thing I tried or anything.
0x10 is located on the upper center of the model's torso.
0x11 is relative to the right hand on Serge, Kid, and Guile, but seems to sit a distance off from it, and I can't tell if it's roughly the same distance or direction. This seems so out of place that part of me wants to believe that this defines a distance like 0x0E and 0x0F, but I haven't been able to determine what it affects, if anything.
The indexes from here are dependent on the model and seem a tad chaotic. On Serge's model, 0x12 sits directly on the weapon articulation. Guile has an entry exactly like this, but it's the very last one in the section at index 0x1F. Kid has no corresponding entry, as she has no weapon articulation. (Or at least, none that I could find. She's got an articulation directly after the right hand where the weapon is on Serge, Guile, and Lynx, but it doesn't seem to actually affect anything.) There's a lot of entries made up entirely of 0s here, with some other entries tossed in towards the end. Only the one Guile has at 0x1F has any significance that I've figured out yet.
I'm going to jump the second segment here and come back to it in a minute. The third segment is fairly short, anyways.
The third segment begins somewhere around 0x120 bytes in. I can't make this segment's length make sense no matter how much I look at it, so I might be missing something, but what I've got seems to make sense. This segment is made of 8 byte long coordinates pretty much exactly like the ones in the first segment, in the form XXXX YYYY ZZZZ AAAA with the exception that the AA AA bytes are now indexes into the list of coordinates defined by segment one. For example, if one coordinate here was 0000 0000 0000 0700 then it would sit directly on the right hand coordinate.
The only part of the third segment that I've managed to assign any importance to is the coordinate that begins 0x1A bytes from the end of section 3. The game attaches the character's weapon to the coordinate defined here. By changing what coordinate in segment 1 this points to, we could, say, make Kid a lefty.
Alright, back to the second segment, which defines the model's shading. Segment 2 is 0x20 bytes long, divided into 0x4 byte chunks. There are 8 chunks, but the amount that actually do anything is dependent on the model. For each that's actually used, it controls the shading to a specific part of the model. For example, Serge only uses two of them, one of which affects the area of his shirt below the belt, and one of which affects everything else. Kid is similar, having one chunk for her skirt and one chunk for the rest of the model.
Each chunk is of the form
RR GG BB EF
where RR, GG, and BB define how red, green, and blue, the model should be. The neutral value for these is 0x80. Higher values tint the model more of that color, lower values tint the model less of that color.
E and F are the fun parts. It's one byte, but the 4 highest order bits and the 4 lowest order bits (in other words, the first digit and second digit) control different things.
E controls what texture (if any) gets drawn over the model's normal one. Here's what the individual values do: (A lot of these look the same to me. There may be subtle variations between some of the "identical" ones, but I didn't see them.)
0 - Normal
1 - Normal
2 - Highly reflective
3 - Highly reflective
4 - Reflective
5 - Reflective
6 - Reflective
7 - Reflective
8 - Normal
9 - Normal
A - Weird texture application (Looks like this could be Serge's normal texture, just applied in a weird way.)
B - Weird texture application
C - Garbage texture (This one isn't static, it changes every frame. If I had to guess, I'd say it's supposed to point to a texture loaded by an attack or tech, but which is simply garbage normally.)
D - Garbage texture
E - Garbage texture
F - Garbage texture
F controls the model's transparency and a related effect or two. Here comes the list:
0 - Solid
1 - Invisible
2 - Transparent
3 - Invisible
4 - Solid
5 - Invisible
6 - Transparent and bright
7 - Invisible
8 - Solid
9 - Invisible
A - Transparent and inverted
B - Invisible
C - Solid
D - Invisible
E - Transparent and very faint
F - Invisible
Combining these can be interesting. For example, here's Serge made of glass.
And wow was THAT longer than I anticipated. Let me know if I'm being redundant by posting this or if anything needs clarification.
Section 3 is 0x160 bytes long, no matter how complex the model is. It seems to have three distinct segments of constant lengths, so it doesn't have any sort of header.
The first 0x100 bytes of it define points around the model. Each point is made up of 8 byte long chunks which look something like this:
XX XX YY YY ZZ ZZ AA AA
The X's, Y's, and Z's define a coordinate in 3D space like we've already seen in section 2 (as well as pretty much the same thing in section 4). As I've said before, I have problems thinking in 3D, so I may have the axes out of order. (I'm guessing it's the same order as section 2, but I could be wrong.) The A's contain the ID of whatever articulation the coordinate is relative to.
A few of these are in roughly the same position on all the models I've looked at. (Remember that I'm getting this from Serge, Kid, and Guile. These are, notably, humanoid models. Non-humanoids like Poshul or Pip might differ.) Here are the indexes of the coordinates, which are useful in the third segment. Multiply them by 8 to get the actual offsets into section 3:
00 - Top of head
01 - Front of face
02 - Neck
03 - Right shoulder
04 - Left shoulder
05 - Right elbow
06 - Left elbow
07 - Right hand
08 - Left hand
09 - Waist
0A - Right knee
0B - Left knee
0C - Right ankle
0D - Left ankle
0x0E defines the height the camera sits at when it rotates around the character during their idle animation. Only the vertical component of this one seems to matter.
0x0F defines the distance between the character and whatever enemy they happen to be attacking at the time. Only one of the horizontal axes seems to matter here, and only the magnitude of the distance, not its direction, so you can't do something funny like have the character go charging past their opponent in preparation for an attack. Um, not that that was the first thing I tried or anything.
0x10 is located on the upper center of the model's torso.
0x11 is relative to the right hand on Serge, Kid, and Guile, but seems to sit a distance off from it, and I can't tell if it's roughly the same distance or direction. This seems so out of place that part of me wants to believe that this defines a distance like 0x0E and 0x0F, but I haven't been able to determine what it affects, if anything.
The indexes from here are dependent on the model and seem a tad chaotic. On Serge's model, 0x12 sits directly on the weapon articulation. Guile has an entry exactly like this, but it's the very last one in the section at index 0x1F. Kid has no corresponding entry, as she has no weapon articulation. (Or at least, none that I could find. She's got an articulation directly after the right hand where the weapon is on Serge, Guile, and Lynx, but it doesn't seem to actually affect anything.) There's a lot of entries made up entirely of 0s here, with some other entries tossed in towards the end. Only the one Guile has at 0x1F has any significance that I've figured out yet.
I'm going to jump the second segment here and come back to it in a minute. The third segment is fairly short, anyways.
The third segment begins somewhere around 0x120 bytes in. I can't make this segment's length make sense no matter how much I look at it, so I might be missing something, but what I've got seems to make sense. This segment is made of 8 byte long coordinates pretty much exactly like the ones in the first segment, in the form XXXX YYYY ZZZZ AAAA with the exception that the AA AA bytes are now indexes into the list of coordinates defined by segment one. For example, if one coordinate here was 0000 0000 0000 0700 then it would sit directly on the right hand coordinate.
The only part of the third segment that I've managed to assign any importance to is the coordinate that begins 0x1A bytes from the end of section 3. The game attaches the character's weapon to the coordinate defined here. By changing what coordinate in segment 1 this points to, we could, say, make Kid a lefty.
Alright, back to the second segment, which defines the model's shading. Segment 2 is 0x20 bytes long, divided into 0x4 byte chunks. There are 8 chunks, but the amount that actually do anything is dependent on the model. For each that's actually used, it controls the shading to a specific part of the model. For example, Serge only uses two of them, one of which affects the area of his shirt below the belt, and one of which affects everything else. Kid is similar, having one chunk for her skirt and one chunk for the rest of the model.
Each chunk is of the form
RR GG BB EF
where RR, GG, and BB define how red, green, and blue, the model should be. The neutral value for these is 0x80. Higher values tint the model more of that color, lower values tint the model less of that color.
E and F are the fun parts. It's one byte, but the 4 highest order bits and the 4 lowest order bits (in other words, the first digit and second digit) control different things.
E controls what texture (if any) gets drawn over the model's normal one. Here's what the individual values do: (A lot of these look the same to me. There may be subtle variations between some of the "identical" ones, but I didn't see them.)
0 - Normal
1 - Normal
2 - Highly reflective
3 - Highly reflective
4 - Reflective
5 - Reflective
6 - Reflective
7 - Reflective
8 - Normal
9 - Normal
A - Weird texture application (Looks like this could be Serge's normal texture, just applied in a weird way.)
B - Weird texture application
C - Garbage texture (This one isn't static, it changes every frame. If I had to guess, I'd say it's supposed to point to a texture loaded by an attack or tech, but which is simply garbage normally.)
D - Garbage texture
E - Garbage texture
F - Garbage texture
F controls the model's transparency and a related effect or two. Here comes the list:
0 - Solid
1 - Invisible
2 - Transparent
3 - Invisible
4 - Solid
5 - Invisible
6 - Transparent and bright
7 - Invisible
8 - Solid
9 - Invisible
A - Transparent and inverted
B - Invisible
C - Solid
D - Invisible
E - Transparent and very faint
F - Invisible
Combining these can be interesting. For example, here's Serge made of glass.
And wow was THAT longer than I anticipated. Let me know if I'm being redundant by posting this or if anything needs clarification.
2
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: April 17, 2009, 03:36:12 pm »
Sorry progress on that has been scarce recently. With the end of the semester coming up, my professors have been piling on a lot more than they did previously.
I'm gonna try to get some decent work done this afternoon. So far I have the idle, ready to attack, and attack animations done. I need to clean those up, but are there any other animations I should move while I'm at it?
I'm gonna try to get some decent work done this afternoon. So far I have the idle, ready to attack, and attack animations done. I need to clean those up, but are there any other animations I should move while I'm at it?
3
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: March 27, 2009, 03:12:42 pm »
I'll certainly give it a shot!
4
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: March 27, 2009, 12:30:47 pm »Hahah awesome vid dude.
*bow* Glad you enjoyed it!
Alright, here's something just a tad more practical than (if, perhaps, not as much fun as) my last video. I decided to try moving a couple of animations from Serge over to Kid. Aside from copying the data, this required inserting additional commands into the first frame so that the commands from Serge would be applied to the proper articulations on Kid's model. (For example, Kid's hair, including the braid, has nine articulations which have no corresponding part on Serge's model. 0xC bytes of extra commands for each articulation had to be inserted at the correct spot in the first frame to prevent these articulations from getting commands intended for the arms.) I also had to modify the animated articulation identifier (which needs a name that's easier to type, dang it!) so that the commands in later frames would apply to the proper parts of Kid's model. This generally meant sticking extra zeroes in the binary anywhere I had to put extra commands in the first frame.
This experiment falls fully under the heading of "stuff I do because I want to see if I can do it," but I feel like it's a decent demonstration of the sort of stuff we can do with our current knowledge of the animation format anyways.
5
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: March 21, 2009, 02:35:01 pm »
Alrighty, then. After a good night's sleep and with my blood/caffeine ratio well on its way to zero, I'm ready to try writing up what I know about the animation format. Some of this has already been mentioned in this thread, but I'll go ahead and write it up again (or use copy and paste, hehe) so it's all in one place. Let me know if any of this is unclear, contradictory, needs further explaining, etc. Here goes.
Animation format:
Number of frames (4 bytes)
Pretty self-explanatory
Animated articulation identifier (? bytes)
Just a placeholder name since I don't know what to call these. The length of this part seems to be dependent on the model, possibly the first multiple of 4 that allows it to contain two bits for every articulation in the model. (I'll look into that. I didn't notice that it was different for Serge and Kid until just now.) Serge has 8 bytes here, Kid has 0xC. This set of bytes tells the game which of the character's articulations will be animated by commands in frames after the first. I'll use Serge's idle animation (which has 5665600015150000 for this segment) as an example of how to read them.
First read the bytes in little endian order, so they become 0000151500606556. Then convert them to binary, which makes them
0000000000000000000101010001010100000000011000000110010101010110.
This is much easier to work with if you reverse the order and put the least significant bit on the left, making it
0110101010100110000001100000000010101000101010000000000000000000.
From here, I generally split them into two rows, with even-numbered bits on top and odd-numbered bits on bottom. The set we're working with looks like this:
ABCDEFGHIJKLMNOPQRSTUVW
01111101000100001110111000000000
10000010001000000000000000000000
The letters I've placed above the binary there represent which of Serge's articulations each column applies to. A 1 in the top row indicates that that articulation will be given rotation commands in later frames of the animation, while a 1 in the bottom row indicates that it will be given translation commands. In other words, articulations B, C, D, E, F, H, L, Q, R, S, U, V, and W will be rotated in the animation, and A, G, and K will be translated.
Frame pointers (4 bytes each)
The pointers are relative to the start of the animation header. Not much else to be said about them.
Frames of animation (Variable length. See below.)
Would you believe this is the easy part? The commands given to articulations in the animation are basically identical to the way that the model's "skeleton" was set up in Section 2. Each command will be 6 bytes long, 2 bytes for each axis. The order of the axes is probably XYZ, as it was in section 2, but I have a hard time thinking in 3D, so anyone's welcome to double check that. The values the command can take range between 0xF000 and 0xFFF, or -4096 to 4095. In the case of rotations, 4096 means 360 degrees.
First frame of animation ( (0xC * # of articulations in the model) bytes)
The first frame of the animation gives two commands to each articulation of the model, presumably in the order that the articulations were defined in Section 2 of the model. Each articulation has 0xC bytes of commands given to it here - 6 bytes of rotation commands followed by 6 bytes of translation commands. The rotations and translations are relative to the model's "default" position as it was set in Section 2.
Other frames of animation ( (6 * # of 1s in the binary of the animated articulation identifier) bytes each)
For each frame after the first, the animation contains only the commands that were defined in the animated articulation identifier, starting with articulation A's rotation, then its translation, then B's rotation, then its translation, etc. For the example of Serge's idle animation given above, the first command in each frame in this section will be the translation command for articulation A, the second command will be the rotation for articulation B, the third command will be the rotation for articulation C, and so on. Note that each command is still relative to the positioning of the articulation in the model's default position (how it was set in Section 2). They are NOT relative to the position of the model in the first frame of the animation or the previous frame of the animation.
Assorted notes
The animations in game don't ever seem to give an articulation both rotations and translations in a given animation. In addition, it seems that any articulation that was translated or rotated at all in the first frame of an animation is always marked in the animated articulation identifier, and therefore always appears in frames of animation after the first. Both of these appear to be quirks of either convention or whatever program Square was using to animate the models. The game's engine doesn't seem to have a problem with articulations receiving both rotation and translation commands, and it's very possible to set an articulation's position in the first frame of animation and lock it there for the duration of the animation by not marking it in the animated articulation identifier. I used the second trick pretty frequently in my demo video.
EDIT: I accidentally gave my explanation of the articulation identifier as though Serge's was 0xC bytes long, when it's actually 8. Way too many zeroes in there. Corrected.
Animation format:
Number of frames (4 bytes)
Pretty self-explanatory
Animated articulation identifier (? bytes)
Just a placeholder name since I don't know what to call these. The length of this part seems to be dependent on the model, possibly the first multiple of 4 that allows it to contain two bits for every articulation in the model. (I'll look into that. I didn't notice that it was different for Serge and Kid until just now.) Serge has 8 bytes here, Kid has 0xC. This set of bytes tells the game which of the character's articulations will be animated by commands in frames after the first. I'll use Serge's idle animation (which has 5665600015150000 for this segment) as an example of how to read them.
First read the bytes in little endian order, so they become 0000151500606556. Then convert them to binary, which makes them
0000000000000000000101010001010100000000011000000110010101010110.
This is much easier to work with if you reverse the order and put the least significant bit on the left, making it
0110101010100110000001100000000010101000101010000000000000000000.
From here, I generally split them into two rows, with even-numbered bits on top and odd-numbered bits on bottom. The set we're working with looks like this:
ABCDEFGHIJKLMNOPQRSTUVW
01111101000100001110111000000000
10000010001000000000000000000000
The letters I've placed above the binary there represent which of Serge's articulations each column applies to. A 1 in the top row indicates that that articulation will be given rotation commands in later frames of the animation, while a 1 in the bottom row indicates that it will be given translation commands. In other words, articulations B, C, D, E, F, H, L, Q, R, S, U, V, and W will be rotated in the animation, and A, G, and K will be translated.
Frame pointers (4 bytes each)
The pointers are relative to the start of the animation header. Not much else to be said about them.
Frames of animation (Variable length. See below.)
Would you believe this is the easy part? The commands given to articulations in the animation are basically identical to the way that the model's "skeleton" was set up in Section 2. Each command will be 6 bytes long, 2 bytes for each axis. The order of the axes is probably XYZ, as it was in section 2, but I have a hard time thinking in 3D, so anyone's welcome to double check that. The values the command can take range between 0xF000 and 0xFFF, or -4096 to 4095. In the case of rotations, 4096 means 360 degrees.
First frame of animation ( (0xC * # of articulations in the model) bytes)
The first frame of the animation gives two commands to each articulation of the model, presumably in the order that the articulations were defined in Section 2 of the model. Each articulation has 0xC bytes of commands given to it here - 6 bytes of rotation commands followed by 6 bytes of translation commands. The rotations and translations are relative to the model's "default" position as it was set in Section 2.
Other frames of animation ( (6 * # of 1s in the binary of the animated articulation identifier) bytes each)
For each frame after the first, the animation contains only the commands that were defined in the animated articulation identifier, starting with articulation A's rotation, then its translation, then B's rotation, then its translation, etc. For the example of Serge's idle animation given above, the first command in each frame in this section will be the translation command for articulation A, the second command will be the rotation for articulation B, the third command will be the rotation for articulation C, and so on. Note that each command is still relative to the positioning of the articulation in the model's default position (how it was set in Section 2). They are NOT relative to the position of the model in the first frame of the animation or the previous frame of the animation.
Assorted notes
The animations in game don't ever seem to give an articulation both rotations and translations in a given animation. In addition, it seems that any articulation that was translated or rotated at all in the first frame of an animation is always marked in the animated articulation identifier, and therefore always appears in frames of animation after the first. Both of these appear to be quirks of either convention or whatever program Square was using to animate the models. The game's engine doesn't seem to have a problem with articulations receiving both rotation and translation commands, and it's very possible to set an articulation's position in the first frame of animation and lock it there for the duration of the animation by not marking it in the animated articulation identifier. I used the second trick pretty frequently in my demo video.
EDIT: I accidentally gave my explanation of the articulation identifier as though Serge's was 0xC bytes long, when it's actually 8. Way too many zeroes in there. Corrected.
6
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: March 21, 2009, 03:22:58 am »
I think I've just about got the animation format whipped. (Actually animating...not so much. ) The format doesn't actually seem very complicated, but it doesn't look like anyone's posted a full explanation yet, so I'll do that tomorrow. Sorry, I'd do it tonight, but it's late and I'm likely to mess up if I'm this tired. For now I'll leave you with a little demo I spent the last couple of days working on. It was supposed to be something silly and simple to see how well I really understood the animation format...and it ended up eating three days whole and not looking half as good as I'd have liked. Well, at least it's something. Enjoy.
) The format doesn't actually seem very complicated, but it doesn't look like anyone's posted a full explanation yet, so I'll do that tomorrow. Sorry, I'd do it tonight, but it's late and I'm likely to mess up if I'm this tired. For now I'll leave you with a little demo I spent the last couple of days working on. It was supposed to be something silly and simple to see how well I really understood the animation format...and it ended up eating three days whole and not looking half as good as I'd have liked. Well, at least it's something. Enjoy.
7
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: March 17, 2009, 02:43:37 pm »
Not sure if I saved them right, but try these, Dark Serge.
8
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: February 14, 2009, 04:49:44 pm »
I've only actually tested that for Serge, Dario, and Dark Serge, but I was able to predict where Dario and Dark Serge's files would be by doing some fast math based on the order of the models ( (Target's model file - Serge's model file) / 3 + 3760) so I would assume the pattern holds for pretty much everyone, including the dummies. I can do some more checking on that to be double sure if you want.
EDIT: Ah, I'm gonna have to be away from my computer for a few hours, so I can do bit more checking to make sure the pattern holds, but it'll have to be later. Sorry.
EDIT 2: Alright, sorry that took so long. I did some more random testing and the correct .out was always where I predicted it would be. I think it's safe to say that the attack drps (what I'm calling those files for the moment, given that at least part of the data in them seems to be related to attacks and they all start with "drp," same as the first file of each element/tech) follow the same order as the models.
Here's something weird, though. You know how some of the model files are just "It's CD Make Dummy!"? The attack files that correspond to those aren't dummies themselves. I can't figure out what that means.
EDIT: Ah, I'm gonna have to be away from my computer for a few hours, so I can do bit more checking to make sure the pattern holds, but it'll have to be later. Sorry.
EDIT 2: Alright, sorry that took so long. I did some more random testing and the correct .out was always where I predicted it would be. I think it's safe to say that the attack drps (what I'm calling those files for the moment, given that at least part of the data in them seems to be related to attacks and they all start with "drp," same as the first file of each element/tech) follow the same order as the models.
Here's something weird, though. You know how some of the model files are just "It's CD Make Dummy!"? The attack files that correspond to those aren't dummies themselves. I can't figure out what that means.
9
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: February 14, 2009, 04:34:46 pm »
The trick to the attack animations was figuring out where they are. Now that we know that, getting them to work properly is really just moving a bit more data and fixing one more pointer.
Unfortunately, the proper animations being applied doesn't fix Dark Serge. It's still red-screening when I try to give him his weapon.
Unfortunately, the proper animations being applied doesn't fix Dark Serge. It's still red-screening when I try to give him his weapon.
10
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: February 14, 2009, 04:18:39 pm »
Confirmed: Dark Serge works just fine if you give him gloves instead of a real weapon. Fear the power of my imaginary scythe, you fiends!
11
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: February 13, 2009, 12:40:13 pm »
utunnels, I actually tried that, but it seems that pSX's savestates don't decompress nicely like ePSXe's and PCSX's do. It would be the frustrating emulator that works for me, wouldn't it? 
Faust, I've attached a zip with a pair of VRAM dumps in it, one with Dario alone and one with Kid in the party. I don't have a save far enough along to even have Sprigg at this point, so I'm going to go hunting around online and see what I can dig up. What I've got right now should at least verify or discredit the theory that Dario's texture is taking up space that's normally used for the second party member's.
Come to think of it, is there a trick to making Dario doppelgang-able? He doesn't show up on any of the lists I've looked at, although it's possible they're incomplete.
Faust, I've attached a zip with a pair of VRAM dumps in it, one with Dario alone and one with Kid in the party. I don't have a save far enough along to even have Sprigg at this point, so I'm going to go hunting around online and see what I can dig up. What I've got right now should at least verify or discredit the theory that Dario's texture is taking up space that's normally used for the second party member's.
Come to think of it, is there a trick to making Dario doppelgang-able? He doesn't show up on any of the lists I've looked at, although it's possible they're incomplete.
12
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: February 12, 2009, 10:39:38 pm »
Unfortunately, I'm not much good for VRAM dumps at this point. I've been doing all my modifications in 2048 byte/sector isos, and I can't get anything but pSX to run them. ePSXe and PCSX (as well as the debugger based on it) seem to choke and die even if I mount the iso on a virtual drive. They run the 2352 byte/sector dump I made just fine, but I haven't been tinkering with that one.
Naturally, if there's a way to make pSX cough up the VRAM, I've never managed to find it. I hate to be unhelpful, but there's not a lot I can do right now. I'll keep fiddling with it and see if I can make anything happen, but I can't do much more than hex edit and run the game for the moment.
Naturally, if there's a way to make pSX cough up the VRAM, I've never managed to find it. I hate to be unhelpful, but there's not a lot I can do right now. I'll keep fiddling with it and see if I can make anything happen, but I can't do much more than hex edit and run the game for the moment.
13
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: February 12, 2009, 08:24:10 pm »
I figured it had to be the dual texture taking up too much memory and being overwritten that was causing it. Maybe doppelgang loads the texture differently somehow? I don't know how much sense THAT would make, but it's all I can come up with.
14
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: February 11, 2009, 12:38:54 pm »
Slightly better video up. This one was recording on my desktop, so there's sound and it's faster. I also threw in Dario's element casting animation, which I managed to forget in the last one. Since I recorded that one, I've fixed the problem with the background and menus being destroyed. Turns out that I slipped up when I was putting together Dario's texture header. Whoops.
Naturally, nothing's ever TOO easy. Using Dario with anyone else in the party can have some...interesting results: (Click for larger image.)
Well, heck, I'D wear a cape with Kid's face on it!
Naturally, nothing's ever TOO easy. Using Dario with anyone else in the party can have some...interesting results: (Click for larger image.)
Well, heck, I'D wear a cape with Kid's face on it!
15
Chrono Cross Modification / Re: CHRONO CROSS MODEL PROJECT THREAD
« on: February 10, 2009, 06:16:08 pm »
Hmm, I suppose this is technically a double-post. Sorry about that.
Anyways, I had some spare time between classes today, so I decided to see what I could do with Dario. Basically, I cleared out Guile's model, moved Kid's backwards, and then put Dario's model in the space where Serge's was and repointed everything in the table of contents. FaustWolf, this is what you did (or is at least similar) to make your DarioTest video, right? I took it a step farther after that and overwrote the the mass of data containing Serge's attack animations (Among other things. I think the attack sounds may be in there, too...) with the equivalent mass for Dario. The results are here. I think I did something nasty to the system graphics and the background, but if you ignore that, we have an almost-playable Dario. This would confirm that the stuff I tripped over earlier does indeed contain the attack animations. Also, in case anyone's interested, the OUTs that contain the attacks seem to start at 3760.out, (This file contains Serge's attack animations, among other things.) and proceed in the same order as the battle models from there. This is how I found Dario's data.
Anyways, I had some spare time between classes today, so I decided to see what I could do with Dario. Basically, I cleared out Guile's model, moved Kid's backwards, and then put Dario's model in the space where Serge's was and repointed everything in the table of contents. FaustWolf, this is what you did (or is at least similar) to make your DarioTest video, right? I took it a step farther after that and overwrote the the mass of data containing Serge's attack animations (Among other things. I think the attack sounds may be in there, too...) with the equivalent mass for Dario. The results are here. I think I did something nasty to the system graphics and the background, but if you ignore that, we have an almost-playable Dario. This would confirm that the stuff I tripped over earlier does indeed contain the attack animations. Also, in case anyone's interested, the OUTs that contain the attacks seem to start at 3760.out, (This file contains Serge's attack animations, among other things.) and proceed in the same order as the battle models from there. This is how I found Dario's data.
Pages: [1] 2