N64 crashes after 10 min

quicksilver

@simonster I've had times where the glitch either didn't happen, or I suspect sometimes it comes and goes so quickly and doesn't always cause a crash. Part of the reason why I thought my case was causing the glitch previously.

simonster

@quicksilver oh well! Thought I was on to something for a moment. I am trying to run top in SSH at the same time to monitor memory/cpu usage and see if it is memory related.

simonster

I forced Super Mario 64 to run through Glide-HighRes and have been running top -d 0.1 on ssh, whilst playing the game (the fastest it seems to go is around 25-27 fps), the memory utilisation (according to top) seems to be stable at 12.2% and increased to 12.3% after 15 minutes on my Pi3B+ and CPU load averages out at 50% (I assume that it can't access more than 50% due to the way it is coded).

I did get the glitch after about 20 minutes whilst playing but the system recovered (despite me trying to crash it deliberately), no noticeable increase in cpu load or memory usage was seen in top. Also the memory usage didn't go down after the glitch.

I know it probably isn't the best tool diagnostically, but the system didn't think it was using more memory or cpu than usual.

dankcushions

@simonster said in N64 crashes after 10 min:

CPU load averages out at 50% (I assume that it can't access more than 50% due to the way it is coded).

no that's just the amount it needs :) try telling that to all the people who overclock their pi3 cpus, though...

BuZz

I can reproduce the freeze on Jessie and older code. It's probably a gpu memory leak issue. Unsure though - but it can't hold up the release sorry. Hopefully we can debug it via valgrind or something.

quicksilver

@buzz no worries. Jessie and older, does that imply its not on issue on stretch?

BuZz

@quicksilver I meant Jessie and older Gliden64. The bug is not limited to Stretch basically. Will need to debug more in the future.

Bobberella

"that's just the amount it needs :) try telling that to all the people who overclock their pi3 cpus, though..."

Hmm.... so overclocking the cpu doesnt do anything?

I thought it was for stability reasons.

jonnykesh

@bobberella overclocking introduces instability. If you actually monitor the CPU cores whilst running emulators you can see that none of them are actually that taxing. You get the odd spike that a mild overclock may smooth out but nothing really that noticeable.

quicksilver

@bobberella Stability and performance are two different things. Overclocking the GPU will make N64 games run a little bit better because you will be able to get better FPS. Hence your performance is increased. Overclocking the CPU will do nothing for you (or nearly nothing) when it comes to N64 emulation on the Pi. However, increasing the clock speeds of the CPU and GPU beyond their default settings can make your system unstable if you push them beyond their capabilities. Making something run faster than intended will never make it more stable than it was originally.

Bobberella

So how often does retropie get updated? If the glitch wont be fixed with this release then.... when?

I will have to keep an extra retropie around that has all the games that run glideN64 so I can limit the corruption to a single 16gig SD card. Lol

dankcushions

@bobberella you can see in this thread its being investigated. it will be ready when it's ready.

Bobberella

didnt mean to be an arse.

Thanks for everyrhing you guys do.

Bobberella

I have a copy of retropie v4.2 with glideN64 version 7 with no glitch.

So I updated glide64 to version 13 and I still have no glitch.

I guess that would mean retropie 4.3 has something changed in it that is causing the issue.

Bobberella

So running retropie 4.2 and glideN64 v.7 I had no glitch... then I updated mupen64plus and I had glideN64 v. 13 and I still had no glitch.

When I "install/update all main packages from source" it caused the game to glitch.

But when I just updated "mupen64plus" from source it didnt cause the glitch...

And I am still running on retropie 4.2...

Feels like I am missing something. Lol

Maybe by updating all main packages there is something else installed besides the individual emulators?

EndersEnigma

@simonster
It is hard to get Mario64 to crash using glide in my experience on a 3B board, it just blurs for about 30 seconds then recovers. Have you tried any other games? I find Banjo Kazooie, Quest64, Aerofighters Assault, and Beetle adventure racing crash very consistently. I am curious on how the 3b+ handles those games using GLIDE.

quicksilver

Found this Reddit post from over a year ago:

https://www.reddit.com/r/RetroPie/comments/5tlx8h/zelda_oot_weird_issue

The second part of the post he describes how glide glitches out after playing for a while. I think this issue has been around for a long time and was never reported properly.

Drakaen391

Hadn’t glide always had issues? Or am I thinking about rice?

dankcushions

@drakaen391 all N64 HLE plugins have issues. Gliden64 is just about the only one being actively developed, though.

Ranma

I'm sure I'll be shouted down for this, but I've pretty much switched all my N64 stuff over to lr-mupen64plus now. It runs much better than it used to. I will add that my Pi 3 runs at 720p with slight overclock, and lr-mupen is at 640x480. GlideN64 is great but you need a powerful device to run it imho. I use it on Android (Mupen64 FZ) and the dev considers anything less than a Shield as a "low-end device". GlideN64 on the Pi, despite lowering the resolution right down to 240p still results in poor performance for me.

I honestly think it's time to reassess lr-mupen64plus on the Pi, as it's much better for me than it used to be. Not perfect but much better than it was. Only the occasional game uses one of the other plugins.