Majora's Mask Flickering

[ichee]

Screen flickering in Majora's Mask. Reproducible by opening the subscreen, followed by opening the bomber's notebook then exit both notebook and subscreen, then open and close the subscreen again. May need to repeat a few times.

Does not occur with Public Release 2.0.

[ghost]

I thought this was solved recently? I can't reproduce this with this build (latest master) https://drive.google.com/file/d/0B0YqMPjGo3B2dThIZXctNU1fbkE/view?usp=sharing

I did have a minor issue after with the camera and the screen flashed/flickered but I could solve it by disabling the store shader cache option.

[ichee]

Issue is still present in latest master. Tested on all default settings, except with shader cache disabled. Just open the subscreen and bomber's notebook, then close both. Then reopen and close subscreen. Toggling fullscreen fixes flickering when it starts.

[ghost]

I can confirm this but I had to go in and out several times before I could trigger it. However it only happened with the option "Same as output resolution" as "Original N64 resolution" worked correctly.

Seems like Majora's Mask is very sensitive to changes these days.

[ichee]

Occurs with "Original N64 Resolution" too.

[ghost]

That's weird, I tried 15 times with "Original N64 resolution" and it didn't occur for me but with "Same as output resolution" it happened after a few times.

I'm stumped and don't know what else to say. Of all 11 games I have Majora's Mask is the only one now causing these weird glitches that behave very random.

Are you playing PAL or NTSC version of Majora's Mask? I'm on PAL myself.

[ichee]

NTSC. Regression happened sometime after 2.0 was released, as it doesn't have the issue.

[ghost]

I have no clue of what it is that can cause this.

PR 2.0 and after was broken with Majora's Mask (Europe) for me as you can see here: https://github.com/gonetz/GLideN64/issues/1396

[loganmc10]

The flickering is some sort of depth issue, looks the same as the issue that the Raspberry Pi has with Framebuffer emulation, except it happens all the time for the Raspberry Pi on almost every game.

[ghost]

Interesting, thanks for clearing that up.

[ichee]

For reference, running:

Windows 10 Pro x64 Intel 4790k @ 4.7Ghz NVidia GTX Titan X (Maxwell) Samsung 950 Pro NVMe

[ghost]

We're not to far off: i7 4790K at stock ASUS Nvidia 1060 6GB 16GB RAM Windows 10 x64

[loganmc10]

Yep I reproduced with with mupen64plus + Windows 7 + Nvidia, I'll try compare the GL logs from Public Release 2.0 and the current master and see what difference I can see, might take me a bit though.

[loganmc10]

I'm still doing some testing on this @ichee can you try enabling "Show FPS" or "Show VI/S" and try to reproduce it? I can't reproduce it if those settings are enabled, I just want to confirm though.

[ichee]

It still happens.

[loganmc10]

Huh, I guess I just lucked out that one time, I just re-tested and it still happens with "Show VI/S", I'll have to try and bisect and see which commit broke it

EDIT: Since this may be a multi-day effort when I get the time, I'm just gonna leave my results here: 8f2303046224f0156ac413d95c8da0ebb36085a5 broken here (Feb 23) 5d51242252418da13b68fbc0720a2ce91001e0e0 broken here (Feb 5) 485f2307efbe4ff545cefcc55d312737fdd4608b seems ok here (Dec 28) 4756b1eb745635a20a052174397edfb9735778d0 seems ok here (Jan 29) 4456d43daf3bde78eb008cbb2e21e7914a6e02f3 seems ok here (Feb 2) 210c9ea64af0a2bcdd9a68fb6ee9432b43099594 broken here (Feb 3) This is a likely candidate for the problem commit

[loganmc10]

@gonetz I have bisected this issue and 210c9ea64af0a2bcdd9a68fb6ee9432b43099594 is the problem commit. The issue does not happen with the commit prior to it (9edd5a5f181891f91a31545031eda01fd78a0a11)

[fzurita]

Hmmm, maybe the depth buffer is being cleared and we are not re-attaching the depth buffer on those cases because of this change.

[loganmc10]

Clearing the depth buffer shouldn't result in the need to re-attach it. But ya, it must be related to the depth buffer being destroyed and the program not realizing it needs to reattach a new depth buffer. I'll look at the GL trace in a bit and see what the difference in the GL API calls is.

[gonetz]

Depth buffer is probably attached to previously active buffer, so this optimization is wrong and must be reverted. @loganmc10 thanks for finding the bad commit. I could not reproduce the issue on my PC.

[gonetz]

Reverted 210c9ea.

[ichee]

Fixed.