search

libretro / mupen64plus-libretro-nx

Improved mupen64plus libretro core reimplementation
GNU General Public License v2.0
229 stars 114 forks source link

[META] Updated GLideN64 Issues #43

Closed m4xw closed 4 years ago

m4xw commented 5 years ago

Meta Thread regarding new GLideN64 Issues. Please confirm that bugs don't happen with standalone before reporting them here. No support requests

m4xw commented 5 years ago

https://github.com/libretro/mupen64plus-libretro-nx/issues/40

m4xw commented 5 years ago

https://github.com/libretro/mupen64plus-libretro-nx/issues/41 - wontfix

kirbyfan067 commented 5 years ago

Idk why but popular sm64 romhacks like last impact and star road just refuse to work. Btw they were working on the old mupen64plus (not the next version) but they suffered from some heavy graphical glitches.

m4xw commented 5 years ago

@kirbyfan067 These are broken romhacks

kirbyfan067 commented 5 years ago

But they worked well on other n64 emulators.

m4xw commented 5 years ago

@kirbyfan067 because they wrote their romhacks around quirks of older emulators. It's a Issue that will never be fixed, you'd have to ask the romhack author to fix it.

kirbyfan067 commented 5 years ago

Thanks for the answers.

kage52124 commented 5 years ago

Problem: black screen with sound and input working. Tested with Gauntlet Legends, Resident Evil 2, and Ocarina of Time.

OS: Ubuntu 18.04(.2) Intel Core i5 uname -r = 4.15.0-46-generic lspci | grep 'VGA" = Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) glxinfo | grep "OpenGL version" = OpenGL version string: 3.0 Mesa 18.2.2 EDIT: glxinfo | grep "version" = server glx version string: 1.4 client glx version string: 1.4 GLX version: 1.4 Max core profile version: 3.3 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.0 OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.2.2 OpenGL core profile shading language version string: 3.30 OpenGL version string: 3.0 Mesa 18.2.2 OpenGL shading language version string: 1.30 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.2.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

Running Retroarch also compiled from source, revision 6e971053fe

Compiled mupen64plus-next-libretro.so with these commands: git clone https://github.com/libretro/mupen64plus-libretro-nx.git cd mupen64plus-libretro-nx/ git fetch origin git checkout remotes/origin/GLideN64 make

m4xw commented 5 years ago

@kage52124 can you do in RA: ./configure --enable-debug and give me the log with --verbose Also can you seperately try the attached patchfile Unix_GL_Core.zip

kage52124 commented 5 years ago

The first request can be found here: https://pastebin.com/K9PgBk3U.

Ran "git apply --stat Unix_GL_Core.patch" after moving it to the right directory to patch it (I'm not a developer, just Googling as I go), I was able to get some insertions and deletions. Still did not work. Pastebin for that is https://pastebin.com/G92vb7ps

m4xw commented 5 years ago

@kage52124 shader on?

m4xw commented 5 years ago

also:

[ERROR] [GL debug (High, Shader compiler, Error)]: 0:1(10): error: GLSL 3.00 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES
[ERROR] [GL debug (High, Shader compiler, Error)]: 0:1(10): error: GLSL 3.00 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES

Seems to be the Issue :/ Did the older core work?

m4xw commented 5 years ago

@kage52124 try changing FORCE_GLES=0 to FORCE_GLES=1 in Makefile Line 2 And do a clean build.

kage52124 commented 5 years ago

No shaders enabled (brand new build with debugging turned on, was having unrelated problems with Ubuntu).

Traditional Mupen64Plus core from the buildbot does work just fine.

Forcing GLES fails completely:

[ERROR] Requesting OpenGLES2 context, but RetroArch is compiled against OpenGL. Cannot use HW context. [libretro ERROR] mupen64plus: libretro frontend doesn't have OpenGL support

I'd be more than happy to recompile Retroarch against OpenGL ES, but I don't know what to pass to the make command (if my computer can even do GLES).

m4xw commented 5 years ago

@kage52124 ./configure --enable-debug --enable-opengles

Pixelman546 commented 5 years ago

Not sure if the SM64 widescreen patch is counted as a "broken rom hack", but I just wanted to check because it wont work in mupen next. Half of the screen horizontally is cut off.

m4xw commented 5 years ago

nah thats just some of your settings

Pixelman546 commented 5 years ago

Alright. Thanks! I'll reset my settings then

kage52124 commented 5 years ago

Would not build with --enable-opengles, stuck on building the gl core.

m4xw commented 5 years ago

Honestly not sure why old mupen would work for you. Your GPU does not support the required GL version (3.3), it should only ever work with GLES2 or GLES3 (or Core profile if you are lucky)

m4xw commented 5 years ago

@kage52124 Try this patch (forcing 3.3 core profile and skipping ver detection) patch -p1 < Unix_GL_Core.patch

[INFO] [GL]: Vendor: Intel Open Source Technology Center, Renderer: Mesa DRI Intel(R) Sandybridge Mobile .
[INFO] [GL]: Version: 3.0 Mesa 18.2.8.

Seems it wasn't detecting the right ver when you tried Core profile.

Unix_GL_Core.zip

kage52124 commented 5 years ago

I had to clear everything in the directory to start over, but after doing that and applying the patch in the prior comment with the command you gave, I was able to boot it up.

I appreciate you trying so hard to get it running for me. I think my computer is a strange one. I've known that gaming is better on Linux for this old thing since it can handle more OpenGL functions than Windows can. I imagine that was the problem?

I ran it with --verbose, but I got a lot less debugging output, which is perhaps good?

m4xw commented 5 years ago

So does that fix it?

kage52124 commented 5 years ago

Yes. I'm fixed and can load the core and get good video output.

m4xw commented 5 years ago

How is perf on your ""GPU"" :P? Also can you add the patch to your instructions on reddit, until i figured a proper way to solve this? Btw can you try the same patch, but remove this from GLideN64/src/Graphics/OpenGLContext/opengl_GLInfo.cpp afterwards (before you update your post):

#if defined(CORE)
    majorVersion = 3;
    minorVersion = 3;
    isGLESX = false;
    isGLES2 = false;
#endif

If it still works without that, you did something wrong with the first patch, if it doesn't, I will need to figure it.

kage52124 commented 5 years ago

@m4xw Okay, I started completely over, removing the git directory and starting fresh:

git clone https://github.com/libretro/mupen64plus-libretro-nx.git cd mupen64plus-libretro-nx/ git fetch origin git checkout remotes/origin/GLideN64 patch -p1 < Unix_GL_Core.patch removed the code mentioned in the prior comment by deleting it make -j4

I can successfully run the core with these steps. I don't know what I could have done wrong though if I'm starting completely fresh.

Also, I'm afraid I don't understand your first sentence: "How is perf on your ""GPU"" :P?" I'm probably too old for this slang :-D

m4xw commented 5 years ago

Okay thanks for testing! Just tell me how your performance is with your integrated graphicscard.

retrorepair commented 5 years ago

The above mirrors my experience too, buildbot m64nx works but black screen with your build, patch works for me. Performance is good with my Radeon HD 5450.

Are there plans to add resolution switching with CRTswitchres? The resolutions that are selectable look quite wrong compared to angrylion.

kage52124 commented 5 years ago

@m4xw So while it does start and run, it crashes within just a few minutes on Ocarina of Time. Sound continues to play, video freezes, and it seems like the game enemies freeze as well since I am not getting hit by them. I'll add a --verbose soon.

Edit: No useful output for --verbose... I build RA with ./configure --enable-debug

m4xw commented 5 years ago

Lower max texture cache size in core options.

kage52124 commented 5 years ago

Okay, I tried lowering Max Texture Cache Size from the default 8000 to 1500, it still crashed (sooner, too).

m4xw commented 5 years ago

@kage52124 I got told the instability on ubuntu 18.04 might be related to libpng. Will investigate it when I find time.

kage52124 commented 5 years ago

@m4xw Okeydokey. Thanks for what you do. I'll be around for testing if you ever need.

kage52124 commented 5 years ago

@m4xw Hey, it's been a while. I wanted to let you know that I tried the same setup as before, but with the most recent version of Manjaro instead of Ubuntu, and I didn't freeze anymore.

See this release page for a possible reason why Ubuntu was different. Perhaps it's similar to your problem here?

shantigilbert commented 5 years ago

Not sure if I should open a new issue, hopefully this is in the right place.

I recently moved from the mupen_next branch to GLideN64 branch and I am now getting a segfault :

https://pastebin.com/SJ0LqgQR

These are my make arguments make platform=unix GLES=1 FORCE_GLES=1 HAVE_NEON=1 WITH_DYNAREC=arm

which were the same ones I used on mupen_next, I've also used platform=odroid and even added my own platform to the makefile 

diff --git a/Makefile b/Makefile
index e7bca7a..d6f45e6 100644
--- a/Makefile
+++ b/Makefile
@@ -186,6 +186,18 @@ else ifneq (,$(findstring odroid,$(platform)))

    COREFLAGS += -DOS_LINUX
    ASFLAGS = -f elf -d ELF_TYPE
+
+# Amlogic S905/S912
+else ifneq (,$(findstring amlogic,$(platform)))
+   TARGET := $(TARGET_NAME)_libretro.so
+   LDFLAGS += -shared -Wl,--version-script=$(LIBRETRO_DIR)/link.T -Wl,--no-undefined
+   GLES = 1
+   GL_LIB := -lGLESv2
+   CPUFLAGS += -marm -mfloat-abi=hard -mfpu=neon
+   HAVE_NEON = 1
+   WITH_DYNAREC=arm
+   CPUFLAGS += -march=armv8-a -mcpu=cortex-a53 -mtune=cortex-a53
+
 # OS X
 else ifneq (,$(findstring osx,$(platform)))
    TARGET := $(TARGET_NAME)_libretro.dylib

which is basically the same thing

I am using an Amlogic S905 with Mali 450, but it also happens on Odroid N2, running EmuELEC (based on CoreELEC/LibreELEC) 32bits ARM

Is there a way I can debug this further? I am not sure how to debug Libretro cores

m4xw commented 5 years ago

gdb backtrace? Take a look at GLideN64\src\Graphics\OpenGLContext\GLFunctions.cpp Maybe you need to specify your GLES lib there

shantigilbert commented 5 years ago

gdb backtrace?

I tried, but not sure if I need to compile Retroarch with debug symbols as well as the core

Maybe you need to specify your GLES lib there

void *gles2so = dlopen("/usr/lib/arm-linux-gnueabihf/libGLESv2.so", RTLD_NOW);

You mean a line like this with the correct path?

m4xw commented 5 years ago

You mean a line like this with the correct path?

Yes, you will also need the same codepath as ODROID/Raspberry (VC define)

shantigilbert commented 5 years ago

Yes, you will also need the same codepath as ODROID/Raspberry (VC define)

hmm you lost me there :(

I used this patch 

--- a/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp
+++ b/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp
@@ -207,7 +207,7 @@
 #ifdef VC
    void *gles2so = dlopen("/opt/vc/lib/libbrcmGLESv2.so", RTLD_NOW);
 #elif defined(ODROID)
-   void *gles2so = dlopen("/usr/lib/arm-linux-gnueabihf/libGLESv2.so", RTLD_NOW);
+   void *gles2so = dlopen("/usr/lib/libGLESv2.so", RTLD_NOW);
 #elif defined(VERO4K)
        void *gles2so = dlopen("/opt/vero3/lib/libGLESv2.so", RTLD_NOW);
 #endif

But its the same problem

shantigilbert commented 5 years ago

Ahh sorry I used the wrong compilation options, but now I get this error: 

GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp: In function 'void initGLFunctions()':
GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:208:50: error: 'RTLD_NOW' was not declared in this scope
  void *gles2so = dlopen("/usr/lib/libGLESv2.so", RTLD_NOW);
                                                  ^~~~~~~~
GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:208:50: note: suggested alternative: 'GL_NOR'
  void *gles2so = dlopen("/usr/lib/libGLESv2.so", RTLD_NOW);
                                                  ^~~~~~~~
                                                  GL_NOR
GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:208:18: error: 'dlopen' was not declared in this scope
  void *gles2so = dlopen("/usr/lib/libGLESv2.so", RTLD_NOW);
                  ^~~~~~
GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:208:18: note: suggested alternative: 'popen'
  void *gles2so = dlopen("/usr/lib/libGLESv2.so", RTLD_NOW);
                  ^~~~~~
                  popen
GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:208:8: warning: unused variable 'gles2so' [-Wunused-variable]
  void *gles2so = dlopen("/usr/lib/libGLESv2.so", RTLD_NOW);
        ^~~~~~~
make: *** [Makefile:450: GLideN64/src/Graphics/OpenGLContext/GLFunctions.o] Error 1
make: *** Waiting for unfinished jobs....
m4xw commented 5 years ago

@shantigilbert 

--- a/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp
+++ b/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp
@@ -12,7 +12,7 @@
 #define glGetProcAddress wglGetProcAddress
 #define GL_GET_PROC_ADR(proc_type, proc_name) ptr##proc_name = (proc_type) glGetProcAddress("gl"#proc_name)

-#elif defined(VERO4K) || defined(ODROID) || defined(VC)
+#elif defined(VERO4K) || defined(ODROID) || defined(VC) || defined(MY_PLATFORM)

 #include <dlfcn.h>
 #define GL_GET_PROC_ADR(proc_type, proc_name) ptr##proc_name = (proc_type) dlsym(gles2so, "gl"#proc_name);
@@ -210,6 +210,8 @@ extern "C" void initGLFunctions()
        void *gles2so = dlopen("/usr/lib/arm-linux-gnueabihf/libGLESv2.so", RTLD_NOW);
 #elif defined(VERO4K)
        void *gles2so = dlopen("/opt/vero3/lib/libGLESv2.so", RTLD_NOW);
+#elif defined(MY_PLATFORM)
+       void *gles2so = dlopen("/usr/lib/libGLESv2.so", RTLD_NOW);
 #endif

 #if defined(EGL) || defined(OS_IOS)

then in Makefile:

# Amlogic S905/S912
else ifneq (,$(findstring amlogic,$(platform)))
   TARGET := $(TARGET_NAME)_libretro.so
   LDFLAGS += -shared -Wl,--version-script=$(LIBRETRO_DIR)/link.T -Wl,--no-undefined -ldl
   GLES = 1
   GL_LIB := -lGLESv2
   CPUFLAGS += -marm -mfloat-abi=hard -mfpu=neon
   HAVE_NEON = 1
   WITH_DYNAREC=arm
   COREFLAGS += -DMY_PLATFORM -DOS_LINUX -DUNDEF_GL_GLEXT_PROTOTYPES
   CPUFLAGS += -march=armv8-a -mcpu=cortex-a53 -mtune=cortex-a53
shantigilbert commented 5 years ago

Thanks, almost worked!

edit: a stupid mistake on my side

But this is the error now 

./GLideN64/src/Graphics/OpenGLContext/GLFunctions.o:GLFunctions.cpp:function initGLFunctions: error: undefined reference to 'dlopen'
./GLideN64/src/Graphics/OpenGLContext/GLFunctions.o:GLFunctions.cpp:function initGLFunctions: error: undefined reference to 'dlsym'
./GLideN64/src/Graphics/OpenGLContext/GLFunctions.o:GLFunctions.cpp:function initGLFunctions: error: undefined reference to 'dlsym'
./GLideN64/src/Graphics/OpenGLContext/GLFunctions.o:GLFunctions.cpp:function initGLFunctions: error: undefined reference to 'dlsym'
./GLideN64/src/Graphics/OpenGLContext/GLFunctions.o:GLFunctions.cpp:function initGLFunctions: error: undefined reference to 'dlsym'
collect2: error: ld returned 1 exit status
make: *** [Makefile:432: mupen64plus_next_libretro.so] Error 1

this is in the linking stage

m4xw commented 5 years ago

@shantigilbert You didn't add -ldl to LDFLAGS

shantigilbert commented 5 years ago

you are right, I should learn to read better!

compiled and it runs now :)

m4xw commented 5 years ago

@shantigilbert feel free to clean it up and PR (also give MY_PLATFORM a proper name). If you encounter issues on a 2nd launch, related to shader storage, look at one of the recent commits for Pi. Dunno if that is common for GLES2, since it doesnt happen for me on android

shantigilbert commented 5 years ago

I will test it and if all works I can, if you like, submit a PR with the changes.

Thanks again

m4xw commented 5 years ago

Keep in mind GLES2 has some limitations (especially framebuffer stuff). So it will never be perfect. If your platform allows it, try GLES3

shantigilbert commented 5 years ago

Will try it

Update: GLES2 works very well, can't get GLES3 to run on my platform, even tho it compiles when it runs it fall-backs to GLES2.

escalade commented 5 years ago

@shantigilbert @m4xw

Segfaults in exactly the same way here on my XU4, any ideas? I've patched sources as such:

--- a/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp       2019-08-05 15:56:10.649859665 +0200
+++ b/GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp       2019-08-05 15:57:01.549193208 +0200
@@ -207,7 +207,7 @@
 #ifdef VC
        void *gles2so = dlopen("/opt/vc/lib/libbrcmGLESv2.so", RTLD_NOW);
 #elif defined(ODROID)
-       void *gles2so = dlopen("/usr/lib/arm-linux-gnueabihf/libGLESv2.so", RTLD_NOW);
+       void *gles2so = dlopen("/usr/lib/libGLESv2.so", RTLD_NOW);
 #elif defined(VERO4K)
        void *gles2so = dlopen("/opt/vero3/lib/libGLESv2.so", RTLD_NOW);
 #elif defined(AMLOGIC)
--- a/Makefile  2019-08-05 16:10:27.975585325 +0200
+++ b/Makefile  2019-08-05 16:12:04.327704900 +0200
@@ -189,7 +189,7 @@
 # ODROIDs
 else ifneq (,$(findstring odroid,$(platform)))
    TARGET := $(TARGET_NAME)_libretro.so
-   LDFLAGS += -shared -Wl,--version-script=$(LIBRETRO_DIR)/link.T -Wl,--no-undefined
+   LDFLAGS += -shared -Wl,--version-script=$(LIBRETRO_DIR)/link.T -Wl,--no-undefined -ldl
    BOARD := $(shell cat /proc/cpuinfo | grep -i odroid | awk '{print $$3}')
    GLES = 1
    GL_LIB := -lGLESv2
@@ -211,7 +211,7 @@
       CPUFLAGS += -mcpu=cortex-a9
    endif

-   COREFLAGS += -DOS_LINUX
+   COREFLAGS += -DOS_LINUX -DUNDEF_GL_GLEXT_PROTOTYPES -DODROID
    ASFLAGS = -f elf -d ELF_TYPE

 # Amlogic S905/S905X/S912 (AMLGXBB/AMLGXL/AMLGXM) e.g. Khadas VIM1/2 / S905X2 (AMLG12A) & S922X/A311D (AMLG12B) e.g. Khadas VIM3 - 32-bit userspace

Then I compile with "make platform=odroid BOARD=ODROID-XU4"

escalade commented 5 years ago

Did a gdb backtrace and found that it crashed at a strstr call. By chance I noticed https://github.com/libretro/mupen64plus-libretro-nx/pull/82/commits/bdcae7b749ecd79cd8d504a3b6f73a6c350d036f from the RPi4 PR which has resolved the issue for me. Compiles and runs using GLESv3 even :)