Compatibility issues with multiple games

[daninthemix]

Not sure which of these are known, written down elsewhere, etc. By and large this core achieves a rather pleasing 'plug and play' ease of use that other N64 emulators, which require you to select your plugins and cross your fingers, don't.

However, these games have issues:

Vigilante 8 - random black boxes

Vigilante 8: 2nd Offense - crashes

The World is Not Enough - polygon lines visible everywhere

Duke Nukem: Zero Hour - crashes in the helicopter cutscenes moments after beginning the game

Extreme-G - polygon lines visible on some tracks

Fighting Force 64 - renders upside-down!

Goemon's Great Adventure - polygon lines

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/45071776-compatibility-issues-with-multiple-games?utm_campaign=plugin&utm_content=tracker%2F53677400&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F53677400&utm_medium=issues&utm_source=github).

[loganmc10]

Can you post your core options? Specifically I'm curious if your RSP mode is set to HLE or LLE

[daninthemix]

RSP is set to HLE, though I believe I did try LLE for the two games that crash. RSP mode wouldn't affect the various games with polygon lines would it?

[loganmc10]

Polygon lines like that are common in LLE mode for GLideN64. LLE mode doesn't work perfectly in GLideN64, HLE mode is usually better. LLE mode is just required for a few games, like Rogue Squadron

[daninthemix]

Common in LLE mode? But I always run in HLE.

[loganmc10]

Then it must be some other issue

[daninthemix]

Found another one - Cruis'n Exotica crashes immediately after the developer logo.

[loganmc10]

I know that the Fighting Force issue has been fixed in a more recent version of GLideN64.

I could reproduce the crashes in Duke Nukem: Zero Hour and Cruis'n Exotica, however they both work in upstream mupen64plus, so that is a problem unique to the libretro port.

I could reproduce the Vigilante 8: 2nd Offense crash in upstream mupen64plus+GLideN64 and I filed an issue here: https://github.com/gonetz/GLideN64/issues/1479

It seems that other people have had the black box in Vigilante 8 issue in GLideN64: https://github.com/gonetz/GLideN64/issues/1023#issuecomment-288097615 https://github.com/gonetz/GLideN64/issues/1414#issuecomment-285944044

I could reproduce the issue in libretro, but not upstream mupen64plus+GLideN64, so it's possible that it was fixed in a more recent build of GLideN64

[daninthemix]

Cool, so I guess we just need a new build of the libretro port with the latest GlideN64 version?

Thanks for confirming.

[daninthemix]

Hmm, according to these guys this core no longer has a developer. Makes this issues list seem a bit moot :o(

[inactive123]

If I were to update it, it would probably end up like Parallel N64, and we already have a hard fork. So it might be best for somebody who cares about staying close to upstream to take care of this repo instead. It was in good hands before.

Things between us (more specifically me) and loganmc10 went bad over one tiny little thing that honestly shouldn't have even been such a huge issue. As far as I'm concerned I'd happily leave this core up to loganmc10 as I am really not the right guy to be continuing this work. It's up to him, it has been mostly his baby, I have a different approach I pursue with Parallel N64 and I don't really feel comfortable to pick up the pieces from here. He can have full repo rights and everything, If he decides to give it a chance, we could try to finally push libretro upstream this time through some joint cooperation between me, loganmc10 and the mupen64plus team. I just hope that next time around that we can work out any disagreements before they come to a head like that again. And I also hope this time that the mupen64plus team wants to seriously look at some of the things I have brought up in the past like find ways so we can remove libco from the equation, as in, reorder the control flow/runloop so that we no longer need to run mupen64plus in a separate thread, etc.

I never wanted things to come to an abrupt halt at any rate, I guess loganmc10 felt he no longer had any code ownership over it and I can understand how it might have felt abrupt. That was not my intention but I guess it came off like that. For that I apologize.

[inactive123]

It would be yet another huge maintenance chore I would have to add to my list. At a certain point, there has to be more reinforcements because I can't take on even more than 80+ of these codebases all on my shoulders. It's simply an impossibility. And I don't see why you and me can't resume our relationship to where it was before.

Doesn't mean you have to take on maintenance duties for this or anything, I'm not your boss, I'm not ordering anybody around here, it's all volunteer based, but we don't need to have this kind of sudden breakup either especially over such a fairly insignificant and trivial issue in the larger scheme of things. I think we should just forget about what happened in the past and try finding some common ground where we can and work from there again. Holding onto grudges serves nobody.

[daninthemix]

Even bi-annual updates would be better than letting this core die. It is, to my knowledge, the easiest way to just start playing N64 games today without getting bogged down in plugins and endless configuration options.

[inactive123]

I can give it a shot and add yet another core to my maintenance/update list, but I'd appreciate if you could stick around in #retroarch then so I could ask you technical questions while I go about trying to get gliden64 to work with the latest code and so on.

If you are down with this, we can do that then.

[inactive123]

Thank you.