Bug with Parallel RDP using HSM shaders in Mupen and Parallel cores

Hey everyone,

When does the bug happen?

  1. This bug happens only when using Parallel RDP (NOT GlideN64) in both mupen and Parallel cores.
  2. It happens when using HSM reflection shaders which also add bezels to the screen.
  3. It also happens only in certain games (e.G. Donkey Kong 64 and Banjo Kazooie)

What is the bug? Whenever there is a screen transition from one area to another and the screen turns black, the shader bezel briefly disappears. It seems like the transition overlaps the bezel.

I can’t seem to be able to fix it. It does not happen when using GlideN64 RDP.

2 Likes

Which version of the shader are you using, what version of RA?

There is particular magic being used to accommodate the N64 cores, it is certainly possible it won’t work for every game and/or RDP plugin.

1 Like

We think this may be related to the core outputting a 0 sized image buffer when it transitions.

Can you try turning off the Graphics Caching and see what result you get?

1 Like

Wow, didn’t think YOU’d reply. I’m actually using your shader bezels. They are amazing. Consider me a fan, haha.

I’ve redownloaded your complete set 3 days ago. Retroarch is at 1.9.14 (latest). The cores are all updated as well.

I haven’t tested many games yet. The bug doesn’t occur in Mario Kart and Banjo Tooie as far as I can tell. it does happen in DK64 OFTEN and sometimes in Banjo Kazooie, too.

As I said, I tried mupen and parallel with parallel RDP and RSP. You should be able to reproduce this easily.

You, too?! All the famous people replying to me today =).

Seriously, I admire your work. I’m enjoying it a lot.

I’ll try your suggestion and get back to you asap.

1 Like

So just that we’re clear, you referred to the caching options in the shader parameters, right? I changed both options under “graphics change” to 0 and applied the changes. Sadly it didn’t work. =/

2 Likes

@HyperspaceMadness

I can verify the bug. The whole screen turns black for just a second. With caching on or off.

I turned on debug and it does not have anything to do with res changes.

1 Like

So my guess of what is happening here is (sort of technical):

  • When graphics modes are changing on the core the core outputs a zero sized graphics buffer.
  • The shader pass which does a bunch of calculations and stores the results to be used later in the chain is forced to 0 as well
  • When this is forced to 0 we can’t get any information from it, so the whole shader chain doesn’t have the info it needs, so it can’t run properly, then this is what gives you the black screen.

So with the way things are if that is the case then there’s nothing that we can do to make it better.

To make it better I think if we had an Original pass scaling mode we could ensure that the caching pass had an explicit resolution (so it would not go to 0) then the next pass could have the correct original resolution.

2 Likes

Yeah it’s wierd. With debug on I noticed it once when res changed 640x480 to 640x420 but then again with no res change.

I’m not really surprised since the Parellel RDP does things with the frame buffer no other renderer does.

2 Likes

Yeah, I think we would also never be able to see the resolution info show it as 0 if that was the case because as soon as it goes to 0 the whole shader chain “breaks” and can’t do anything.

1 Like

Can you put in a sanity check? So if it gets a crazy value (like 0) it just snaps to a sane range?

2 Likes

yeah, that’s a bit what I was thinking. If I can catch that I could at least just reuse the image cached from the viewport from the last frame while the core is outputting something wacky.

3 Likes

Thank you all for helping. So it seems that there is no quick fix. For now I guess I’ll make game specific configs for the hopefully few games that have this issue. I’ll have them launch with gliden64 instead of parallel. This is however not an ideal solution so I’m hoping for a real fix some time in the future.

4 Likes