[Scummvm-tracker] [ScummVM :: Bugs] #11399: MOHAWK: RIVEN: Return to Launcher & Quit don’t autosave if GMM opened by F5.

ScummVM :: Bugs trac at scummvm.org
Wed Apr 15 10:18:38 UTC 2020


#11399: MOHAWK: RIVEN: Return to Launcher & Quit don’t autosave if GMM opened by
F5.
---------------------+----------------------------
  Reporter:  macca8  |      Owner:  bgK
      Type:  defect  |     Status:  new
  Priority:  normal  |  Component:  Engine: Mohawk
Resolution:          |   Keywords:
      Game:  Riven   |
---------------------+----------------------------
Comment (by macca8):

 My assessment that autosaves created by RTL were somehow leading to
 freezes when reloaded was incorrect. Please accept my apology if I’ve
 caused you unnecessary frustration in trying to resolve this matter.

 Further testing revealed that the freezes were due to a variation of the
 known SDL 1.2 bug affecting macOS 10.9 & later, which causes a freeze
 after multiple switches between windowed mode & fullscreen in the same
 session.
 The autosaves created are perfectly fine, with the minor issues all
 resolved by the fixes applied in this report and #11417.

 With regard to the pending issue with the autosave created when exiting
 during a cutscene, I was wondering if repositioning the
 ''saveAutosaveIfEnabled()'' call might fix the issue?

 We already know that, prior to the change, Quit/RTL calls from keyboard &
 GMM (via Ctrl+F5) were being handled correctly by the autosave call
 positioned within the ''processInput()'' method.

 With its current positioning, the autosave method is called much later
 than previously. Is it possible that the extra code inside ''doFrame()'',
 that runs before the autosave is called, may be changing the status of
 ''canSaveAutosaveCurrently()'' from false to true?

 Would repositioning ''saveAutosaveIfEnabled()'' from its current position
 to immediately after ''processInput()'' in the ''doFrame()'' method,
 placing it closer to its previous position - where it was working properly
 - and avoiding all the extra code in ''doFrame()'', possibly fix the
 problem?

 It may be completely irrelevant, but I thought it worth asking the
 question.
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/11399#comment:8>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM


More information about the Scummvm-tracker mailing list