Skip to content

Saving and loading state should not cost lag frames - #294

Draft
idlechild wants to merge 1 commit into
tewtal:next-updatefrom
idlechild:lag
Draft

idlechild wants to merge 1 commit into
tewtal:next-updatefrom
idlechild:lag

Conversation

@idlechild

Copy link
Copy Markdown
Collaborator

This needs more testing. Also it needs to be communicated (I plan to make a post in the practice-hack discord channel in the next 24 hours; it's just getting late to do it tonight and I have a busy day tomorrow).

There is a scenario where even though costing a lag frame on save/load is "wrong", it's also been this way for a while; it's also not that wrong... I think this is the right change to make but there could be differing opinions on it. I'd also feel better after testing it more. My own testing on console shows improvement but I want to see it working in the BizHawk TAS as well (won't have time to test that until tomorrow).

@idlechild

Copy link
Copy Markdown
Collaborator Author

The above solution doesn't quite work; at least not in the TAS testing. I think you can trigger two NMI events on load and the logic I made assumes there will only be one. It should be fixable.

@idlechild

Copy link
Copy Markdown
Collaborator Author

This version seems better. Passing the TAS tests and also cannot reproduce the lag frame when saving/loading in elevator room.

For those wondering, the TAS was saving/loading in the middle of a short-charge with a single-frame tap to verify that the extra NMI cycles on save and load aren't messing with gameplay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant