V
Vehek
Guest
Well, I think we (the people from the Chrono Compendium) don't really know what a "quad" is.
- Status
F
FaustWolf
Guest
Heh heh. Very true, Vehek. :-D Visiting the Qhimm forums sure has been a learning experience!
We may luck out and not have to do the tracing Halkun suggests if I'm correct in my suspicion that model data is sandwiched between the texture files I'm examining. But that's a BIG if. Later on I'll get some data isolated (say, all of Serge or Kid's battle and weapon textures, with the possible model data in between) and post a download link here so everyone can take a look at it with me. I have yet to confirm that the data fulfills the conditions described by Cyberman above, but it looks promising.
BTW Cyb, when we're talking DWORDs, is that 32 bytes in length? Is word size hardware specific, i.e., should it be consistent across all PSX games?
We may luck out and not have to do the tracing Halkun suggests if I'm correct in my suspicion that model data is sandwiched between the texture files I'm examining. But that's a BIG if. Later on I'll get some data isolated (say, all of Serge or Kid's battle and weapon textures, with the possible model data in between) and post a download link here so everyone can take a look at it with me. I have yet to confirm that the data fulfills the conditions described by Cyberman above, but it looks promising.
BTW Cyb, when we're talking DWORDs, is that 32 bytes in length? Is word size hardware specific, i.e., should it be consistent across all PSX games?
Z
ZeaLitY
Guest
I checked out the battle field OUTs for the hell of it. As expected, they contain the battle field textures, and each is prefaced with a 3-byte descriptive header. The header seems to be quick romaji. For instance, "kumo" goes before the cloud texture. Anyway, after removing the TIMs from the source OUT file, around 53 kb is left. The OUT file starts with "DRP", so I'm assuming what's left are the field model box and texturing instructions. I've attached a chart of the TIMs and their corresponding headers, along with the remaining OUT file here.
F
FaustWolf
Guest
Now for a report on the potential battle model / weapon model data.
http://www.chronocompendium.com/Forums/index.php?action=dlattach;topic=4770.0;attach=1950
Firstly, the link is a zip containing a chunk of data from the CD image that I have named "ModelMine1." It's just raw hex data, and its beginning corresponds to a fresh sector (2048 bytes/sector as always) in the CD image. The data fall in this order: A header; Serge's battle model texture; Serge's eyeball texture; unknown data; Serge's first weapon model texture; unknown data; etc. Also inside the zip is a copy of my datamap for "ModelMine1," which I reproduce below. The chunk seems to be 11 sectors long exactly, if that means anything.
Also included in the zip are Serge's battle model texture, eyeball texture, and the seven weapon texture TIMs that occur within the ModelMine.
DATAMAP: All offsets given in hexadecimal notation.
00000000 ~ 0000000F: 16 byte header
00000010 ~ 0000823B: Serge Battle Texture
0000823C ~ 00009467: Serge Eyeball Blink Texture
00009468 ~ 000097FF: 00 Buffer Bytes
00009800 ~ 00014847: Unknown Data (Battle Model?)
00014848 ~ 00015DC7: Serge Weapon Texture 1
00015DC8 ~ 00016BE7: Unknown Data (Weapon Model?)
00016BE8 ~ 00018167: Serge Weapon Texture 2
00018168 ~ 00018C5F: Unknown Data (Weapon Model?)
00018C60 ~ 0001A1DF: Serge Weapon Texture 3
0001A1E0 ~ 0001AF0F: Unknown Data (Weapon Model?)
0001AF10 ~ 0001C48F: Serge Weapon Texture 4
0001C490 ~ 0001D2EF: Unkonown Data (Weapon Model?)
0001D2F0 ~ 0001E86F: Serge Weapon Texture 5
0001E870 ~ 0001F687: Unkknown Data (Weapon Model?)
0001F688 ~ 00020C07: Serge Weapon Texture 6
00020C08 ~ 00021897: Unknown Data (Weapon Model?)
00021898 ~ 00022E17: Serge Weapon Texture 7
00022E18 ~ 00023FFF: Unknown Data (Weapon Model?)
After this begins my ModelMine2 file, which contains Kid's suspected battle model and weapon model data. I'll post that later for comparison if anyone's interested.
SUSPECTED MODEL FILE INFO: The offsets and file lengths may actually be one byte too "short" depending on whether I'm interpreting the hex code correctly. For example, the First "Weapon Model" listed below is described as 3615 bytes long. If it makes more sense, feel free to interpret the file size as 3616 bytes.
First "Model" : 45127 bytes long. Header begins "06 00 00 00 20 00 00 00"
First "Weapon Model" : 3615 bytes long. Header begins "01 00 00 80 48 00 5E 00"
Second "Weapon Model" : 2807 bytes long. Header begins "01 00 00 80 39 00 46 00"
Third "Weapon Model" : 3375 bytes long. Header begins "01 00 00 80 43 00 58 00"
The weapon "models" are consistent in their first 8 bytes, which may constitute a model file header; the first 8 bytes for the weapon "models" read: 01 00 00 80 xx 00 xx 00 (where "xx" represents a byte position that varies in value among the "models")
My notes on the data were hastily scribed, so if anyone wants clarification on any point, please ask. Once again, the "ModelMine" for Serge's (suspected) battle and weapon models and all the associated textures are in the attached zip if anyone would like to investigate.
ADDENDUM: Also, a question for Halkun or anyone else who understands PlayStation design/architecture: Are PsyQ opcodes for the Playstation GPU actually planted amongst the game data? I'm interpreting Halkun's previous post about quads as saying that I should be able to see the applicable opcode just before the model geometry, TIM textures, etc. Am I understanding this correctly?
If GPU opcode *is* in with the game data, is it also in the SLUS file? If both the SLUS file and the data following the SLUS file on the game CD contain opcode, and that opcode features the same call functions, then perhaps I could view the call functions in the SLUS file in hex, determine their ASCII signature, and then find the call functions further on in the game CD as well, pointing to model data.
Does that make any sense whatsoever? I've yet to read the PlayStation design documents, but will begin doing so in the near future. Oh, and another question -- what "language" are the PsyQ opcodes written in? MIPS Assembly language?
http://www.chronocompendium.com/Forums/index.php?action=dlattach;topic=4770.0;attach=1950
Firstly, the link is a zip containing a chunk of data from the CD image that I have named "ModelMine1." It's just raw hex data, and its beginning corresponds to a fresh sector (2048 bytes/sector as always) in the CD image. The data fall in this order: A header; Serge's battle model texture; Serge's eyeball texture; unknown data; Serge's first weapon model texture; unknown data; etc. Also inside the zip is a copy of my datamap for "ModelMine1," which I reproduce below. The chunk seems to be 11 sectors long exactly, if that means anything.
Also included in the zip are Serge's battle model texture, eyeball texture, and the seven weapon texture TIMs that occur within the ModelMine.
DATAMAP: All offsets given in hexadecimal notation.
00000000 ~ 0000000F: 16 byte header
00000010 ~ 0000823B: Serge Battle Texture
0000823C ~ 00009467: Serge Eyeball Blink Texture
00009468 ~ 000097FF: 00 Buffer Bytes
00009800 ~ 00014847: Unknown Data (Battle Model?)
00014848 ~ 00015DC7: Serge Weapon Texture 1
00015DC8 ~ 00016BE7: Unknown Data (Weapon Model?)
00016BE8 ~ 00018167: Serge Weapon Texture 2
00018168 ~ 00018C5F: Unknown Data (Weapon Model?)
00018C60 ~ 0001A1DF: Serge Weapon Texture 3
0001A1E0 ~ 0001AF0F: Unknown Data (Weapon Model?)
0001AF10 ~ 0001C48F: Serge Weapon Texture 4
0001C490 ~ 0001D2EF: Unkonown Data (Weapon Model?)
0001D2F0 ~ 0001E86F: Serge Weapon Texture 5
0001E870 ~ 0001F687: Unkknown Data (Weapon Model?)
0001F688 ~ 00020C07: Serge Weapon Texture 6
00020C08 ~ 00021897: Unknown Data (Weapon Model?)
00021898 ~ 00022E17: Serge Weapon Texture 7
00022E18 ~ 00023FFF: Unknown Data (Weapon Model?)
After this begins my ModelMine2 file, which contains Kid's suspected battle model and weapon model data. I'll post that later for comparison if anyone's interested.
SUSPECTED MODEL FILE INFO: The offsets and file lengths may actually be one byte too "short" depending on whether I'm interpreting the hex code correctly. For example, the First "Weapon Model" listed below is described as 3615 bytes long. If it makes more sense, feel free to interpret the file size as 3616 bytes.
First "Model" : 45127 bytes long. Header begins "06 00 00 00 20 00 00 00"
First "Weapon Model" : 3615 bytes long. Header begins "01 00 00 80 48 00 5E 00"
Second "Weapon Model" : 2807 bytes long. Header begins "01 00 00 80 39 00 46 00"
Third "Weapon Model" : 3375 bytes long. Header begins "01 00 00 80 43 00 58 00"
The weapon "models" are consistent in their first 8 bytes, which may constitute a model file header; the first 8 bytes for the weapon "models" read: 01 00 00 80 xx 00 xx 00 (where "xx" represents a byte position that varies in value among the "models")
My notes on the data were hastily scribed, so if anyone wants clarification on any point, please ask. Once again, the "ModelMine" for Serge's (suspected) battle and weapon models and all the associated textures are in the attached zip if anyone would like to investigate.
ADDENDUM: Also, a question for Halkun or anyone else who understands PlayStation design/architecture: Are PsyQ opcodes for the Playstation GPU actually planted amongst the game data? I'm interpreting Halkun's previous post about quads as saying that I should be able to see the applicable opcode just before the model geometry, TIM textures, etc. Am I understanding this correctly?
If GPU opcode *is* in with the game data, is it also in the SLUS file? If both the SLUS file and the data following the SLUS file on the game CD contain opcode, and that opcode features the same call functions, then perhaps I could view the call functions in the SLUS file in hex, determine their ASCII signature, and then find the call functions further on in the game CD as well, pointing to model data.
Does that make any sense whatsoever? I've yet to read the PlayStation design documents, but will begin doing so in the near future. Oh, and another question -- what "language" are the PsyQ opcodes written in? MIPS Assembly language?
Last edited:
F
FaustWolf
Guest
I'm double-posting with full knowledge that such practices are discouraged. However, I feel it is necessary given the extraordinary length of my previous post.
I've found some very interesting ASCII blocks in Chrono Cross' SLUS file. First up...
Seems to be file paths. Is it possible that this is a signature left from the disc burning process, meaning there's MDE, FID, FND, and PRG files on the game CD? Anyone know what these file extensions even refer to?
Next up...
If I had to take a wild guess, I'd say these might be assembly language opcodes that tell the Playstation GPU how to handle model data, but of course "I R a NooB" at this sort of thing. Now, this wouldn't be functional opcode data, right? Just ASCII evidence that the opcodes are in the SLUS. I expect I'd find these elsewhere in the SLUS when I investigate with a disassembler such as PS2Dis. But I'm not sure PS2Dis knows to "tag" the various assembly language opcode functions with these labels. Anyone know of a full-featured PlayStation-centric disassembler that already does the trick?
I just wanted to throw this out there in case others have seen this sort of thing and can comment.
It's about time I delved into Halkun's PlayStation architecture/design doc -- grabbed it off Zohar.net just a few minutes ago. I shall return enlightened. :mrgreen:
I've found some very interesting ASCII blocks in Chrono Cross' SLUS file. First up...
Seems to be file paths. Is it possible that this is a signature left from the disc burning process, meaning there's MDE, FID, FND, and PRG files on the game CD? Anyone know what these file extensions even refer to?
Next up...
If I had to take a wild guess, I'd say these might be assembly language opcodes that tell the Playstation GPU how to handle model data, but of course "I R a NooB" at this sort of thing. Now, this wouldn't be functional opcode data, right? Just ASCII evidence that the opcodes are in the SLUS. I expect I'd find these elsewhere in the SLUS when I investigate with a disassembler such as PS2Dis. But I'm not sure PS2Dis knows to "tag" the various assembly language opcode functions with these labels. Anyone know of a full-featured PlayStation-centric disassembler that already does the trick?
I just wanted to throw this out there in case others have seen this sort of thing and can comment.
It's about time I delved into Halkun's PlayStation architecture/design doc -- grabbed it off Zohar.net just a few minutes ago. I shall return enlightened. :mrgreen:
Last edited:
C
Cyberman
Guest
Not everything will have a GPU code, only the quadric's and triangles used in the model would use that.
I'm not positive but TIM et all use bios calls that set up a DMA into the GPU to load the data into the VRAM.
If GPU opcode *is* in with the game data, is it also in the SLUS file? If both the SLUS file and the data following the SLUS file on the game CD contain opcode, and that opcode features the same call functions, then perhaps I could view the call functions in the SLUS file in hex, determine their ASCII signature, and then find the call functions further on in the game CD as well, pointing to model data. [/qoute]Well actually it is more likely there is a buffer of where to load the model data. I know the background files contain fixed load points in each file in FF7. It's less likely GPU opcodes will be interspersed in the executable. The code in the executable is more likely to know what to do with it and use it to set up the GTE to transform the data to be sent to the GPU instead.
Halkun has a nice document he wrote "everything you wanted to know about the playstation but were afraid to ask" or something like that. I recommend reading the GPU commands. That is one way you can distinguish between quads and triangles in the data you are looking at.
Remember ALL CODES ARE 32 bits this includes the GPU so be sure to think that when you are looking for GPU codes.
What you have is part of the library for loading stuff into the GPU likely
Cyb
F
FaustWolf
Guest
Thanks Cyb! :-D Yes, Halkun's "Everything You Ever Wanted to Know But Were Afraid to Ask..." is first on my reading list over the next few weeks. This is fun!
H
halkun
Guest
Short History on Psy-Q
Once Upon a time, Sony made an arcade board for Namco called "System 11". Namco used this arcade system and created games such as "Ridge Racer" and "Tekken". During the fall out between Sony and Nintendo over the cd-rom addon, Sony took the System 11 board, tacked on the PSX cd-rom technology, put it on a box, and called it "The Playstation"
Now Sony had a problem.
Sony is a hardware manufacturer. They are not coders, and for this new system, had no real game development kits to go along with it. They invited Psygnosis, a very popular video game company at the time to create a 1st party game and Sony wanted dibs on the development kit they created for it. Psygnosis created "Psy-Q" and went on to create the first "wipeout" game with it. Psy-Q was a good game library, and had the ability to abstract all the hardware away from programming. You called the Psy-Q commands, which in turn called the BIOS, which in turn commanded the hardware to do cool things.
A snag was hit early on when Sony made the decree that software companies could only go though the PSX BIOS or Psy-Q, when making the game. No direct hardware calls were allowed. (This was because they wanted to preserve a kind of "reference" that could put into a later machine for backwards compatibility).
Psygnosis thought because they made the dev kit, they were exempt from the "no direct hardware programming" rule. The first release of Wipeout talked directly with the PSX. Sadly when the first revision of the hardware came out, it crashed all the first-generation Wipeout games and Psygnosis had to make another version more compatible with Sony reference.
Psy-Q is a game library and toolset written in C, and was used on DOS. It used a modified gcc compiler. Looking on the internets, you can find copies of the Psy-Q documentation, but having is illegal. You can also find the library too if you look hard enough. This is why you will find programs that seem to use the same dataset over and over again. (TIM, for example, or SEQ) these are all Psy-Q data formats that are "native" to the PSX.
TIM = bitmap picture/texture format
HRC = hierarchy format
TMD = 3d object format
RSD = model+hierarchy+texture format (resource data, it's the whole "3D entity")
ANI = 3D Animation format
VAG/VAB = digital Audio format (group/single)
SEQ = Sequence (midi) data
STR = Streaming video format
You can see how this becomes a basis for a game. If you can find this data hidden on the disk, youhave an idea of how to "expand" it into something to use. Keep in mind: The PSX only had 4 meg, that's not a lot, especially when you realize that you have no dynamic libraries and most of the time Psy-Q was statically linked to the executable somehow.
That should start you off.
Once Upon a time, Sony made an arcade board for Namco called "System 11". Namco used this arcade system and created games such as "Ridge Racer" and "Tekken". During the fall out between Sony and Nintendo over the cd-rom addon, Sony took the System 11 board, tacked on the PSX cd-rom technology, put it on a box, and called it "The Playstation"
Now Sony had a problem.
Sony is a hardware manufacturer. They are not coders, and for this new system, had no real game development kits to go along with it. They invited Psygnosis, a very popular video game company at the time to create a 1st party game and Sony wanted dibs on the development kit they created for it. Psygnosis created "Psy-Q" and went on to create the first "wipeout" game with it. Psy-Q was a good game library, and had the ability to abstract all the hardware away from programming. You called the Psy-Q commands, which in turn called the BIOS, which in turn commanded the hardware to do cool things.
A snag was hit early on when Sony made the decree that software companies could only go though the PSX BIOS or Psy-Q, when making the game. No direct hardware calls were allowed. (This was because they wanted to preserve a kind of "reference" that could put into a later machine for backwards compatibility).
Psygnosis thought because they made the dev kit, they were exempt from the "no direct hardware programming" rule. The first release of Wipeout talked directly with the PSX. Sadly when the first revision of the hardware came out, it crashed all the first-generation Wipeout games and Psygnosis had to make another version more compatible with Sony reference.
Psy-Q is a game library and toolset written in C, and was used on DOS. It used a modified gcc compiler. Looking on the internets, you can find copies of the Psy-Q documentation, but having is illegal. You can also find the library too if you look hard enough. This is why you will find programs that seem to use the same dataset over and over again. (TIM, for example, or SEQ) these are all Psy-Q data formats that are "native" to the PSX.
TIM = bitmap picture/texture format
HRC = hierarchy format
TMD = 3d object format
RSD = model+hierarchy+texture format (resource data, it's the whole "3D entity")
ANI = 3D Animation format
VAG/VAB = digital Audio format (group/single)
SEQ = Sequence (midi) data
STR = Streaming video format
You can see how this becomes a basis for a game. If you can find this data hidden on the disk, youhave an idea of how to "expand" it into something to use. Keep in mind: The PSX only had 4 meg, that's not a lot, especially when you realize that you have no dynamic libraries and most of the time Psy-Q was statically linked to the executable somehow.
That should start you off.
F
FaustWolf
Guest
That starts me off alright. :-o Thanks Halkun!
Now that I've figured out how to take advantage of PS2Dis' built-in hex viewer (offset disparities between that and the SLUS file as shown in my hex editor were giving me a headache for awhile), I should be good to go once I find out what the quad GPU opcodes look like in assembly language. Sharing that info on this board is strictly "Verboten," right? Meaning I'll have to figure it out from some documentation I downloa- well, nevermind.
Ooh, and that "ANI" format - do all PSX models use that for animation, or only TMDs? Do developers typically come up with their own animation formats as they do with their proprietary model formats?
Now that I've figured out how to take advantage of PS2Dis' built-in hex viewer (offset disparities between that and the SLUS file as shown in my hex editor were giving me a headache for awhile), I should be good to go once I find out what the quad GPU opcodes look like in assembly language. Sharing that info on this board is strictly "Verboten," right? Meaning I'll have to figure it out from some documentation I downloa- well, nevermind.
Ooh, and that "ANI" format - do all PSX models use that for animation, or only TMDs? Do developers typically come up with their own animation formats as they do with their proprietary model formats?
Last edited:
H
halkun
Guest
There are two major animation formats that have been found, and both are used in FF7. One is a bitwise delta format that is used for the battle models, and is closely related to the Psy-Q animation format. The other is a "frame" format that simply holds all the angles for the bones in that frame.(used for the field characters) I don't know if the both come from Psy-Q. I know MGS used a special animation format that was a kind of compressed delta, and Square uses the modified AKAO format for sound. The Psy-Q animation format has support for not only delta positions, but also machine states, so it can get really complex.
Oops, let me define:
Delta - Change over time. As opposed to listing joint angles every animation frame, it only lists how much the angle has changed via a +/- value. It's smaller, but more complex to decode.
State machine: Basically a "mode" that a particular program runs in. When it comes to animation it can have a "stand" state, a "walking' state", a "running" state, and a "jumping" state. These are all linked togeather to from a branch-loop.
stand->walk->stand->jump->stand->walk->run->stand.
I know we decoded the delta format, I think it's in the wiki. I'm not sure about the state machine though.
Talking about the PSX GPU here is fine. It's open and not a trade secret. Pretty much anything about the PSX is fair game except for the BIOS function names. Psy-Q, on the other hand, is a little more tricky. If it looks like you are copying out of the Psy-Q manual, that is a sure-fire way to get yourself banned. However, If you can get a clue about a format by analyzing the data, you should be in the clear.
Also, take the strings you find in executables with a grain of salt. Some of that data looks like garbage left over after the compile process. Sometimes compilers compile a program in memory and bulk-copy the finished heap to disk. When that happens it can "scoop up" chunks of the compile process as filler to round out the memory boundary. It's interesting that it might lead a clue to the compile process, but not necessarily anything useful about the executable.
P.S.--> Oh and by the way... Why can't we talk about the Psy-Q/BIOS functions?
Because Sony told me not to, that's why.
P.P.S. --> V hfrq gb jbex sbe Anzpb
Oops, let me define:
Delta - Change over time. As opposed to listing joint angles every animation frame, it only lists how much the angle has changed via a +/- value. It's smaller, but more complex to decode.
State machine: Basically a "mode" that a particular program runs in. When it comes to animation it can have a "stand" state, a "walking' state", a "running" state, and a "jumping" state. These are all linked togeather to from a branch-loop.
stand->walk->stand->jump->stand->walk->run->stand.
I know we decoded the delta format, I think it's in the wiki. I'm not sure about the state machine though.
Talking about the PSX GPU here is fine. It's open and not a trade secret. Pretty much anything about the PSX is fair game except for the BIOS function names. Psy-Q, on the other hand, is a little more tricky. If it looks like you are copying out of the Psy-Q manual, that is a sure-fire way to get yourself banned. However, If you can get a clue about a format by analyzing the data, you should be in the clear.
Also, take the strings you find in executables with a grain of salt. Some of that data looks like garbage left over after the compile process. Sometimes compilers compile a program in memory and bulk-copy the finished heap to disk. When that happens it can "scoop up" chunks of the compile process as filler to round out the memory boundary. It's interesting that it might lead a clue to the compile process, but not necessarily anything useful about the executable.
P.S.--> Oh and by the way... Why can't we talk about the Psy-Q/BIOS functions?
Because Sony told me not to, that's why.
P.P.S. --> V hfrq gb jbex sbe Anzpb
Last edited:
F
FaustWolf
Guest
Halkun, you're a walking PSX encyclopedia! Truly amazing!
Ah, so nothing wrong with GPU opcode discussion then. *Breathes sigh of relief* Is there any documentation on what GPU opcode / functions look like in assembly language, Halkun? (At least related to quads, if that's the only opcode that appears near model data) I didn't see anything about that on the wiki.
Ah, so nothing wrong with GPU opcode discussion then. *Breathes sigh of relief* Is there any documentation on what GPU opcode / functions look like in assembly language, Halkun? (At least related to quads, if that's the only opcode that appears near model data) I didn't see anything about that on the wiki.
H
halkun
Guest
The gpu opcodes are not in any language. How they work is you make a list of opcode commands that you want to the GPU to accomplish, line them all up in a row, and then fire them to the GPU for execution.
You can talk to the GPU two ways, by giving the opcode directly to the GPU, or by fireing them off via DMA. The GPU hand off only works one at a time. The DMA method is much faster and supports Ordering Tables (OT) or linked lists of GPU opcodes.
What makes OTs so easy is you can pre-rig your list of opcodes, and then use the GTE to sort each "triangle" opcode by Z depth. Then you have a paint order that the GPU can render triangles to the screen. (That's why they are called "ordering tables") In FF8, the texture data consisted of pre-made GPU packets that was missing some data (to be filled by the GTE).
Of course it's been almost 7 years since I looked at them.
FF7 was more HRC-ish when they were built.
You can talk to the GPU two ways, by giving the opcode directly to the GPU, or by fireing them off via DMA. The GPU hand off only works one at a time. The DMA method is much faster and supports Ordering Tables (OT) or linked lists of GPU opcodes.
What makes OTs so easy is you can pre-rig your list of opcodes, and then use the GTE to sort each "triangle" opcode by Z depth. Then you have a paint order that the GPU can render triangles to the screen. (That's why they are called "ordering tables") In FF8, the texture data consisted of pre-made GPU packets that was missing some data (to be filled by the GTE).
Of course it's been almost 7 years since I looked at them.
FF7 was more HRC-ish when they were built.
Last edited:
A
Akari
Guest
In PSX format not that easy. It is not set all rotation for all bones, but only rotation for defined bones and to defined axis (many bones have only one or two axis for rotation). And, in addition root bone movement. And all this stored not frame by frame, but all rotations for 1 axis of one bone, next next axis, next bone and so on.
L
Lupus Erectus
Guest
Speaking of animation formats, a few days ago I was trying to look at the Vagrant story animation data and watching some animations in-game I noticed they definately aren't skeletal like the TMD seems to be, but more like a list of vertex coordinates for each frame (like the MD2 of quake 2 I think) It's very noticeable on some weird monsters like the slimes and the Dark Eyes with theyr glowing and theyr texture "animations" but also on some humanoid models there are some visible distortions.
I guess Psy-Q doens't support anything like this, eh?
And Faustwolf, since VS and CC are both from Square and from the same age, I looked at those files you posted but they seem very different beasts.
I guess Psy-Q doens't support anything like this, eh?
And Faustwolf, since VS and CC are both from Square and from the same age, I looked at those files you posted but they seem very different beasts.
F
FaustWolf
Guest
Thanks for looking at the files, Lupus! Once we get past the hurdles associated with viewing Chrono Cross' models, Vagrant Story is actually very high on my list of games to explore next. Have you succeeded in viewing VS model data?
L
Lupus Erectus
Guest
No, but I haven't really investigated, and probably I won't for a good while....
OTOH, some time ago I started uploading some VS data on http://www.datacrystal.org/wiki/Main_Page
OTOH, some time ago I started uploading some VS data on http://www.datacrystal.org/wiki/Main_Page
Z
ZeaLitY
Guest
Quick question:
Code: [Select]
Would those be the actual filenames for the TIMs? These three byte headers go before each TIM in the battle data. I think pretty soon we can begin asset extraction in the files produced by Yazoo's tools at the Compendium...sort of like, getting identifiable data out of OUT files, leaving the rest / deleting them if they are completely convertible.
Code: [Select]
Code:
Headers example 00 00 00 00 64 65 67 75 ....degu04 00 22 01 00 00 00 00 64 65 67 31 04 00 22 01 00 00 00 00 ..".....deg1..".....64 65 67 32 04 00 22 01 00 00 00 00 64 65 67 33 04 00 22 01 deg2..".....deg3..".00 00 00 00 64 65 67 34 04 00 22 01 00 00 00 00 64 65 67 35 ....deg4..".....deg504 00 22 01 00 00 00 00 65 6e 6b 65 04 00 22 08 00 00 00 00 ..".....enke..".....65 6e 6b 31 04 00 22 04 00 00 00 00 67 61 6b 65 04 00 22 01 enk1..".....gake..".00 00 00 00 67 61 6b 31 04 00 22 01 00 00 00 00 67 61 6b 32 ....gak1..".....gak204 00 22 01 00 00 00 00 67 61 6b 33 04 00 22 01 00 00 00 00 ..".....gak3..".....67 61 6b 34 04 00 22 01 00 00 00 00 67 61 6b 35 04 00 22 01 gak4..".....gak5..".00 00 00 00 67 61 6b 36 04 00 22 01 00 00 00 00 67 61 6b 37 ....gak6..".....gak704 00 22 01 00 00 00 00 67 61 6b 38 04 00 22 01 00 00 00 00 ..".....gak8..".....67 73 30 31 04 00 22 01 00 00 00 00 67 73 30 32 04 00 22 01 gs01..".....gs02..".00 00 00 00 67 73 30 33 04 00 22 01 00 00 00 00 67 73 30 34 ....gs03..".....gs0404 00 22 01 00 00 00 00 67 75 30 31 04 00 22 01 00 00 00 00 ..".....gu01..".....67 75 30 32 04 00 22 01 00 00 00 00 67 75 30 33 04 00 22 01 gu02..".....gu03..".00 00 00 00 67 75 30 34 04 00 22 01 00 00 00 00 6a 69 6d 65 ....gu04..".....jime04 00 22 01 00 00 00 00 6a 69 6d 31 04 00 22 01 00 00 00 00 ..".....jim1..".....6a 69 6d 32 04 00 22 01 00 00 00 00 6a 69 6d 33 04 00 22 01 jim2..".....jim3..".00 00 00 00 6a 69 6d 34 04 00 22 01 00 00 00 00 6b 75 6d 6f ....jim4..".....kumo04 00 22 02 00 00 00 00 6b 61 6e 6b 04 00 22 04 ..".....kank..".
Last edited:
A
Akari
Guest
This is common sence in bones animation. Each vertex has weight parameter bones (or how much bone movement influence it). You can set vertex linked to two bones at once, so you will see ettect of distortion (when dress move and stretch). This was used in FFIX.
F
FaustWolf
Guest
This is posted at the Chrono Compendium also, but I'm reproducing here. It relates to a comparison I'm attempting between FF8 model data and Chrono Cross model data:
I've just done some investigation of the data following Zell's battle model texture(s) in my disassembler (because viewing data through a disassembler makes me feel cool
), and it appears the data immediately following Zell's texture starts with the following assembly language instructions:
dsrav zero, zero, zero
sync
dsllv zero, zero, zero
Halkun, does this provide any clue as to whether or not I'm looking at quad opcodes? Or, an alternative question, how is one able to tell that he/she is even looking at quad opcodes?
And I've got a few quick questions about your PSX doc, which I am still reading through (rather haphazardly, as time allows):
1.) In your GPU packet command list, "0x2c" constitutes a packet command for a textured 4-point polygon. What would that look like in hex? Just "2C"? And would that appear in a quad opcode?
2.) You differentiate between "monochrome" and "textured" polygons. Would I be correct in stating that Final Fantasy 7 uses monochrome polygons (excluding faces, I guess?), whereas Final Fantasy 8 (and, by association, Chrono Cross) uses textured polygons? This is an obvious NooB question, but I just want to make sure.
EDIT: I received your answer on Chrono Compendium Halkun! Thanx!
I've just done some investigation of the data following Zell's battle model texture(s) in my disassembler (because viewing data through a disassembler makes me feel cool
), and it appears the data immediately following Zell's texture starts with the following assembly language instructions:dsrav zero, zero, zero
sync
dsllv zero, zero, zero
Halkun, does this provide any clue as to whether or not I'm looking at quad opcodes? Or, an alternative question, how is one able to tell that he/she is even looking at quad opcodes?
And I've got a few quick questions about your PSX doc, which I am still reading through (rather haphazardly, as time allows):
1.) In your GPU packet command list, "0x2c" constitutes a packet command for a textured 4-point polygon. What would that look like in hex? Just "2C"? And would that appear in a quad opcode?
2.) You differentiate between "monochrome" and "textured" polygons. Would I be correct in stating that Final Fantasy 7 uses monochrome polygons (excluding faces, I guess?), whereas Final Fantasy 8 (and, by association, Chrono Cross) uses textured polygons? This is an obvious NooB question, but I just want to make sure.
EDIT: I received your answer on Chrono Compendium Halkun! Thanx!
Last edited:
F
FaustWolf
Guest
Posting this here for maximum exposure; it's on the Compendium as well:
The "Uknown Data" in my ModelMine1 post can now be referred to as "Model Data."
Here's tonight's update. The vid quality is less than I would have liked, but hopefully we can find some insight within its grainy-ness. No sound either; I'll report later as to whether the "Chimera" uses Kid's or Serge's sounds in battle, because I've forgotten. :-D
The first video is just a demonstration of how the characters Serge and Kid look in battle. Folks already familiar with Chrono Cross battle models can probably skip to the second vid, but this provides a useful reference:
Now the fun begins. As boring as it will be at times, please watch this in its entirety to get a full impression of what's going on with the model data. The final 30 seconds are especially important:
*t-thL5Q
Please finish the web address of the second vid with the letter "I". Silly Youtube. :roll:
As you can see, the "Chimera" is Serge's model data with Kid's battle texture. Serge's standing, running, and spell-casting animations have carried over, but not his physical attack animations for some reason. But a complicating factor is the significant difference in file size between Serge's and Kid's model data. Specifically (and surprisingly), Kid's model takes up 8184 bytes more in the game CD than Serge's! It could be that Kid's animations are more complex than Serge's or something, and therefore need more space.
I'll illustrate graphically what I did exactly. Below is a representation of Serge's battle model data (sans skin & eye blink textures). In ModelMine1, the unskinned model lasts from hex offsets 00009800 ~ 00014848:
The following is a representation of Kid's unskinned battle model data. I will release her battle data set - ModelMine2 - tomorrow evening, once I jot down some datamapping notes on it. Then we can find potential model file headers.
Now, with Serge's model data written over Kid's:
So some of Kid's model data is still left over. At some point I'll wipe the rest of the "red" (Kid) part out with 00 bytes and see how that changes things.
At least this shows that we've got battle models. Now, the question is how to go about deciphering the model format so it can be viewed in 3DS Max, Blender, etc.
The "Uknown Data" in my ModelMine1 post can now be referred to as "Model Data."
Here's tonight's update. The vid quality is less than I would have liked, but hopefully we can find some insight within its grainy-ness. No sound either; I'll report later as to whether the "Chimera" uses Kid's or Serge's sounds in battle, because I've forgotten. :-D
The first video is just a demonstration of how the characters Serge and Kid look in battle. Folks already familiar with Chrono Cross battle models can probably skip to the second vid, but this provides a useful reference:
Now the fun begins. As boring as it will be at times, please watch this in its entirety to get a full impression of what's going on with the model data. The final 30 seconds are especially important:
Please finish the web address of the second vid with the letter "I". Silly Youtube. :roll:
As you can see, the "Chimera" is Serge's model data with Kid's battle texture. Serge's standing, running, and spell-casting animations have carried over, but not his physical attack animations for some reason. But a complicating factor is the significant difference in file size between Serge's and Kid's model data. Specifically (and surprisingly), Kid's model takes up 8184 bytes more in the game CD than Serge's! It could be that Kid's animations are more complex than Serge's or something, and therefore need more space.
I'll illustrate graphically what I did exactly. Below is a representation of Serge's battle model data (sans skin & eye blink textures). In ModelMine1, the unskinned model lasts from hex offsets 00009800 ~ 00014848:
The following is a representation of Kid's unskinned battle model data. I will release her battle data set - ModelMine2 - tomorrow evening, once I jot down some datamapping notes on it. Then we can find potential model file headers.
Now, with Serge's model data written over Kid's:
So some of Kid's model data is still left over. At some point I'll wipe the rest of the "red" (Kid) part out with 00 bytes and see how that changes things.
At least this shows that we've got battle models. Now, the question is how to go about deciphering the model format so it can be viewed in 3DS Max, Blender, etc.
Last edited:
- Status