-
Notifications
You must be signed in to change notification settings - Fork 66
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
New implementation of the savestate loaded at startup option.
The savestate will be loaded on the first safe state interrupt instead of being loaded on the first frame.
- Loading branch information
Gillou68310
committed
Oct 19, 2016
1 parent
07dba79
commit 334db80
Showing
1 changed file
with
12 additions
and
12 deletions.
There are no files selected for viewing
This file contains 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
334db80
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Gillou68310 @richard42
I know it's years after but I realize this break the possibility to use
--savestates
with--testshots
because screenshots are taken before the save states is loaded.What about also execute frame callback after the "first safe state interrupt"? This would guarantee the save states is loaded before take screenshots.
Any idea?
For information: My original attempt to fix the save state loading before frame was here: 7d5247b#diff-803c5170888b8642f2a97e5e9423d399, you can see the
main.c
history here: https://github.com/mupen64plus/mupen64plus-ui-console/commits/master/src/main.cYesterday I worked again on my regression test tool chain so I only see the problem now.
334db80
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why this change would prevent the screenshots from being taken after the state is loaded. The M64CMD_STATE_LOAD command just sets the savestate job to savestates_job_load. With the original code, this would get set during the first frame callback. With the new(er) code, it will get set just before starting the emulation running with M64CMD_EXECUTE. I presume the interrupt handler would get called before the first frame is rendered.