N64 crashes after 10 min
-
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.
-
@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!
-
@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. :-)
-
@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.
-
@quicksilver I wasn't aware the crash bug was ever fixed? Got a reference?
-
@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.
-
@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.... -
@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?
-
@quicksilver
OMG!?!
U kidding me right ?? ;)
will update now <3 ! -
@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). -
@shavecat did you update retropie setup script first?
-
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.
-
@quicksilver
yes i did ,
mupen64plus only that dont work the update from source .
the lr-mupen64plus works. -
https://github.com/gonetz/GLideN64/issues/2005
I'm going to temporarily lock RetroPie to the previous commit until this is resolved.
-
@BuZz
so the issue not only on my pi ?
it will get fix ? :) -
@shavecat I have reported the issue upstream. I will do a workaround for RetroPie in the time being. patience! :)
-
@BuZz
Thank u <3
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.