N64 crashes after 10 min

Ranma

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.

Ranma

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.

dankcushions

@Ranma typically all core and additional binaries are updated when there's a new retropie image released. beyond that, it's whenever it's deemed worthwhile.

GLideN64 might report its version in the /dev/shm/runcommand.log - not sure!

Ranma

@dankcushions said in N64 crashes after 10 min:

@Ranma typically all core and additional binaries are updated when there's a new retropie image released. beyond that, it's whenever it's deemed worthwhile.

GLideN64 might report its version in the /dev/shm/runcommand.log - not sure!

Awesome! Thanks for the details. :-)

quicksilver

@BuZz would it be worth updating the mupen64plus binaries now as opposed to waiting for next retropie version release? The current binary has the nasty gliden64 crash bug.

@thelostsoul also worth noting that the current mupen64plus version from source seems to solve the Yoshi's story glitch issue when using gliden64.

BuZz

@quicksilver I wasn't aware the crash bug was ever fixed? Got a reference?

quicksilver

@BuZz I don't think the bug was fixed intentionally. Unfortunately I don't know which commit inadvertently fixed the problem. I just happened to update from source around the beginning of January and the problem was solved. I have tested multiple games with gliden64 and left them running for several hours each and the crash issue is gone. I made a comment in this thread about it about a month ago. I also updated the GitHub issue tracker saying that the issue appeared to be fixed but I never got a response back there. Not sure if my word is enough to go on or someone with a little more clout needs to confirm.

shavecat

@quicksilver
I have the same issue,
got to say i also tried it .
if i keep a game ruining it can go for hours , but if i really play(not let it just be on running on the screen) more then half an hour at glitch out....

quicksilver

@shavecat the issue is solved for me whether I am playing or just letting the game run by itself. I should mention the glitch occured around 20-30 mins of a game running whether you were playing or not didn't matter.

If you update mupen64plus from source the issue is resolved. Have you updated mupen64plus from source?

shavecat

@quicksilver
OMG!?!
U kidding me right ?? ;)
will update now <3 !

shavecat

@quicksilver
Im Getting an error ,
Could not succssfully bulid mupen64plus - n 64 emulator MUPEN Plus
(Gliden64/projects/cmake/plugin/Release/mupen64plus-video-Gldien64.so not found).

quicksilver

@shavecat did you update retropie setup script first?

BuZz

It's not building currently. Upstream issue with GlideN64 plugin due to

[ 53%] Building CXX object CMakeFiles/mupen64plus-video-GLideN64.dir/Graphics/OpenGLContext/opengl_Attributes.cpp.o
/home/pi/RetroPie-Setup/tmp/build/mupen64plus/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp: In function ‘void initGLFunctions()’:
/home/pi/RetroPie-Setup/tmp/build/mupen64plus/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:10:47: error: ‘g_eglGetNativeClientBufferANDROID’ was not declared in this scope
 #define GL_GET_PROC_ADR(proc_type, proc_name) g_##proc_name = (proc_type) dlsym(gles2so, #proc_name);
                                               ^
/home/pi/RetroPie-Setup/tmp/build/mupen64plus/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:245:2: note: in expansion of macro ‘GL_GET_PROC_ADR’
  GL_GET_PROC_ADR(PFNEGLGETNATIVECLIENTBUFFERANDROIDPROC, eglGetNativeClientBufferANDROID);
  ^~~~~~~~~~~~~~~
/home/pi/RetroPie-Setup/tmp/build/mupen64plus/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:245:18: error: ‘PFNEGLGETNATIVECLIENTBUFFERANDROIDPROC’ was not declared in this scope
  GL_GET_PROC_ADR(PFNEGLGETNATIVECLIENTBUFFERANDROIDPROC, eglGetNativeClientBufferANDROID);
                  ^
/home/pi/RetroPie-Setup/tmp/build/mupen64plus/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:10:64: note: in definition of macro ‘GL_GET_PROC_ADR’
 #define GL_GET_PROC_ADR(proc_type, proc_name) g_##proc_name = (proc_type) dlsym(gles2so, #proc_name);
                                                                ^~~~~~~~~
CMakeFiles/mupen64plus-video-GLideN64.dir/build.make:1094: recipe for target 'CMakeFiles/mupen64plus-video-GLideN64.dir/Graphics/OpenGLContext/GLFunctions.cpp.o' failed

cause by commit:

commit f209304d0b052dd53fcaadfa9f21055ab9f489d5
Author: fzurita <fzurita@gmail.com>
Date:   Sun Feb 3 22:00:29 2019 -0500

    Add support for Android EGL Image Public API

I've not had a chance to debug further or report upstream yet. Will do that shortly.

shavecat

@quicksilver
yes i did ,
mupen64plus only that dont work the update from source .
the lr-mupen64plus works.

BuZz

https://github.com/gonetz/GLideN64/issues/2005

I'm going to temporarily lock RetroPie to the previous commit until this is resolved.

shavecat

@BuZz
so the issue not only on my pi ?
it will get fix ? :)

BuZz

@shavecat I have reported the issue upstream. I will do a workaround for RetroPie in the time being. patience! :)

shavecat

@BuZz
Thank u <3

BuZz

RetroPie-Setup is patched to use the commit before the one that broke it (so just before Feb 3rd). Binaries have been updated.

shavecat

@BuZz
So update from Binary will work ok ? ( no glitch ? )