[WIP] Update mupen64plus to latest upstream version #4117
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I feel I should let @Wyst3r know about this. |
|
The latest commit adds linux binaries which "work", as in everything loads, but I've experienced freezing after 1-100 frames. It's not a crash, just an unresponsiveness forcing me to close the program. I have no idea how to debug this except by adding dozens of console.writelines and trying to narrow down the place it's getting stuck at. |
|
Just for the sake of re-documenting it here and not like somewhere in the Discord (and it is the first todo point). better gln64 is a high recommended from Mupen64-rr-lua mainly for it having low hardware requirements and better to TAS with. The only caveat against it from what I can tell is that it's HLE and not LLE and some glitches with certain titles (which some of the plugins already in Hawk has those issues). So in other words it would be a suitable replacement to Rice (so lowest of the low). And whilst porting it, it's probably beneficial to disable the texture settings (technically you can hide everything, and make it just the plugin, but some people might benefit from disabling fog). |
|
Linux can be fixed to work with all currently checked in binaries by applying the following diff: diff --git a/Assets/EmuHawkMono.sh b/Assets/EmuHawkMono.sh
index 7ca69f6ea..e695450ac 100755
--- a/Assets/EmuHawkMono.sh
+++ b/Assets/EmuHawkMono.sh
@@ -18,6 +18,7 @@ fi
export LD_LIBRARY_PATH="$PWD/dll:$PWD:$libpath"
export MONO_CRASH_NOFILE=1
export MONO_WINFORMS_XIM_STYLE=disabled # see https://bugzilla.xamarin.com/show_bug.cgi?id=28047#c9
+export MONO_THREADS_SUSPEND=preemptive
if [ "$1" = "--mono-no-redirect" ]; then
# printf "(passing --mono-no-redirect is no longer necessary)\n" #TODO uncomment later
shiftLooking at the documentation, it looks like this might be an actual mono bug (maybe mono/mono#14084 ?). Either |
YoshiRulz
added a commit
that referenced
this pull request
Jan 22, 2025
|
Pre-emptive mode also improved framerates in managed and maybe wbox, so ^ I set it globally. Nice find!
|
Could you post the full stdout/stderr output? There should be some logging about plugins in the beginning. |
GLideN64angrylion-plus |
|
Hmm, those logs look proper, nothing out of the ordinary there. Note that for angrylion-plus, the |
|
Oh, that fixes it, now I can get in-game and it's almost playable (mostly stable 50 fps). |
Looking at how that works, it does somewhat make sense. You have a pure native thread being created (in this case the "render thread"), without the runtime having any knowledge of them (since they weren't made with managed APIs). As such, it doesn't really know of such a thread needing to be suspended for GC purposes. This is all fine, as long as that thread remains in unmanaged land, and thus doesn't touch managed state. Once it tries to come back to managed land (via a callback), things go very poorly. |
|
Hm, I did a bit of testing with Donkey Kong 64 and it appears to be a GLideN64 plugin issue rather than a fault of anything in BizHawk, so it's unlikely I'll be able to resolve this. I also get broken video output in the old mupen core with gliden64 (in bizhawk), so it's not really a new regression. |
|
This is more or less ready from my side. I want to pull a couple more submodules once they're ready and of course this needs to be rebased, but aside from that the diff should be about final. Mainly needs more testing now, especially on linux and the parallel video plugin (vulkan). |
|
I'm looking to test this branch with some N64 games on my machine running Arch Linux but I'm having trouble compiling. I have the .NET SDK installed and ran |
|
Your copy of the .NET SDK is incomplete. I'd be surprised if Arch doesn't have a proper package, but if that is the case, you can use Nix. (Or we could fix the merge conflicts here and have CI build it.) |
|
Thanks! It turns out the only missing SDK was the WindowsDesktop, so I simply copied and pasted the SDK from the official download into the install folder. Not a permanent solution, but good enough for testing this. On the testing side, I'm currently stuck getting much going on all 3 video plugins. Video: GLideN64 | RSP: hleVideo: paraLLel | RSP: paraLLelVideo: angrylion-plus | RSP: cxd4All tested with Super Mario 64, Banjo-Tooie, and Super Smash Bros. Only Super Smash Bros. loaded at all and only on angrylion-plus/cxd4 when launching BizHawk with my discrete GPU as the preferred graphics device. It seems like any scene transition breaks it. Ex. Super Smash Bros. doesn't get to the main menu if I cancel the N64 startup logo early, but if I let the N64 startup logo play in full it'll never even get to the title screen. My DE is KDE Plasma 6.3.2. |
|
@kimimaru4000 I've rebased, could you try again now? |
|
What a world of difference! All the games are working great now and run at full speed on my machine with different combinations of settings 👍 Awesome work! |
|
If it's not already, I would suggest allowing an option, or just having it always do it, to load the shaders before the game starts. I've been testing this build for the last few hours with OOTMM and noticed a bit of stuttering whenever I load into new areas, something that earlier versions of Bizhawk and PJ64 don't get. Earlier versions of Bizhawk I noticed have a "Texture Save Cache" option with GlideN64 which seems to be what is affecting it on those since I disabled it and started getting the stuttering. PJ64 has an option to store the compiled shaders which disabling that also yielded the stuttering I would get on this newest Bizhawk build. |
Hm, while I don't currently expose shader cache or texture cache options, both of these should be enabled by default. I'm not sure what could be going wrong there. |
The culprit is most likely |
Ah okay I forgot to mention that Banjo-Tooie actually wasn't working well with GLideN64. There's a flickering duped render of the whole game on the bottom left. Also, no matter the video backend I can't get the game to recognize the controller whereas the other games are working fine. BanjoTooieBizHawkLinux.mp4But overall much more progress after the rebase. |
This is somewhat expected. That's one of the anti-piracy measures in BT. Someone needs to make sure the save type is set to the correct 2Kb EEPROM for the game. |
45 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work in progress update of the mupen64plus core to the latest version. This would ideally improve compatibility and increase accuracy and be a real-time playable alternative to the existing ares64 core.
There's a couple of known TODOs that need to be resolved:
those are currently all default because no choices existdoneintegrate mupen core and plugin sources and build in the bizhawk repo; I currently build from a fork that is not checked in to bizhawk (https://github.com/Morilli/mupen64plus-core/tree/bizhawk)<-- done, added basic build script. There's still some issues while waiting for upstream commits, but assuming we fork all projects anyway that shouldn't be a blockerIDebuggablefunctionality is missing, mainly because registers aren't implemented. Registers not being implemented also affectsITraceableimpl (why is that required but only exposed inIDebuggable... whatever)The diff should be relatively clean, the commit history isn't. Best to look at the full diff instead of individual commits.