Repository navigation
Conversation
Mupen 1.5.0-3 (extended version 4) stores cpu_cf and rcp_lag_factor as doubles at 0x030 and 0x038. ToBytes wrote that area as zero padding, so the roundtrip check in LoadBytes threw on every movie recorded with 1.5.0-3. Read and write both fields, and write back the bytes this class doesn't model from the loaded header instead of zeros, so later additions to the format don't break loading. Fixes FramePerfection#66 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
FramePerfection
approved these changes
Oct 9, 2026
FramePerfection
left a comment
Owner
There was a problem hiding this comment.
Looks fine to me, too.
A quick notice on merging this into Development though:
For fixes like this, it could be better to branch off the Release branch and PR into that one as a "hotfix" - it'll be merged into Development, too, of course, but it's easier to release a new fixed version (0.9.2 in this case) without the other stuff on Development (Wine support things currently, which I may not want to release just yet, because that'd definitely be a 0.10.0, and then there are other things I'd like to get into that, and so on.)
I'll leave this open until tomorrow or so if you want to do that @frKieran .
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #66.
Movies recorded on Mupen 1.5.0-3 can't be opened in the M64 tab: it shows "Unhandled exception has occurred… Specified argument was out of the range of valid values." and the movie isn't loaded. Movies with extended version 0 or 1 open fine.
Extended version 4 (1.5.0-3) added two doubles to the extended data,
cpu_cfat 0x030 andrcp_lag_factorat 0x038 (CoreVCRExtendedMovieDatain Mupen'sCore/Types.hpp).M64Header.ToBytesstill wrote 0x030..0x0C3 as zero padding, so the roundtrip check at the end ofLoadBytesfailed as soon ascpu_cfwas set (1.0 isf0 3fat 0x036, so every 1.5.0-3 movie).This PR:
M64Headerdoesn't model (0x01E, 0x040..0x0C3, 0x0EA..0x121) back from the loaded header instead of zeros, so the next extended-format addition doesn't break loading again.Tested on Windows with a Release build of this branch (and the same change on v0.9.1): a 1.5.0-3 movie, an extended v1 movie and a v0 movie all open, and Save leaves each file byte-identical apart from the VI count ("Max Out VI Count"). Without the change, the 1.5.0-3 movie throws as above.
Related, on the Mupen side: with Mupen's "Extended Movie Format" option off, 1.5.0-3 still writes
cpu_cfthere, so turning it off doesn't avoid this. PR by Claude Code, take with a grain of salt.