Is the save chunk being compressed before being base-64 encoded? The save game data isn't supposed to be edited manually anyway, so that seems like it would be a good move. (Gens can probably decode and decompress it much faster than Notepad could even open a file without that compression, and Gens only has to do that once when starting to play the movie, anyway.)
Compression is certainly possible to implement, but it's not crucial. It can be added later easily enough.
upthorn, you seemed to say that a GM2 implementation should only parse the first button list for a given controller, but you edited the wiki to say the last. Since the first is more consistent with your post, I changed the wiki.
No... I actually meant last. For the following two reasons:
1) When a user adds new data, the instinct is to add it to the end of the line, not the beginning.
2) It seems to require fewer lines of code to parse lines in reverse. I would assume this means it's more efficient. (This would also make the first segment for each controller it reads the last segment on each line in the text file, which is consistent with my suggestion of using a boolean flag to to skip future iterations of the parse loop if it's already encountered that controller number)
How fleeting are all human passions compared with the massive continuity of ducks.
The first point is clear and looks like a good starting place for discussion.
The second point I don't get. Do you mind elaborating. I'm viewing the file as already having been read into memory, so I don't see what difference it makes one way or another.
It's not a matter of loading into memory, it's a matter of parsing the loaded data.
I have it set up with two char *s (to reference null terminated strings.)
One stores the whole line, the other stores from the final comma to the end of the line.
When it's done parsing that segment, it sets the comma to a null character, and finds the new last comma in the line, and parses from that.
That's not a very good explanation, but my loop looks like this:
(we get the line somehow, either it's passed to us read from a file, or read from elsewhere in memory)
char *Line,*PadData;
Line = strchr(Line,':');
Line[0] = ',';
while ((PadData = strrchr(Line,',')) != NULL)
{
//stuff to parse the PadData goes here.
//I use a "strcspn"s to get the controller, so that the controller number can actually appear anywhere in the segment
//Then I use strcspn in a nested while to get each button.
//The button must then be set to an invalid button value for this to work,
//but I could instead use strpbrk and gradually decrease the size of the string we're working with.
//That would probably be faster, but I can't test any of this yet because I haven't got all the chunk parsing segments worked out
//for loading GM2 and GM2TEXT files.
PadData[0]='\0';
}
In this way, we only have to search through the segment we're currently parsing, which I imagine would be much faster than searching the entire string, and then having to figure out which set of commas each character is between. Of course, there are probably other ways that I haven't thought of, but this seems like the most efficient one.
How fleeting are all human passions compared with the massive continuity of ducks.
Question. I thought I already knew the answer, but looking over some of your source, I feel I need to ask.
Does controller number "2" reference "Player 2" or "Player 1B"?
I think it should reference 2, then 3-5 for 1B-1D 6-8 for 2B-2D, because while it's somewhat nonintuitive for players 1-1D not to be contiguous, it's less intuitive for "2" not to mean Player 2.
How fleeting are all human passions compared with the massive continuity of ducks.
I've been working under the assumption that the controllers go 1, 1b, 1c, 1d, 2, 2b, 2c, 2d. The way I intuit things is pretty closely tied to the code I've looked at and written, so my intuition is wierd. I can see how your order makes more sense from the perspective of a user. I updated the wiki.