Perfect Dark does not work properly with Unfiltered (m64p)

[ghost]

I have this weird issue with Perfect Dark with Unfiltered output in Mupen64Plus and I have a hard time figuring out whether I should report it here or at Mupen64Plus because Project64 is unaffected.

My issue is this, with Unfiltered selected and with either Nearest-neighbor or Linear the screen freezes when you press start during the intro to start the game.

Take notice that I said that the screen freezes because the rest of the game is still working/running with sound but all you see is the last image before it froze.

Filtered seems unaffected as it works OK.

@ata4 , @loganmc10
Just thought I would give a heads up on this.

[Jj0YzL5nvJ]

In mupen64plus with Linux (Xubuntu 16.04.3 LTS) and r600g Mesa driver, this happen regardless of the use of Unfiltered or not. #49
In short, on Perfect Dark, none "tvfadeoutstate" function works correctly.

[ghost]

Hmm what a weird issue, it seems that it's indeed is related to #49 then.

I wonder why it "works" on Project64 and not on m64p (Mupen64Plus) and why just Unfiltered (at least on my end) is affected and on your end @Jj0YzL5nvJ it doesn't matter if it's Unfiltered or not.

[loganmc10]

I'm having a hard time reproducing this. I have no issues getting past the logo in either Filtered or Unfiltered mode. Do you guys have an tips on how to reproduce this?

[ghost]

@loganmc10

It's very easy to reproduce:

1. Download m64p here
2. Extract to a new folder
3. Run the emulator and make changes as needed
4. Configure angrylion-rdp-plus to use Unfiltered with either Nearest-neighbor or Linear
5. Restart the emulator and launch perfect dark
6. Somewhere the screen will freeze but you can still here sound and the game is still running

This steps worked for me when I downloaded m64p from 2017-12-25, https://github.com/m64p/mupen64plus-GLideN64/commit/58016b1b33bd334815b8a37d02eca47d9b64af89

[Jj0YzL5nvJ]

Another way to unleash the event is if you choose Accept before a mission. Such also work by choose Decline in a place other than the Carrington Institute.

Example: After completing, failing or aborting a mission and choosing any.
https://youtu.be/MX_QoNfCNKY?t=2m12s
https://youtu.be/MX_QoNfCNKY?t=4m15s

Launching with LIBGL_SHOW_FPS=1 from a Terminal, libGL stops showing activity at such moments.

[ghost]

@loganmc10

Tried with m64p/mupen64plus-GLideN64@7c6c004 this morning and it was still the same result.

I managed to find a copy of m64p from 2017-11-13 before @ata4 had implemented Nearest-neighbor or Linear and Everything worked perfectly with Unfiltered.
However if I used the angrylion-rdp-plus plugin from 2017-11-13 with a newer version of m64p, the image froze.

Take note that this issue is only present with m64p (Mupen64Plus) and not Project64.

I don't know what else to test here, somewhere during the development road something must have happened between m64p and angrylion-rdp-plus and the way it handles Unfiltered because it have worked before.

@Jj0YzL5nvJ
Was linking to Perfect Dark speed-runs intentional?
None of the YouTube videos shows the issue I'm having.

[ghost]

@loganmc10
I managed to get it to work partially, but only on 32-bit and with m64p from 2017-11-13 and angrylion-rdp-plus 32-bit from EmuCr from 2017-12-25

32-bit m64p package from 2018-01-02 https://github.com/m64p/mupen64plus-GLideN64/commit/7c6c004 does not work

[Jj0YzL5nvJ]

Was linking to Perfect Dark speed-runs intentional?
None of the YouTube videos shows the issue I'm having.

Yes, my intention is to show what normally happens in those parts. They are using the real hardware.
https://youtu.be/MX_QoNfCNKY?t=53m2s

Our problems are related, but they are not exactly the same.

In my case, what happens in such parts is that OpenGL stops rendering instead of cleaning what is there on the screen and leaving it black. Instead, it shows a frozen image.
Passing that part, the rendering works again.

As far as I can understand, in your case. Passing that part, the rendering does not recover again.

[ghost]

@Jj0YzL5nvJ
Gotcha!

Now something weirder have happened here, I partially got it working with m64p 2017-11-13 32-bit and angrylion-rdp-plus from 2017-12-25 as I mentioned above (it worked with angrylion-rdp-plus 32-bit from https://github.com/m64p/mupen64plus-GLideN64/commit/7c6c004 also)

Now the screen freezes every time I quit or complete a level and it never recovers after that but again the game is still running and with sound.
So while it partially works with that setup it truly never works properly like it should.

I could have lived with this Frankenstein build setup if it weren't for that small little fact.

Damn, once you go Unfiltered with Linear you never wanna go back and compared to m64p the performance with Project64 sucks now.

What a nice catch 22, working setup with Project64 but bad performance on GoldenEye and Perfect Dark.
Then a partial/non-working setup with m64p but supreme performance on GoldenEye and Perfect Dark.

[ghost]

Scratch what I said about bad performance on Project64, it was Azimer's newest WIP 10 Audio plugin that gave me crappy performance.
Using WIP 7 or WIP9 instead of WIP 10 cured all my performance problems.

However my issue with m64p still stands when it comes to using Unfiltered in angrylion-rdp-plus on newer builds of m64p.

[loganmc10]

@Sigmavirus can you try the latest build on the m64p website? I've updated to include the latest changes intended to fix #49

[ghost]

@loganmc10
No my issue is not fixed.

This is what I'm getting most of my times playing, frozen screens but the gameplay and sound is still working.

I don't have these problems with Project64, everything is working as intended there and I only have these problems with m64p (Mupen64Plus) (Unfiltered)

[loganmc10]

Ok I'll look into it. Mupen64plus and Project64 handle these Rare games differently (the "DP freeze" bit). This is why Rare games like dk64 and Blast corps won't work with angrylion + recent versions of PJ64 for instance.

I'm inclined to "blame" this plugin since it works in filtered mode, but I'll try and track down a solution

[ghost]

Thanks mate, I appreciate it!

[ata4]

I think I found the issue: After hitting enter in the intro and when the menu is loaded, VI_V_CURRENT_LINE is still set to 1, even though the serrate bit in VI_CONTROL has already been set to 0 at this point.

In unfiltered mode, AL+ uses VI_V_CURRENT_LINE to skip every other frame in interlaced mode, since they may cause wobbling artifacts.

It looks like Project64 sets both register bits to 0 after interlacing has been disabled, but I can't say if that's the hardware behavior. But to me, it seems that it's indeed a minor issue in m64p.

For now, I can fix this issue by also checking for the serrate bit in vi_process_start_fast.

[loganmc10]

Yeah I'm not sure about PJ64, but mupen64plus only updates the value of VI_V_CURRENT_LINE right before the game tries to read it, so if a plugin tried to read the value, it's not surprising to me that it could get an old/bad value

[ata4]

As far as I can tell, PJ64 uses a timer that periodically sets CURRENT_LINE and ORs it with the serrate bit (source). m64p, on the other hand, XORs CURRENT_LINE with the serrate bit (source). So CURRENT_LINE just stops changing when the serrate bit is off, regardless of its current state.

Again, I don't know which approach is correct, but it's still a difference that may also have an impact on VI emulation elsewhere.

[loganmc10]

@Sigmavirus I've updated m64p.github.io, everything looks normal to me now, perhaps you can take a look when you get a chance?

[ghost]

@loganmc10 , @ata4 Thanks guys!
I'll have to take a look at this once I got a chance later on but I have no doubts whatsoever on your work behind this.

@Jj0YzL5nvJ
Does it work for you now?

[Jj0YzL5nvJ]

Yeah, the initial bug is gone... but I currently see another new glitches intruded by the commits on Jan 5.
https://imgur.com/a/OA1Vx

Now they last one single frame and appear only on Unfiltered mode if you enter to the "secret" Controller Pak menu (leave Start button pressed at "power on").
After leaving such menu, you start to see glitches in the following scenes if you skip...

[Jj0YzL5nvJ]

I can't reproduce the later glitch mentioned above by me. Tested in 5c8b788.