Closed GoogleCodeExporter closed 9 years ago
Confirming this issue does appear in SVN r7380.
I loaded up Majora's Mask, let the demo play, then made a Save state. Rebooted
the core. Went to the Title Screen (pressed Start). Paused the emulator,
loaded the save state. Unpaused the emulator and I saw the loaded state
screen, then a flash of the main menu then back to my savestate point.
Plugins used:
Pure Interperter
Z64 HLE
Glide64mk2
320x240
Default settings.
Original comment by hegyak
on 26 Jul 2014 at 2:55
Original comment by zero...@zeromus.org
on 28 Jul 2014 at 11:07
I think this is caused by the GPU plugin architecture sometimes issuing
framebuffer updates to the emulator frontend before actually rendering
anything. therefore, the previously rendered framebuffer gets taken. This isnt
a problem in other n64 emulators because they arent saving an additional
screenshot to display immediately after loadstating, so the spurious
framebuffer matches what's already on the screen
Original comment by zero...@zeromus.org
on 28 Jul 2014 at 11:08
in r6834, we made a change which is, i think, succinctly described as 'obey
plugin choice of when to submit framebuffer'. Some plugins, with some settings,
choose to submit framebuffers before actually rendering anything. Note that
this effectively creates an extra frame of lag. This is by design! Those
settings exist for some (lame) reason, most likely to fix specific games. Users
can solve this with different plugin preferences. We could solve the garbage
display by fixing the _bug_ in those plugins which produces frames when
nothing's been rendered, but that won't solve the lag, since the lag is
intended.
Original comment by zero...@zeromus.org
on 2 Aug 2014 at 7:10
Before r6834 n64hawk was essentially using the plugins incorrectly by grabbing
a video frame every frame. This worked on Zelda games, but caused the
flickering in Paper Mario (and possibly other games). r6834 fixes this bug by
allowing the plugins to let n64hawk know when a frame was actually drawn.
However, as a result n64hawk now listens to the plugin's decision of when to
grab a frame, which may or may not be correct. In the case of Majora's Mask and
Ocarina of Time the default option was to get the frame before it has been
rendered, resulting in old data being shown (this issue report).
For MM and OoT This problem can be avoided by changing a setting in the
plugins. For Rice the setting to change is "Screen Update Setting" to
"SCREEN_UPDATE_AT_VI_UPDATE_AND_DRAW", and for Glide64 and Glide64mk2 the
setting is "Buffer swapping method" to "Old". This fixes this issue for those
games. In r7488 I have changed the defaults for these settings in the gameDB,
so if you use the default settings the change will be automatic, otherwise you
will need to manually change this setting.
As zeromus said, some games may require a different setting, so this same issue
may arise for other games. I suggest trying to change those options first to
see if it fixes the problem. If so that setting should probably be changed in
the gameDB as well. If changing these settings does not fix the problem for
those games this issue will need to be revisited.
Original comment by pjga...@gmail.com
on 2 Aug 2014 at 11:04
Loading a savestate with the emulator at frame 0-75 in OoT may cause blank
frames to be shown until the video plugin redraws the screen. This problem will
go away if the state is loaded after the 75th frame, and won't come back until
the core is rebooted. A similar problem may be present on other games. If this
becomes a major problem we can revisit this issue.
Original comment by pjga...@gmail.com
on 2 Aug 2014 at 11:36
Original issue reported on code.google.com by
moritz.g...@gmail.com
on 26 Jul 2014 at 1:18