--Because there are way more bytes used to represent the other GUIDs than this one, I just appended -0000-0000-0000-000000000000 to this per zeromus' request.
-Got rid of the hex part of the BytesToString function. We apparently have BizHawk.Util.BytesToHexString.
-Converted BytesToString to r.ReadStringFixedAscii, an extension method. I've determined that extension methods are cool and that I should use them more often.
-Fixed some error and warning messages:
--Made it so that the first .FCM warning is shown instead of the last.
--Added an error for .FCM files that aren't version 2.
--Did the same for ImportVBM, but with version 1.
-Cleaned up comments / code throughout.
-Fixed the file format for GBx; it had an extra bar which made reading Player 1 impossible.
-Seemingly finished ImportVBM.
--The results seem same. I have no way of testing whether they sync up or not.
--As I can't actually handle additional controllers, I just skip the bytes for them.
--As I can't actually handle the miscellaneous buttons and commands (Ex. L, R, Reset), I just give warnings whenever they come up in the file.
TODO: ImportGMV, ImportVMV, ImportNMV, and maybe ImportSMV...I'm going to need a new assignment soon! :)
-Set the buttons to the opposite state when they are updated.
--Presumably, this is how this works.
-Read the delta bytes.
TODO: Figure out where in the world the writing of frames actually comes into play. Bisqwit gave me some insight on this.
-Set the buttons to the opposite state when they are updated.
--Presumably, this is how this works.
-Read the delta bytes.
TODO: Figure out where in the world the writing of frames actually comes into play.
-Added a FourScore header and applied it to ImportFile and ImportFCM.
--Not sure if there's any equivalent header for FMV/FCM.
-Seemingly have the update bytes being read properly.
TODO: Make ImportFCM actually utilize the update bytes to write frames.
-Added PAL handling to ImportText.
-Finished the header and metadata of ImportFCM.
TODO:
-Input handling for ImportFCM.
-Find out what the format for the FDS data is on FMV, as it occurs to me that I already handle FDS data in ImportText by giving warnings, so I might as well do the same thing in this case.
-Figure out whether or not I should be using "using" for the BinaryReader objects, as it seems like they do in fact have .Close() methods.
-There's "FDS data" stored in the frames of FDS recording. I have no idea how to handle this. If we do in fact support these features, they should be utilized in the TODO section provided.
-99M syncs with this...isn't this a problem? Wouldn't this imply that bizhawk is as inaccurate as Famtasia? I'm pretty sure this run didn't sync when I tried it on my now broken NESBot.
TODO: I guess I'll try to move on to ImportFCM now. Although I heard this is a difficult format to work with, my favorite console is the NES, and this'd be useful for console verification if the NESBot Lua script gets adapted for bizhawk, so I think I'll give it a shot.
brandman211