gonetz / GLideN64

A new generation, open-source graphics plugin for N64 emulators.
Other
778 stars 180 forks source link

Banjo-Kazooie time flickering #1969

Open ghost opened 5 years ago

ghost commented 5 years ago

When using Bizhawk (and GLideN64), the N64 logo in the PAL (E) version of Banjo-Kazooie exhibits flickering (this is not an issue with the NTSC version of the game). Disabling framebuffer emulation fixes the problem, though this breaks many in-game effects and is not a suitable workaround. The flickering is time-based, meaning a frame is displayed and then on occasion the next frame which is displayed shows content which should appear previously in time. The displayed video judders forwards and backwards through time.

The most recent version of Bizhawk at the time of posting can acquired here: https://github.com/TASVideos/BizHawk/releases/download/2.3/BizHawk-2.3.zip

To access the plugin settings in Bizhawk, load the rom and then select N64 > Plugins. Bizhawk uses M64P as a N64 core, though now it's somewhat outdated.

The problem is not present on stock M64P. This problem is persistent on all versions of Bizhawk which have had GLideN64 present. The problem is also persistent when building the latest GLideN64 master for Bizhawk, though building this requires some changes in contrast to standard M64P: https://github.com/TASVideos/GLideN64

Given that it works in M64P and not Bizhawk, I initially assumed it was a Bizhawk issue and so I contacted the Bizhawk developer, specifically zeromus. Here's part of an IRC chat log (with all the quoted messages coming from him):

it certainly looks like the depth buffer is getting lost somewhere if you break the color copying from framebuffer youll see that the depths are messed up on the same cadence as its whole copying effect (youll see it flicker visible and black, and the depth buffer is broken every time its visible) if i reboot core and then immediately load a savestate, it works if the n64 logo ever shows up, its broken possibly a combination of timing factors gets it out of the expected cadence. anyway due to that detail it sounds like a bug in gliden64 which manifests only under chaotic conditions for instance it could be as simple as if the intro timing is off by one frame it will get whacked out or maybe its just a variable gliden64 isnt savestating thats actually the simplest explanation well. thats just a useful tidbit the fact is it does go off the rails during the n64 intro i guess thats suggestive it could be an uninitialized data problem. you should try it on an older bizhawk with an older gliden64

I'm aware that having an emulator-specific problem on an altered build of the plugin may complicate the issue's resolution, so I'm happy to provide any extra information or answer any questions in relation to this issue if it will help out.

Jj0YzL5nvJ commented 5 years ago

https://github.com/mupen64plus/mupen64plus-core/pull/485#issuecomment-426179138

ghost commented 5 years ago

Thank you for that, It sounds related and I feel better knowing the issue has been encountered before to some degree. In specific this case, the problem is present on RSP HLE too though.

ghost commented 5 years ago

This issue is not exclusive to the PAL game and Bizhawk any more. It also occurs on the NTSC version when used with Mupen 0.5 re-recording (and likely standard Mupen 0.5). I know it's an older emulator, but it might help track down the solution having a more accessible emulator exhibit the problem as well. The issue should be apparent upon booting the game.

Mupen 0.5 re-recording can be downloaded here: http://adelikat.tasvideos.org/emulatordownloads/mupen64-rr/Mupen64%20v8%20installer.zip