GLideN64 Regression

[nlburgin]

There's a strange glitch happening in GLideN64 on Mario Golf in Bizhawk 2.3.1 and 2.3.2 (as well as latest interim build)

It looks like this.

The texture is blacked out on the fairway, the tee box, and the green.

However, on 2.3.0, it looks like this:

which is clearly a lot more normal. The sync settings were exactly the same between these two pictures. In fact, this result can also be achieved on 2.3.2 if you simply swap out its copy of mupen64plus-video-GLideN64.dll with the older one that came with 2.3.0.

I initially assumed this was an upstream regression, but when I tested the latest upstream GLideN64 with the latest upstream Mupen64Plus, the glitch did not occur. So it seems like it has to be a Bizhawk issue, then.

Interestingly, the upstream DLL did not seem to be compatible with BizHawk. As I mentioned it worked fine with regular M64+, but when I tried it with Bizhawk, it did this:

Which is definitely worse. Although from what little I can make out through the complete scramblage, at least the texture glitch appears to be absent 😝

Incidentally I was on IRC (as "Question48") and someone suggested removing all the Mario Golf related lines from gamedb_n64.txt, but that had no effect. So, it seems like the answer isn't in there.

[zeromus]

bizhawk is not using the latest upstream gliden64, so it's not proof of anything.
the only interesting proof of anything would be demonstrating a gilden64 version that had that bug on mupen. ideally, the version we last merged.

additionally it would help if someone merged the latest gliden64 code, since you did test that version on mupen. it's possible it will work again in bizhawk

[nlburgin]

ideally, the version we last merged.

Would that be this?

Unfortunately, that commit is over six months old, so its appveyor artifacts got automatically deleted. I'm not confident trying to build it from source myself ☹️

[zeromus]

no, that's the master branch. the last version we merged is from TASVideos/GLideN64:Branch_bizhawk

edit: link --yoshi

[nlburgin]

Oh. Well in that case it looks like the latest merge was Public Release 4.0, which is what I tested, and what I meant when I mentioned the latest upstream Gliden. I wasn't using an interim dev build of gliden, just the most recent release.

So it looks like the version that was merged last was the one I tested after all.

[nlburgin]

It might be worth noting that I could only find a 32-bit build of upstream M64+ for Windows, so when I tested upstream Gliden with it I also used the 32-bit version library.

Whereas I'm pretty sure everything to do with Bizhawk was 64-bit.

I wouldn't think that would be related to anything like this, but IDK.

[nlburgin]

It also might be worth mentioning that in all cases I was using OpenGL 3.3. core profile.

I think gliden is designed do things somewhat differently internally depending on what OpenGL version it detects. So I'm not 100% sure if the bug would be reproducible in an OpenGL 4.x environment due to different code paths possibly being involved.

IDRK, it just seemed worth mentioning.

[vadosnaprimer]

We've seen bugs that were only caused by the way we forked gliden, it's probably one of those.

[vadosnaprimer]

Test latest master https://ci.appveyor.com/project/zeromus/bizhawk-udexo/build/artifacts
Might not help at all, but there's not a lot we can do with our 7 year old core.

[nlburgin]

I couldn't even get the dev build to run (see #1886)

However, I can confirm that my workaround of simply copy-pasting the mupen64plus-video-GLideN64.dll from 2.3.0 to the newer version still works in the latest stable release 2.4.0

[vadosnaprimer]

Main issue should be #1718