N64 crashes after 10 min
-
so I was messing around with the settings in the mupen64plus.sh file and by setting frame buffer emulation to false it seems to have taken care of the crashing issue. I just tested two different games for over 30 minutes and I did not get a crash. With frame buffer emulation turned off some games don't render certain things properly but it would be great to know if this is where the problem lies. Anyone else able to test this and let me know if they get the same result?
-
-
@quicksilver said in N64 crashes after 10 min:
so I was messing around with the settings in the mupen64plus.sh file and by setting frame buffer emulation to false it seems to have taken care of the crashing issue. I just tested two different games for over 30 minutes and I did not get a crash. With frame buffer emulation turned off some games don't render certain things properly but it would be great to know if this is where the problem lies. Anyone else able to test this and let me know if they get the same result?
interesting! this sounds like it's the same issue as this: https://www.reddit.com/r/RetroPie/comments/4yyyle/glide64_crashing_after_a_few_minutes_of_emulation/
it sounds like it's the old texture corruption issue: https://github.com/gonetz/GLideN64/issues/1084
i've had a thought and updated the issue!
-
Btw I never got this freeze issue. I even finished Wave Race 64 several times without problem and even then, I didn't have the problem here is described. Besides with Yoshis Story, but it does not happen after sepcific time, but after a specific point of game.
Does this happen only with specific configuration of the emulator? I am a bit confused here. Is it glide only?
-
@thelostsoul gliden64 only. waverace runs in gles2n64: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/mupen64plus/mupen64plus.sh#L357
-
@dankcushions I have found the rice plugin to be better for performance with waverace.
-
@dankcushions so the reddit issue sounds the same. But the issue on the GitHub doesn't sound quite the same. They stated the textures become transparent but the game still runs. Maybe the fps counter only partially fixed the issue.
-
@quicksilver this issue seems to involve a crash/hang - https://github.com/gonetz/GLideN64/issues/1665
does this sound similar? in theory there's a fix in retropie to resolve this, but maybe it doesn't work anymore.
i think if we can clarify the issue that best reflects this problem, we could raise a bounty. we may need to create a new issue.
-
@dankcushions https://github.com/RetroPie/RetroPie-Setup/issues/2207
Visually the current issue looks very much like the pictures from the above issue (is this the same issue you linked?). No mention of time is noted though in the previous issues, whereas the current bug only shows up about 10-20 minutes into gameplay. Hard to know for sure if it's the same problem or just related.
Something else that is odd when frame buffer emulation is disabled is the fps counter in glide suddenly jumps up to 50-60fps while playing GoldenEye whereas with fbe enabled I'm lucky for it to reach 30fps during gameplay. Game doesn't feel any faster though so I'm wondering if it's not reporting the fps properly when fbe is disabled.
-
@dankcushions said in N64 crashes after 10 min:
i think if we can clarify the issue that best reflects this problem, we could raise a bounty. we may need to create a new issue.
I think this is a great idea and I would be more than willing to contribute to a bounty.
-
Seems like this puppy is dead
-
@bobberella What do you mean?
-
@thelostsoul He dug up a dead puppy and concluded it was dead.
-
Sorry to necro the thread but since it's relevant to this issue felt it was best to keep this conversation in one place. So I recently updated mupen64plus from source and it seems as though it may have solved the gliden64 crashing issue. I have run several games using mupen64plus-gliden64 for over an hour each with no crashing (framebuffer emulation was on while testing). Any chance anyone else is willing to update mupen64plus from source and test this? Just want to confirm if it's a recent commit that may have fixed it or something else I may have inadvertently done.
@dankcushions not sure if this issue was still on your radar but thought you might find it interesting.
-
@quicksilver neat! i do follow the gliden64 project but i'm not sure what change might have fixed that. i never really investigated it myself
-
@dankcushions yea I would be curious to know which commit may have fixed it otherwise its possible that a future change may revert it by accident. Problem is it could be anything over the last 8 months or so (probably the last time I updated mupen64plus). Coupled with the fact that it takes like 20 mins for the bug to show itself Im not sure where to start. Should we update the bug report on github?
-
sure, you can update it!
-
@dankcushions Awesome, thanks for the input! I will do that now!
-
Thanks for posting this up as I would never have known otherwise. I've updated mine from source this morning and after a brief play it does indeed seem to be fixed. However I'll have a more extensive session tonight and see how it goes.
I've said it before and I'll say it again - it's a minor miracle that N64 runs at all on the Pi. The fact that it runs as well as it does is really absolutely amazing and I cannot thank the developers enough. Superb work imho.
-
Quick questions about updating from source here:
At what point do changes made to the source code pass into the binary update? Does it all come through on the next system update? Is there a way for a user to check when the updates made to source have been passed to the binary package? Many thanks.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.