N64 crashes after 10 min
-
I can manage to get through the 10 minute glitch fairly easily with a lower SDRAM frequency than a higher one.
If you set SDRAM_freq to 550 and not something insanely high the Rpi 3 can sort itself out pretty well. If you set it to 600 or above then screen will get worse and worse and will it freezes.
I am currently matching my GPU and SDRAM overclock and it seems to help get thought the 15 minute glitch...
Here is a reddit post I found that seems to be the same issue.
-
@bobberella overclock isn't the root issue here. Read my earlier posting, I tried a stock image and the emulator is still glitching out and freezing. I'm wondering if it is somehow related to the framebuffer issue that the fps counter was supposed to solve.
-
I did a fresh load from a brand new SD card with no overclock settings and updated from source, I am still getting the same 10-20 min crash time. I have even downloaded ROMs from different locations just inc case my ROM was corrupt, this does not seem to be the case. I have the EXACT same issues with varying levels of overclock (which I am not using any more as I continue to test issues per admin instruction).
It seems to be software related, but I am not sure what information the developers need to further look into this issue.
At this time I am using GLES when possible as it performs great (once you tweak the audio setting to allow save states). If the game does not run on GLES, RICE, or LR-, then I just cant play it because every game I have tested on GLIDE crashes at the 10-20 min mark. I use the spreadsheet on the n64 emulation page as a starting point to guide which emulator I run, but I have found that list is not up to date and its better to just experiment on my own. This is very frustrating as playing the same game up to 4 different times for 20 min to test for the "GLIDE glitch" as i have come to call it is painstakingly tedious.
SUMMARY:
I have found out that GLIDE crashes between 12-15 min on almost every game I have tried (about 12 games total). The problem happens only once at that time interval (does NOT repeat every 12-15 min after the first one). If i let the game sit at an idle point such as a load screen, save screen, or face my character into a wall or something, the game will blur and stutter for about 30-45 seconds then recovers and runs great, If I move at all or force the game to process movement of almost any kind it crashes. This is impossible on games like Aerofighters Assault where you are in constant motion, these types of games crash every time as a result. The indicator if the game has crashed or not is tied to audio output. So long as sound is playing normally when the problem starts, it is in the "blur" phase and recovers within 30-45 seconds every time. If you try to move or jump or cycle through a menu during the "blur", the sound will cut out completely or hang on a note and sustain until you hard reset.I hope this helps, I am happy to provide any additional information if it assists in solving this issue.
-
@endersenigma I see you have spent as much time trying to figure this out as I have. I've noticed all the strange nuances with this glitch as well. I suspect this is an issue with mupen64-glide on the pi itself. If this issue was universal to all devices I'm sure the mupen64 devs would already know about it. At this point I just need to figure out who to report it to.
-
@quicksilver
I did a search looking for the contact information of the GLIDE devs, no luck. Maybe one of the admins/mods can point us in the right direction.If you hold your Pi out the window while driving 40+ mph, the performance is improved significantly.
True story.
-
I have known that overclocking isnt the root of the issue for a long time now... What im more interested in is setting up my retropies so that they will overcome the glitch and not freeze up given the chance.
I have run about 50 tests. You can start the game, set the timer for 14 minutes and let the game run without hitting pause and then see how your new settings react to the glitch.
I cant fix the glitch. I have no idea who can but I dont care either. All I want is to play so N64 in peace.
If you know of any other componants I can tweek that will allow the Rpi 3 to recover better from a glitch like this I would be interested in hearing it. :)
I am glad you guys are gonna try and get it fixed and thats awesome because this glitch has been around for at least a year now.
-
@endersenigma https://github.com/mupen64plus/mupen64plus-core
This is most likely the place to report an issue. I too would like a mod/admins opinion though.
-
I found that Dolphine was crashing at exactly the 15 minute mark and they found:
"Oh, looks like I found the solution.
I changed DSP HLE to LLE, and I changed the driver from XAudio2 to Direct Sound"
So what does that mean?
-
@quicksilver said in N64 crashes after 10 min:
@endersenigma https://github.com/mupen64plus/mupen64plus-core
This is most likely the place to report an issue. I too would like a mod/admins opinion though.
if this isn't happening in other graphics cores then it's not a mupen64plus issue, it's a gliden64 issue. please report it here: https://github.com/gonetz/GLideN64/issues, but lets hold fire on that for a while until we have more details
i think a video of the issue would be ideal, and even better would be a stack trace, but that's kinda difficult to explain if you've not done it before. tagging @gizmo98 if you have a moment :)
-
@dankcushions I will try to get a video of it, it's hard though because sometimes it glitches and freezes faster than I can get my camera ready (I don't have capture equipment). It's easily reproduced though.
-
@quicksilver
I might be able to capture some video this weekend, will update as able. -
I think i fixed the glitch by setting "show VI/s counter" to True.
Its in the advanced settings for mupen64 near the "show FPS"
I figured if show fps fixed the last thing then lets try the rest of them.
Im gonna test it a few more times... posting later.
-
@bobberella See https://retropie.org.uk/forum/topic/11279/how-to-turn-off-fps-frame-counter-in-mupen64plus-gliden64, seems like known problem.
-
@mitu Except that the frame counter is on and we are still encountering this issue. So either its not working as intended or this is something else.
-
It only worked twice so now im on to messing with different settings.
-
Seems like if you turn on percentage and vi/s...
The glitches are not so bad and you can make it through them without freezing. -
@bobberella Its probably just incidental. A lot of times I can get through the glitch by not moving. If I keep moving and looking around it makes it worse and usually crashes. At this point I think its out of our hands, Im not sure its something we can fix. I applaud your enthusiasm for digging through configs and testing things though!
-
@psyke83 has reproduced the issue. We need to debug it though and it could take some time.
To help us help you - please make sure you read the sticky topics before posting - https://retropie.org.uk/forum/topic/3/read-this-first
-
Awesome.
There seems to be no settings in "advanced mupen64 settings" that do anything besides break the emulator or do unnoticible changes.
I think adding FPS, percentage, and vi/s made it more stable but I have no idea.
Hopefully the fix is soon... :)
The people of retropie thank you.
-
@buzz thanks for the reply buzz. Do you know if a issue was opened for it on the gliden64 GitHub?
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.