So, let's talk about file formats for these external j2t files. (And extensions too, if people like? I said .j2tdata earlier, but I might prefer .j2tprofile.)
I think it's fair to expect that the files be versioned. Coming up with a good system for metatiles/eyecandy definition could take some work, as Jerry has illustrated, but the stuff I listed in the first post only required two bytes per tile and that's quite straight-forward. Here's what I'm thinking for a first pass:
Code:
struct J2TProfile (version 1)
{
char Version;
short NumberOfTiles; // not necessarily redundant from the .j2t, since tilesets may be expanded and people might want to use a single .j2tprofile with multiple .j2t files.
char Properties[64]; // don't know what would be put here; just allocating some space in case it might be necessary later.
short NotesLength;
char Notes[NotesLength]; // any information the profile compiler might think helpful to provide for users. A quick built-in readme, if you will.
short SmartFlip[NumberOfTiles];
short Alternate[NumberOfTiles];
}
Additions in later versions, such as a working metatiles system, would go at the end of the files. That way a program that's only familiar with version 1 (for example) but receives a file of version 2 or 3 could still read the data it would understand, since those data would be at the start of the file, and could simply ignore everything after that.
__________________
|