Name: Anonymous 2007-02-05 15:05
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?
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?