Alrighty, here is a utility I wrote to address some of the common frustrations I find with FCM format.
(1) I've experienced a few times where a reset is not placed at the beginning of the controller data on my FCM. This is troublesome because FCM is not erasing the savestate it automatically stores, even on a start-from-reset movie, is not reset, and sync could be affected (dirty SRAM). This also will not allow a movie to be submitted here (the submission page will give an error).
(2) Speaking of that savestate, it's completely removable from the movie, and in most cases will not affect sync. One counterexample I can think of is Kirby's Adventure. For that movie I left the savestate in, but set it to all zeros.
(3) The length of the movie is stored in several places, and the one that the submission system looks at here does not need to coincide with the actual length of controller data to play in FCEU correctly.
FCM Fix - v4
This utility has a few different checks available.
Savestate removal - Remove an embedded savestate from an FCM if it is marked to start from reset or power-on. File sizes usually drop by about 80k.
Reset check - Verifies that a reset or power-cycle command is at the beginning of the controller data if the movie is marked to start from reset. (Without this command, a submission will fail the checks of the TASVideos submission script) Also gives the option to change a reset to a power-cycle.
Validate length - Compares the length stated in the movie metadata with the actual length of the controller data, and corrects the metadata if it is inconsistent. (This is important because the TASVideos submission script gets the movie time from this possibly faulty value)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
I've finished v2 of this utility. Same link as above.
Fixed a bug that checked for reset/power-on incorrectly
Implemented "Check Length" routine
Renamed fixed files based on which fix was selected
I won't be implementing the "Check Stuck Buttons" routine, as it is caused by incorrect hex-editing that puts the end of the controller data between an update byte and a delta byte, which is fixed simply by re-recording the end of the movie in FCEU.
The length checking routine is important, because submissions here go off of position 00C in memory to determine the time, regardless of the actual length of the movie. This publication is an example of an incorrect time in the header (due to my own inaccurate hex-editing that was not validated before submission).
Since we have at least one user who intentionally changed their re-record count, this is something that it would be a good idea to validate for current and future submissions.
Hopefully there are no bugs :)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Separated reset-checking from savestate-removal. (Still does not remove the savestate if a movie is marked to start from it)
Fixed a bug where savestate-removal was causing an empty file in certain circumstances.
Focus remains on the same filename after applying any of the checks, for quick 1-2-3 testing.
If there are other things that someone would find handy with this tool, please let me know. If not, and if no bugs are found, this is probably the last update for this utility. Hopefully it's been helpful!
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Separated reset-checking from savestate-removal. (Still does not remove the savestate if a movie is marked to start from it)
Fixed a bug where savestate-removal was causing an empty file in certain circumstances.
Focus remains on the same filename after applying any of the checks, for quick 1-2-3 testing.
If there are other things that someone would find handy with this tool, please let me know. If not, and if no bugs are found, this is probably the last update for this utility. Hopefully it's been helpful!
Will the fixed version still sync properly with movies recored with non-fixed versions?
I think i've watched about 70% of the TAS's on this site... It's become one of the first sites I check daily for updates.
I'm going to start posting more.
Will the fixed version still sync properly with movies recored with non-fixed versions?
Most movies should.
The embedded savestate rarely affects the movie if it starts from power-on or reset, in my experience. One example of the contrary was removing the savestate from my Kirby's Adventure run - it desynced somewhere in the first couple levels. So I inserted a big batch of zeros where the savestate was, and did the run from there. My theory is that the battery back-up was saved somehow as well, affecting sync in minor ways.
If adding a reset causes a desync, then the movie was basing something off of not having a reset, which is generally bad (for submitting movies here, at least). I've only had the "no-reset" happen to two of my FCM files (and one of Randil's), so it's not too common of a bug, and each time, adding the reset didn't cause a desync.
Length checking doesn't change anything except how long the initial dialog box says the movie is.
Bisqwit wrote:
I'd prefer it start from poweron rather than reset, though.
Currently, if the first byte is 81h or 82h, it's considered good. If it's any other value, 82h is inserted, the rest of the input bumped forward 1 byte, and the "length of controller data" is increased by 1 byte.
So it actually is inserting a power-on. I just often forget to make the "reset vs. power-on" distinction when talking about it. ><
You might mean that movies with 81h should be changed to 82h. I didn't do it this way to be consistent with the submission script, but if the other way is preferred, I can update it. (Or, give an option for either.)
I updated to v4 which now differentiates between reset and power-cycle, with the option to change a reset to a power-cycle if desired.
I can host the source somewhere, if anyone is interested in it. (VB6)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
