search

divyang4481 / bizhawk

Automatically exported from code.google.com/p/bizhawk
0 stars 0 forks source link

N64 - wrong image after loading savestate #226

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
1.7.3

3 frames (1 visible frame) after loading a savestate the image on the screen 
will revert back to the image it was before loading the savestate for 3 frames 
(1 visible frame). This is really distracting and didn't happen with bizhawk in 
the 1.6-range.

https://imgur.com/a/7x2zL

Original issue reported on code.google.com by moritz.g...@gmail.com on 26 Jul 2014 at 1:18

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago

Original comment by zero...@zeromus.org on 28 Jul 2014 at 11:07

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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