I don't know if this belongs in /prog/... since I intend to write a viewer for the (unnamed game's) environments, though, I suppose it does.
When reverse-engineering a file format in a certain game that holds the world data, what sort of things should I take into account considering it's a game that runs on PS2 architecture?
As the game would be slow loading its areas if it did a bunch of field-size conversions during load-time, the DVD would likely store its data as the PS2 hardware would most readily see it... for lack of a better way to put it. This is what I have to determine first before I even consider figuring out the file structures through trial and error.... For example, would vertices (x,y,z,etc) values more likely to be stored as 32-bit floats or 64-bit floats, going by the PS2's FPU specifications? And what about endianness? Does the PS2's math registers store numbers in big-endian or little-endian? And, *if* different from the endianness on my own computer, then how come ASCII text strings in binary files don't look all switched-around?
Reversing fileformats on the PC is easy for me -- since I know how files are usually written.
Reverse-engineering something for a mysterious architecture? I think not.
Name:
Anonymous2007-02-05 16:34
And, *if* different from the endianness on my own computer, then how come ASCII text strings in binary files don't look all switched-around?
First of all, they're probably not ASCII at all, which is a 7-bit character set, but rather some 8-bit set, like windows latin, or whatever.
Anyways, endianness affects how bytes are ordered in values that require more than one byte to hold, like utf-16 characters, which come in both big-endian and little-endian flavor. 8-bit characters require a single byte to hold (you should know this), so they're not affected by endianness.
>>4
Fileformats differ very little between architectures. For general formats, you usually only need to pay attention to endianness. Of course things like textures and audio often are stored in a very architecture-specific way, but you can usually still easily figure out the headers.
Disassembling executables and figuring out what they do with the files also tends to help (PS2 = MIPS = easy). If you're really lucky there could even be some debugging info left (like a symbol table).
>>11
Truth, games don't need that level of accuracy, and they will probably be converted to 32-bit floats before they are sent to the graphics card anyway. If the card supports 64-bit floats, then it takes twice as long to send the data instead.
almost all modern file formats designed for large files are compressed
it's almost always faster to load the compressed file and uncompress it than to load the raw file from slow media
the real way to do reverse engineer the file format, if you must, is to run an emulator and see what happens when the files are loaded and how the loaded data is used
>>24
If you don't want to help, you are free to refrain from posting. We're posting here either way, so no point in whining about it.
>>1
First, I'd try this (very) blunt test: right-click the file (after copying all the files to a folder on your HDD), then select "Extract here". Yes, you read that right. That is, providing you have any decent archiving program with shell extensions. ``Decent'', as in, can extract archives inside files regardless of their extension. (For example, 7zip can extract the packages found in installation EXE files.)
This test is the lazy way of searching for valid archive headers in the files. It will most likely fail, but if it succeeds you're lucky as shit and things would start getting more interesting and a whole lot easier.
This actually works with countless games' data files.
Bringing /prog/ back to its people
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy