Update mupen64plus to latest upstream version #4117
Draft
+6,278
−383,055
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
Contributor
|
I feel I should let @Wyst3r know about this. |
Collaborator
Author
|
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). |
Collaborator
Author
|
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
Member
|
Pre-emptive mode also improved framerates in managed and maybe wbox, so ^ I set it globally. Nice find!
|
Collaborator
Author
Could you post the full stdout/stderr output? There should be some logging about plugins in the beginning. |
Member
GLideN64angrylion-plus |
Collaborator
Author
|
Hmm, those logs look proper, nothing out of the ordinary there. Note that for angrylion-plus, the |
Member
|
Oh, that fixes it, now I can get in-game and it's almost playable (mostly stable 50 fps). |
Member
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. |
Collaborator
Author
|
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. |
Collaborator
Author
|
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). |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
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. |
Collaborator
Author
|
@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. |
Collaborator
Author
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. |
in an attempt to get more control over what the core/plugin does
I don't like that this adds dependencies and increases the plugin size substantially just for this goodizer feature but it's either that or no hires texture support :/
apparently the old one is missing symbols that the new dlls need
why is this how things are
|
What's the status on Lua support with this? (for Multiworld Randos, etc.) |
Collaborator
Author
That sounds like it requires a specific patched rom that you aren't using, not related to the core. Does that work with ares? |
|
This is the correct rando ROM though, hence the version number in the corner that matches the one in the Lua output. Exact same ROM/script combo works on the Ares core (albeit running super slow because Ares), and it also works on Mupen with the current release build of BizHawk (Windows release ran thru Wine). My assumption was that Lua support just wasn't finished yet on this branch, which is fine, but I wanted to ask and make sure. (The reported "vanilla ROM" error is because (i think, probably wrong) it's looking for a pointer that only exists in the patched rando ROM, and can't find it due to not being able to read memory at all.) |
useful when the underlying data is actually stored in opposite endianness from what the memory domain "should be". Could probably replace MemoryDomainIntPtrSwap16/MemoryDomainIntPtrSwap16Monitor with this while we're at it.
Collaborator
Author
|
@JustNeoXYZ the issue was that the memory domain implementation declared big endian byte order while the underlying data was stored in little endian. I've fixed the code to support this now, so all memory reads and writes should now return correct values. This should allow the lua script to work properly. |
Tested and it works perfectly! Thank you so much!
|
|
...never mind then, apparently it can't read ROM domains for N64 |
might need to add more that were previously present too, will have to see what's relevant
And that fixes it! Thank you so much (again)!
|
|
This only launches games in Ares for me still. That being said, BizHawk won't launch at all on my Steam Deck unless I run it through a distrobox, which may have something to do with this. Here's the guide I followed, I just changed the username to my own: https://gist.github.com/SpenserHaddad/417a772aea5be99d563fe73295bb62fb |
Collaborator
Author
|
@ahhh-reptar the linux binaries are currently compiled by me on an ubuntu 24.04 system with GLIBC 2.39, so if your glibc version is older than that then the binaries may fail to load. You can set the |
|
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
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 (mupen) debugger has some overhead and should be toggleableI'll consider this unfeasible as lots of functionality depends on the debugger now, overhead is probably negligiblesome games have graphical issues with GLideN64, this appears to be a plugin issue that can't be resolved easilyresolved upstreamre-investigate linux binaries after 25203c5program freeze has been resolved via workaround (see [🐧] BizInvoker does not cause gc mode switch without compatibility argument #4553), GLideN64 crash resolved via compiler arguments, cxd4 crash has been resolved upstreamThe diff should be relatively clean, the commit history isn't. Best to look at the full diff instead of individual commits.