Since people seem to like the ideas of zip files, I will delete the "compressed?" flags. Should SRAM/states always be compressed within the movie file anyway, like I suggested? I think that's a good idea at least.
>Assuming that Gens can natively read and write a nice text format, is there any reason the binary format would need to be hexedit-friendly?
People might want to write their own tools for manipulating the frame data. There's no reason to make it hexedit-unfriendly at least, seeing how unpopular FCEUs precompressed format is.
Changes I made to the GM2 page:
- I suggest removing the PAL/NTSC flag and just having the country byte. See page.
- Need clarification on how the BIOS chunk works (I think what we have isn't enough).
- Removed "from reset" starting condition. I've seen enough submissions making the mistake of starting from reset instead of power-on, and we have the ability to record resets now, making this unnecessary.
- Names of states would be neat, but not necessary. Having them ordered by the frame they start would also be good, but perhaps it's not necessary to make it a format requirement
---------
About peripherals:
http://www.vidgame.net/SEGA/peripherals.htm
The ones that would need a number are
- Mega Mouse
- Sega Menacer (zapper)
- TeeVGolf (golf simulator)
- Batter Up! (baseball simulator)
The ones that probably don't are
- All the turbo controllers (we have autofire already)
- Activator ring (sends the same signals as a regular controller)
How do we handle Multitaps? I'm not sure - we have a number of controllers byte, but maybe it's not the same thing? Do some games detect multitaps? It seems like Gens only accepts either 1 or 4 controllers on one port anyway, so perhaps this needs to be taken into consideration.
One suggestion for solving it is having a multitap number and a "no controller" number. The number of ports on a Genesis is always two, both must be assigned a value.
0 = no controller
1 = 3-button
2 = 6-button
10 = multitap (next four numbers are controllers connected to it)
1-player:
2
0
3 players on multitap:
10
2
1
2
0
0
6 players on multitap, 2 on first team:
10
2
2
0
0
10
1
1
1
1
We could still have a "number of controllers" byte for the sake of searching through the file. It would always be 2, 6, or 12, and it wouldn't reflect the number of people that are actually playing. Probably someone has a better method for handling this.
------------
Someone mentioned SMS support. Without making ourselves much trouble, I think we could:
- reserve a number for type "SMS controller" in controller configuration
- reserve a flag/number for type "SMS game" in 'rom info'
- make a 'MSpauses'-chunk identical to the 'resets '-chunk for the pause button located on the SMS
Speaking of 'rom info', any reason why game type should be flags instead of a number? A game can't have several types at once. I changed it in the specs, change it back if I'm missing something.
I'd also suggest:
Merge 'record ' and 'author '.
Merge header and 'version '.
