just stopping by to say that i have figured out the SRT0 heading.. quote from my last post on last page:
it's been known for a while. >.>
unsafe struct SRT0
{
public const uint Tag = 0x30545253;
public const int Size = 0x28;
public BRESCommonHeader _header;
public bint _dataOffset;
public bint _stringOffset;
public bint _unk1;
public bshort _numFrames;
public bshort _numEntries;
public bint _unk2;
public bint _loop;
I told you, I just didn't change the actual display yet. I'm still working on parsing the data correctly.
hey...
I just had a thought...
has anyone tried patching a GCN game with Riivo??
also...
if the main.dol can be patched,
then could you also basically replace the game??
for example...
I lost one of my fav games "TimeSplitters Future Perfect",
but I ripped the game before I lost it...
now if this goes as I think it would then I'd have to patch all of Brawl's files with dummy data,
and add TS3's files to the SD
(thus replacing main.dol)
anyone think that'll work??
I highly doubt that would work at all.
Hexidecimal parsing, eh.... I need to learn that. It always seemed too overwhelming for me to pick up on my own
But an undo button can be done easy enough, the key is to make sure it doesn't lag or screw up.
Reading hexadecimal files is easy. XD
How you interpret the values you read is the hard part. (Whether it's an offset, data size, or count and what it's referencing, or actual data and how to get to it)
Here's an explanation, or at least how I do it.
A byte is, well, a byte (00)
A short is two bytes (00 00)
A float or int is four bytes (00 00 00 00)
There are also two types of values:
signed (can be negative) and
unsigned (can't be negative).
Throw "u" in front of the name and the value will be read as unsigned, except for float and byte.
byte defaults unsigned, so an "sbyte" is a signed byte.
float values are always signed, no matter what.
Now for example,
I can tell that this is a 4x3 matrix of float values because there's 3F 80 00 00 (1 in float) for scale values in a 4x3 matrix.
The questions that I ask myself though, are how do I get to this matrix and what does it do?
Basically you want to follow offsets first to get a general map of the file. Then you start to parse the file based on your notes and refine it based on the errors it throws (if there are any). After you've fully parsed the file and have a bunch of unknown values, that's when you start to edit those unk values and see what happens.
When you first start to parse an unknown file, read the bytes in groups of 4. (00 00 00 00) This is the maximum size of a value, unless there happens to be a 64bit long value in the file (which there usually isn't...)
Float values are generally easy to spot because they *usually* start with 3 or 4 in the first half of a byte on the first byte of four, like this:
int values are easy to spot too, because they usually look something like this: 00 00 01 25. They start out with 0s and end with actual values, which is pretty much the opposite of what float values look like.
Whether to read as byte/short or signed/unsigned instead is where it gets a bit tricky.
Generally if you see something like this: 03 00 01 25
Then you probably have a
byte (03),
byte (00), and
short (01 25) value.
Then again, the short could be two seperate byte values.
I work out whether they're signed or unsigned once I've parsed the file.
Data sizes should never be negative, but offsets can be negative sometimes (like the MLD0/BRRES offsets)
The first step to parsing an unknown file type would be to find the first major differences between different files of the same file type.
That would be awesome if you could work out the bugs with the undo/redo buttons. There's probably a better way than using a modulated list of save objects, but I dunno. XD
