The VG Resource

(05-19-2012, 11:24 AM)Mighty Jetters Wrote: [ -> ]...I was not expecting this! If you figure all this out, will we be able to export the Pokémon with their rigging as .DAEs (as well as .OBJ of course)? That would be a major breakthrough for the Colosseum project. We wouldn't have to use printscreen rippers!
Will it also export all the textures as .PNG (unlike BRRES Viewer that only auto-exports as .TGA)?
Sorry for all the questions, I'm just really excited to see a potential new FSYS Viewer.
I genuinely hope you can crack the format and complete this program, so best of luck to you!

(05-24-2012, 05:08 AM)tykel Wrote: [ -> ]Reverse-engineering? What a wonderful opportunity to procrastinate!

So, you still have not explained very clearly what an FSYS file is. A bit of googling led me to believe it is a video/audio file used primarily in Gamecube Pokemon games? Secondly, am I right in saying the FSYS file type is not well documented?

Some searching made me come to this (http://forum.xentax.com/viewtopic.php?f=10&t=8890), some guy has started something similar. You should definitely check this out if you haven't already.
In his pseudo-code, you can see the following structure:

Code:

struct fsys_file_header {
  char magic[4]; //FSYS
  uint32_t t1;
  uint32_t t2;
  uint32_t file_size; //DATA_COUNT?
  uint32_t t3;
  uint32_t t4;
  uint32_t info_offset; //start address of info header
  uint32_t data_offset; //DATA_BASE, start address of data
  uint32_t file_size;
};

struct fsys_info_header {
  uint32_t array_offset;
  uint32_t name_table:
  uint32_t base_offset;
};

struct fsys_fdat_entry {
  uint32_t data_hash;  // CRC-32? You probably know more than me.
  uint32_t offset;
  uint32_t size;
  uint32_t t1;
  uint32_t t2;
  uint32_t z_size;
  uint32_t t3;
  uint32_t t4;
  uint32_t t5;
  uint32_t name_offset
};

/* ETC.... */

You may already have got this far, but hopefully this will get you started in the right way.
And those numbers at offset 06 & 07? Well, they do not seem that important if the other person's doc. is to be believed, as they fit into a temp (ie. dummy) variable. Perhaps some metadata, maybe information about the compression, or file version information.

As for LZSS, that is a classic LZ compression scheme, which basically is an improved LZ77 with less redundant data sent.

I see you are using Windows from your screenshots, but let me say this: there is a reason Linux is called a hacker's OS. There are many little utilities available to encrypt/decrypt strings on the command line, among other things. You should be fine with a good hex editor, and I recommend something to prototype quickly (not C++; a scripting language like python, maybe) for experiments.

Sorry if I have oversimplified or repeated stuff you know already.
Good luck.

EDIT: As per the C++ debate; C++ is a very complex language. It is one of the only languages not to have a context-free grammar representation, because of its many ambiguities. It is also one of the slowest to compile. BUT it is definitely one the most powerful you can use: native, object-oriented, template meta-programming, ... There is a reason to the fact it is the #1 language in video games, high-performance programs, and many other areas.
My 2 cents: perhaps C# would have been a wiser choice for a GUI program. Or at least, the GUI side of it, it is much simpler. C++ is a bit more work, but you seem to have something good already, so carry on, good sir.