Search the Community

Hello everyone, I am new here and would like to introduce myself a little bit before going to the main part of the topic. In October last year I started a project with disassembling a PS2 game called Driver Parallel Lines and a little bit later the prequel of it, a PSP game called Driver 76. As a person with basically no prior experience in doing things like these, the start was difficult for me, but because I am really interested in turning my idea into reality, I invested really much time in this project, and learned interesting and possibly important things. I also tried out many cool programs for modifying/working with different kinds of files. Since I found my way to the raw textures my current main goal is to modify the Textures from Driver Parallel Lines (PS2) so they get displayed correctly in Driver 76 (PSP). Why do I think inserting these textures from a PS2 into PSP should work?? Because these two games are basically the same and use many same textures, Driver 76 runs fine with these textures (I tried it out), but they don't look how they should, that's why I assume the keyword of this topic might be Swizzling? The main part of this topic I started with the easiest part, which in my opinion is the HUD. This is how the stock Hud looks in Driver 76: At first I would like to describe the whole picture of this Topic to understand what is what. Driver Parallel Lines (PS2) has two eras in it's gameplay, the year 1978 and the year 2006, both eras have it's unique textures, including two types of the HUD. At first I tried the easiest what I could imagine, just effortlessly pasting the 1978 HUD files [a .gfx file (the textures) and a .bin file (the function/moving elements of the HUD)] into Driver 76, and this is how it looked: Not what I expected, but hey, the PS2 .bin file of the 1978 HUD works fine on the PSP, I can see how the speedometer works, the mileage changes, and also the health bar works fine, which now acts like in Driver Parallel Lines. A little bit later I noticed something very interesting. Since Driver 76 has only one era (the year 1976) not two eras like in Parallel Lines (1978 and 2006), it logically should only have the HUD files for 1976, but for some reason it has the files for 1976 and for 2006! I thought this is very good, because this gives a big opportunity to directly compare the PSP version with the PS2 version of the exact same files, which might help to understand the differences. Since I discovered this, I definitely had to try out both files of the 2006 HUD, the PSP version and the PS2 version. The .bin file doesn't work for some reason, I assume it might be directly bound with the 2006 stuff which is not present here, but the function is not important now, since I am aiming to find a solution for the graphical part. Here are the screenshots of both versions: 2006 HUD PSP file from Driver 76 2006 HUD PS2 File from Driver Parallel Lines I think this is enough to understand what the trouble currently is, that's why I will continue with the results which I was able to find, when comparing + analysing these files and trying to modify the PS2 file. As an example, I decided to work with the texture of the ingame loading icon (a CD), which looks like this in both games: Here are the texture files:Texture files.zip Basic info about this CD texture: -Both textures are exactly the same and are used for the same purpose in both games on both platforms. -Size and offsets are for both files identical -Total file size: 5120 Bytes -Palette offset: -(DEC): 0-1024 -(HEX): 0-400 -Graphics/Texture offset: -(DEC): 1024-5120 -(HEX): 400-1400 -Raw Texture size (without palette): - 4096 Bytes The differences which I noticed: *When viewing in HxD* -Palette only: First & Last two lines are identical, everything between becomes reordered like this: 1->3 2->4 3->1 4->2 identical<->identical identical<->identical identical<->identical identical<->identical 1->3 2->4 3->1 4->2 And so on... Screenshot of the comparison with the differences that I found: I think that this is not a big problem, because the situation of the palette seems to be very understandable, so I would just reorder these lines by using this example of the comparison of these 2 files. If this is necessary of course. *When viewing in HxD* -Graphic/Texture only: The Graphic's/Texture's code is completely different, it seems that only the beginning and the end of the code may look somehow similar (but not identical), but it looks like there's no way to find a logical difference between these two, so that's it with HxD, let's continue with the visual part. Screenshots of the Graphic's/Texture's code: Beginning of the code: End of the code: A cool program which I found on this forum called Console Texture Explorer, by Dageron, gave me the opportunity to view textures the way how they would be displayed on PS2 and also on PSP, by ticking the needed console, this saves much time, no need to rebuild the game to see the result if changes are made. Here is an example to simulate the same result which I described earlier with ingame screenshots: PS2 Texture with PS2 Console option tick: PS2 Texture with PSP Console option tick: And the PSP texture with PSP Console option tick: I think this acts as a perfect example that these textures are exactly the same, but the way both consoles display these textures is different. I assume that the PS2 swizzles textures with it's own technique, and the PSP swizzles with it's own technique, is this correct? Or did I understand this wrong? After weeks of unsuccessful attempts to understand what exactly the displaying difference is, I decided to look again for similiar programs today and I was able to find a very powerful cool program which was posted on this forum called ImageHeat by the moderator ikskoks, as far as I understood who is the developer of this program. I would like to say thank you very much for creating this cool program, I like it, there are many many functions. After playing around with ImageHeat, I think I finally understood that my problem has something to do with swizzling. Here is my latest result with this texture + what I did First a screenshot in ImageHeat of the texture displayed correctly: Then I changed the Swizzling Type to PSP, and turned off PS2 Palette Swizzle: This is also how I saved the texture, by pressing Save Raw Data This is the result: All 3 pictures where simulated in Console Texture Explorer, first picture is an example, and the last two pictures where simulated with PSP option ticked. This is how it should look like: This is how it looked: And this what I was able to achieve with ImageHeat after saving with PSP Swizzling type: After weeks of understanding nothing, I think this already something. Unfortunately I still didn't achieve my goal, but it looks like the end result is halfway done/displayed correctly. This is the end of this long post, thank you to everyone who took his/her time to read everything. I would be really happy and thankful if someone could point me in the right direction, or tell me what the issue is. Maybe even the developer of ImageHeat sees this post who has a really good understanding based on his awesome program. This is my first post on this site, I hope i chose the correct forum (Graphic file formats), If not I apologize for this.

I've been interested in trying to rip the files for the Open Season videogame to unearth any unused files present for a couple of years, found some filenames for unused stuff like a wolf character among other things in the .UMD package file which the game requires in the Xbox 360, Xbox, and PC versions to even bootup (while also using .lin and liv files for packages (.liv being exclusive to the Xbox 360 version), PS2, GameCube and Wii have the contents of the .lin and .liv files included in the main .UMD package file that's required to boot the game up. Though there's been no way to view this stuff for 18 and a half years since the release of the movie and the tie-in game here. Here's files as samples from every version of the main Console/PC releases for research purposes from anyone willing to look into this, which would be really awesome. Versions included: Xbox 360 (North American Version) Xbox (North American Version) PC (North American Version) PS2 (1st European version (English, French, Spanish, Dutch) since it's the earliest final retail build of this release compared to the Scandinavian European PS2 version) GameCube (North American Version) Wii (North American Version) https://drive.google.com/drive/folders/1lTmfQnIQhtK099_aeYbiDBTHjNbwY7oh?usp=sharing

Hi everyone! I recently extracted Midnight Club 2's textures as I am looking to experiment with creating a HD texture pack (which does not exist today). Most of the files are .TEX, with a few .IPU and .PAL files and one .OUT file. However, I have tried several different programs to convert the .TEX files to PNGs in order to upscale them properly, without much luck. ScarletConvert doesn't recognize the tex, Rainbow doesn't support tex files, TextureFinder 1.3.2 opens up a weird image with distorted colors, and TextureFinder 2.1 may be a virus based on VirusTotal and my W11 PC literally stopping me from opening the file. In addition, there are also IPU, OUT, and PAL files in the directory for seemingly larger assets. Can I get some assistance with this problem? Thank you, and have a great day!

love it or hate it Metal Slug 3D PS2 (2006). I just need to extract pak file so I knew there are 3d models of enemies and vehicles in the 2006 game but I couldn't extract it I used BMS quickbms https://aluigi.altervista.org/bms/metal_slug_3d.bms it only works only DATA file and the folder in the iso metal slug 3d ps2 doesn't have it! help please !

I'm currently in the early steps of a translation project for Tokimeki Memorial 3: Yakusoku No Ano Basho De. Right now I am making a tool for extracting the game's script. I have extracted the file system from the .iso. It has five .BIN files which contain all of the game's assets. At first I extracted text from Data5.BIN, as it contained uncompressed text that simply needed to be filtered from the other data. This text is almost exclusively for menus, which means the dialogue must be stored in the other .BIN files. When viewed in a hex editor, it becomes clear that the other data files (Data1.BIN - Data4.BIN) contain a large amount of compressed files with the header ATP. I know some of these contain dialog, because I can see scattered bits of Shift-JIS strings, some of which line up with dialogue I've seen in-game. Using a combination of the PCSX2 debugger and Ghidra I was able to identify where the compressed files are stored in memory when they are loaded off the disk and the function that is responsible for decompressing them. I've recreated this function in my toolset and it runs/exits without crashing but I don't think the decompression is working. It seems to have the following issues: Sometimes there are no changes between the compressed and "decompressed" ATP file (it's possible that this means the file's content was never actually compressed to begin with) Oftentimes the strings appear more jumped in the "decompressed" version than the compressed version. It doesn't stop when it needs to, running into the next ATP file and stopping halfway through "decompressing" that. Here's the assembly function taken from the PCSX2 disassembler: lbu a3,0x0(a0) addiu a0,a0,0x1 daddu t1,a1,zero addiu t0,zero,0x8 bne t0,zero,0x001E93F8 andi v0,a3,0x0001 lbu a3,0x0(a0) addiu a0,a0,0x1 addiu t0,zero,0x8 andi v0,a3,0x0001 bne v0,zero,0x001E9418 addiu t0,t0,-0x1 lbu v0,0x0(a0) addiu a0,a0,0x1 srl a3,a3,0x01 sb v0,0x0(a1) beq zero,zero,0x001E93E0 addiu a1,a1,0x1 bne t0,zero,0x001E942C srl a3,a3,0x01 lbu a3,0x0(a0) addiu a0,a0,0x1 addiu t0,zero,0x8 andi v0,a3,0x0001 beql v0,zero,0x001E9498 lbu v0,0x0(a0) addiu t0,t0,-0x1 bne t0,zero,0x001E9450 srl a3,a3,0x01 lbu a3,0x0(a0) addiu a0,a0,0x1 addiu t0,zero,0x8 andi v0,a3,0x0001 srl a3,a3,0x01 addiu t0,t0,-0x1 bne t0,zero,0x001E9470 sll a2,v0,0x01 lbu a3,0x0(a0) addiu a0,a0,0x1 addiu t0,zero,0x8 andi v0,a3,0x0001 srl a3,a3,0x01 lbu v1,0x0(a0) addiu a0,a0,0x1 addu v0,a2,v0 addiu t0,t0,-0x1 bne v1,zero,0x001E94E0 addiu a2,v0,0x2 beq zero,zero,0x001E94E0 addiu v1,zero,0x100 addiu a0,a0,0x1 lbu v1,0x0(a0) addiu a0,a0,0x1 sll v0,v0,0x08 srl a3,a3,0x01 or v1,v0,v1 beq v1,zero,0x001E9510 addiu t0,t0,-0x1 andi a2,v1,0x000F beq a2,zero,0x001E94D0 addiu a2,a2,0x2 beq zero,zero,0x001E94E0 srl v1,v1,0x04 nop lbu v0,0x0(a0) addiu a0,a0,0x1 srl v1,v1,0x04 addiu a2,v0,0x1 beq a2,zero,0x001E93E0 subu v1,a1,v1 lbu v0,0x0(v1) addiu v1,v1,0x1 addiu a2,a2,-0x1 sb v0,0x0(a1) nop bne a2,zero,0x001E94E8 addiu a1,a1,0x1 beq zero,zero,0x001E93E0 nop nop jr ra subu v0,a1,t1 and here's my attempt to recreate it for my tool set . I apologize in advance for the poor readability public static void DecodeATP(int startAddress, byte[] byteArray, String outputPath) { //Note to self: when implementing this, use integers that refer to indexes on the array as "pointers" //Use labels and gotos for the parts byte[] destination = new byte[byteArray.Length]; uint sourcePointer = (uint) startAddress + 8; //a0 in the assembly, skips 8 to avoid the ATP file header //set up a few variables to take the place of some registers in the original assembly uint v0 = 0x0; uint v1 = 0x0; uint a2 = 0x0; byte previousByte = byteArray[sourcePointer]; sourcePointer++; uint destinationPointer = 0; uint counter = 8; byte buffer; Part1: //Part1 v0 = (byte)(previousByte & 0x1); if (counter == 0) { previousByte = byteArray[sourcePointer]; sourcePointer++; counter = 8; } else { goto Part2; } Part2: //Part2 counter--; if (v0 == 0x0) { buffer = byteArray[sourcePointer]; sourcePointer++; previousByte = (byte)(previousByte >> 0x1); destination[destinationPointer] = buffer; destinationPointer++; goto Part1; } else { goto Part3; } Part3: //Part3 previousByte = (byte)(previousByte >> 0x1); if (counter == 0) { previousByte = byteArray[sourcePointer]; sourcePointer++; counter = 8; } else { goto Part4; } Part4: //Part4 v0 = (byte)(previousByte & 0x1); v0 = byteArray[sourcePointer]; if (v0 == 0x0) { goto Part7; } else { counter--; previousByte = (byte)(previousByte >> 0x1); if (counter != 0){ goto Part5; } previousByte = byteArray[sourcePointer]; sourcePointer++; counter = 8; goto Part5; } Part5: //Part5 v0 = (byte)(previousByte & 0x1); previousByte = (byte)(previousByte >> 0x1); counter--; a2 = (byte)(v0 << 0x1); if (counter != 0) { goto Part6; } else { previousByte = byteArray[sourcePointer]; sourcePointer++; counter = 8; goto Part6; } Part6: //Part6 v0 = (byte)(previousByte & 0x1); previousByte = (byte)(previousByte >> 0x1); v1 = byteArray[sourcePointer]; sourcePointer++; v0 = (byte)(a2 + v0); counter--; a2 = (byte)(v0 + 0x2); if (v1 == 0) { v1 = 0x100; } goto Part9; Part7: //Part7 sourcePointer++; v1 = byteArray[sourcePointer]; sourcePointer++; v0 = (byte)(v0 << 8); previousByte = (byte)(previousByte >> 0x1); v1 = (byte)(v0 | v1); counter--; if (v1 == 0x0) { goto Part11; } else { a2 = (byte)(v1 & 0xf); a2 = a2 + 0x2; if(a2 == 0x0) { goto Part8; } else { v1 = (v1 >> 0x4); goto Part9; } } Part8: //Part8 v0 = byteArray[sourcePointer]; sourcePointer++; v1 = (byte)(v1 >> 4); a2 = (byte)(v0 + 1); goto Part9; Part9: //Part9 v1 = (byte)(destinationPointer - v1); if (a2 == 0) { goto Part1; } else { goto Part10; } Part10: //Part10 v0 = byteArray[v1]; v1++; a2--; destination[destinationPointer] = (byte)v0; destinationPointer++; if (a2 != 0x0) { goto Part10; } else { goto Part1; } Part11: destination = SubArray(0, (int)destinationPointer, byteArray); File.WriteAllBytes(outputPath, destination); return; } Could anyone help me identify where the problem is?

Hi all - I've been obsessed with this little game for a very, very long time, and I'm trying to learn the file structures to try to make it work. I've got the files broken out into the different formats from the disk, and I've pretty confidently identified the .md model files. The mesh files themselves I'm exploring with ModelResearcherPro, and this is what I've come up with so far. most models have multiple meshes embedded, and there's some things I have and some things I haven't figured out yet. I'm using the attached GSG03.MD as the example model, which Iam pretty sure is a robot broken into multiple bits. (There are some models for like a map model, and it's broadly similar.) File Start: Little Endian First long 26 00 00 00 Mesh Start 7x long or floats of header - this is different for each file, but very consistent in length. First long is an address pointer to the end of the vert section, 4 bytes after the vert end marker. Then 6 other ones? Next is what I'm calling a New Mesh Indicator, but probably has some other function: 3x 00 00 80 3F (read as 1.0 as a float?) Next long is the address pointer to the of end of the mesh total (eg. 74 05 00 00 -> 0x0574) then a null long, then a set of bytes that are a consistent header within the file but I haven't sorted them out yet (eg: 17 25 06 00 A3 9E 9C FF 3F 3F 3F FF 99 99 99 0C 40 00) (somewhat consistent between files, at least the same header format, read as: 17 25 06 00 XX XX XX XX XX XX XX XX XX XX XX XX XX XX. ) Then an unsigned int short for....something? doesn't seem to line up with number of faces, or a pointer, or anything like that, but it changes for each mesh in the file. It's bigger than the vertex count, but that's about all I know. Maybe a total number of objects to process, and you subtract out the verts? Then a mix of triangular faces and normals, maybe? Triangular Faces using unsigned int shorts as vertex identifiers (I think), and probably normal vectors? Not really sure how to break through this, the faces don't really align with anything resembling sensible geometry. Also, there's periodically very large shorts, like FB FF, that break the vert indexing. They one's complement into somewhat sensible vertex indices, but no other rhyme or reason as far as I can tell, and I don't know how to do that automatically. At the end of the faces section, there's a long of FF 00 00 00, which I think is an end marker. Then another short 29 00, then another short that's different for each mesh, then another null short. Then a Vertex Count Short (unsigned int). This one I'm fairly confident in, and it's reproduceable. Then starts a mix of Verts and UV and maybe something else. I don't really know if this is right, but it makes the address math work out: each point is 6 floats: ??, U?, V?, X, Y, Z. Then after vertex count of verts, another FF 00 00 00 end marker. Next is 6 longs, and the first is the one that the End of Verts pointer addressed Finally either a short and a null short, or a long, but a low int 24 00 00 00, or 36 00 00 00, and is the address of the end of mesh pointer. Maybe it's actually the beginning of the next mesh? Sometimes there's an empty mesh at the beginning or end. Not sure, but they don't have an end of mesh pointer; sometimes they have a few vertexes, sometimes not. I'll get to textures eventually, but I'd really like to figure out what the mesh format is first. Anyhow, thanks for taking a read! I don't really know what I'm doing yet, but I'd really appreciate any guidance you've got on this. GSG03.7z

Hello, I believe this is a good place to have this topic, anyways, I want to know how I can extract the models from the following 3 games: Monster Rancher 3 (2001), Monster Rancher 4 (2003), and Monster Rancher EVO (2006 in the states, 2005 in Japan). These 3 games are for the PS2 console, and I want to know how to open the .dat files of these 3 games. I'm willing to accept your wisdom, provided that you know what you are teaching me. I thank you in advance, and I also provided 3 screenshots, one for each of the 3 games, and all of them are Monster Rancher related.

There are at least two types of i3d file formats, used within the .i3d files used in ape escape 3 and Rule of Rose uses .i3d files in .mdl files. I3D_BIN: Mesh ✔️ Bones ✔️ Skin ❌ I3D_I3M: Animation ❌ Tools: https://github.com/Durik256/Noesis-Plugins/blob/master/fmt_i3dg.py - Supports meshes. fmt_RuleOfRose_PS2__i3d.zip - Supports bones (made by Bigchillghost from xentax, reuploaded into reshax for quicker accessibility)

I want to rip from a game released only in Japan on PS2 called "Jigoku Shoujo Mioyosuga" developed by Compile Heart. More info for curious people on the game or franchise : https://en.wikipedia.org/wiki/Hell_Girl#Video_games or https://gamefaqs.gamespot.com/ps2/961167-jigoku-shoujo-mioyosuga I've extracted the files from the game and it seems most of the game data is stored in .PTD archives (other files are .PSS that are movies files). There are 11 PTD files and I don't know if they are encrypted or compressed. What I've noticed is that it seems there is a file index table named "PTDALL.PID" which seems to contain the location of files and data but I'm not very familiar with it so I'm not sure. Maybe with some bms script it will be possible to extract everything so thanks for the people that will be able to do this. Download link of the files : https://drive.google.com/file/d/1IIgGjkqZBM__VNdzehLaWAFwmuNUGckl/view?usp=sharing. The PTD files are in the DATA folder.