Search results

GSL is a pretty generic archive format, so you read the offset and extract the files like everything else. For .rel assets, there are only a few of them in the game and they pretty much the same format at the stage maps. You start at EOF -16, to get the pointer to the header table. And then from...

Small update. I've been working on Shenmue animations for a while. It looks like the devs used a pretty complicated format using inverse kinematics. To take a break from that I made a set of tools to convert Ikaruga's .nj files to my own .dmf format (animations included). The tool can be found...

Okay managed to find all of the skyboxes. It ended up being as simple as looking for the s.nj files, checking to see if there is a s.pvm file or not, and then generating a function to handle loading the assets. So next step is going to be the ultimate enemies. And it looks like Sega was nice...

Quick notes on more assets to extract. Boss 1: bm_boss1_dragon_a.bml bm_boss1_dragon.bml bm_obj_boss1_common.bml bm_obj_boss1_common_a.bml obj_boss1_common.pvm obj_boss1_common_a.pvm Boss 2: bm_boss2_de_rol_le_a.bml bm_boss2_de_rol_le.bml bm_boss3_volopt_ap.bml bm_boss3_volopt.bml...

Went back and grabbed the rel objects from the forest gsl. Next to try to see if this works with the Pioneer 2 NPC's. Okay and also finished off the NPC rels in city.gsl. They ended up being the pre-made NPC hunters, which might help map out the texture numbers for the different outfits...

City map_city_on_e.bin map_city_on_f.bin map_city_on_g.bin map_city_on_j.bin map_city_on_s.bin map_city_off_e.bin map_city_off_f.bin map_city_off_g.bin map_city_off_j.bin map_city_off_s.bin fs_obj_warp.bml fs_obj_warp.pvm bm_obj_warpboss.bml bm_obj_city_common.bml symbolchatcolli.prs...

So on to Ruins. There are a bunch of custom assets. So I'll probably have to go back and add in things like teleports and stuff. Hopefully Ruins 2 and 3 won't add in too much. Ancient 01 GSL o_key_ancient02.pvm seems like the odd texture out. Everything else seems to have textures. Ancient...

It's been almost a month since posting. I guess I've had a busy summer. Caves 02 GSL Okay, that wasn't too bad. The assets that I didn't have were pretty straight forward. not too many animations, and everything was generally grouped together. So onto caves 03. Caves 03 GSL Thank god...

Oh nice, the wiki has a much better image than the Katana SDK docs. And there's "twiddled" name drop, spelled with one 'd'. Maybe that explains why I couldn't find much searching google for 'twiddled'. But this description makes a lot more sense. Writing the documentation gave me some ideas...

Okay, for PVR textures I guess it makes the most sense to go from top to bottom. Like other files PVR textures use a magic number "PVRT" followed by the length of the pvr texture. The header of pvr is 8 bytes in length: struct pvr_header_t { uint8_t encode_format; uint8_t pixel_format...

I was hoping to add some more information over the weekend, but either way it's time for some more forum spam. For document I wrote, there was generally already something there so I was able to contrast with what else needed to be added. So for pvmh and pvrt, I guess I can at least add the basic...

For now I've created a "dreamcast" namespace in the wiki to document the PSO v2 formats as it. My thinking is that the Dreamcast documentation can serve as a base for file formats in Gamecube and PsoBB that haven't been documented yet. Pages added: AFS Archive BML Archive GSL Archive Ninja...

The key frame list is generally declared above the motion table, so you can use the start offset of the motion table to check against the last key frame list.

Okay last chunk to describe before jumping into the wiki Ninja Texture List So the image above it pretty ugly, but the struct are pretty simple. The first struct 0x08 is the offset to the texture list, 0x02 is the number of textures. typedef struct { NJS_TEXNAME *textures; /*...

As far as I can tell PSOv2 for Dreamcast and PC always uses the format: struct NJS_MKEY_A { uint32_t keyframe; int32_t angle[3]; } For PsoBB, i think it could use the 32 bit format, but more often than not it's probably going to be: struct NJS_MKEY_A { uint16_t keyframe...

Okay so moving on to ninja motion (.njm). Ninja Motion uses the magic number NMDM, followed by the length of the file. The first struct in the file often looks like the following: NJS_MOTION 60060000 1E000000 03000200 What this is is the pointer to the motion table (0x660), the number of...

In terms of things to rant about, the general bone structure of the nj format is easy enough to use. It's the packing method of the vertices and materials that's the stupid part. So in terms of parts that are hard to interpret you have, 1. Handling the vertex list, indices and weights 2...

So the bits chunk documentation that's already there seems to pretty accurate. When the bit type is 4 you cache the location and stop parsing that set of chunks. When the bit type is 5 you jump back to the cached location. Which just leaves the Strip Chunk. Which I might end up splitting into...

I guess I can get another quick one out of the way: Material Chunk The material chunk is used to declare the diffuse, secular and ambient color for the mesh being defined. The header probably gives a better description of how this chunk works compared to the NinjaGD.pdf /*----------------*/...

Next step is Tiny Chunk Tiny Chunk has a fixed length and sets the texture id. The texture id matches up with the texture name set in the NJTL texture list, and should generally match any corresponding PVM files. [chunk head 8 bytes] [ chunk flag 8 bytes ] [tiny chunk 16 bytes ] struct...