Open s1eve-mcdichae1 opened 1 year ago
Not in Xubuntu 22.04.2 LTS (jammy) with RX 560.
$ glxinfo -B
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: AMD (0x1002)
Device: AMD Radeon RX 560 Series (polaris11, LLVM 15.0.6, DRM 3.42, 5.15.0-67-generic) (0x67ff)
Version: 22.2.5
Accelerated: yes
Video memory: 4096MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
VBO free memory - total: 3745 MB, largest block: 3745 MB
VBO free aux. memory - total: 4063 MB, largest block: 4063 MB
Texture free memory - total: 3745 MB, largest block: 3745 MB
Texture free aux. memory - total: 4063 MB, largest block: 4063 MB
Renderbuffer free memory - total: 3745 MB, largest block: 3745 MB
Renderbuffer free aux. memory - total: 4063 MB, largest block: 4063 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 4096 MB
Total available memory: 8192 MB
Currently available dedicated video memory: 3745 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 560 Series (polaris11, LLVM 15.0.6, DRM 3.42, 5.15.0-67-generic)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.2.5
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.2.5
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.2.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
Since you are using RetroPie, try:
--set Video-GLideN64[ThreadedVideo]=True --set Video-GLideN64[EnableFBEmulation]=True --set Video-GLideN64[EnableN64DepthCompare]=2 --set Video-GLideN64[EnableCopyColorToRDRAM]=2
The requirements for depth emulation on non-NVIDIA GPUs are especially heavy on CPU.
Yeah I suppose I should mention the environment. You're correct I am using RetroPie on Raspberry Pi 4 (2GB version) (ARM Linux/Debian 10/Raspberry Pi OS).
$ glxinfo -B
I don't have this command or know how to get similar information from my system.
$ glxinfo -B
-bash: glxinfo: command not found
Since you are using RetroPie, try:
--set Video-GLideN64[ThreadedVideo]=True --set Video-GLideN64[EnableFBEmulation]=True --set Video-GLideN64[EnableN64DepthCompare]=2 --set Video-GLideN64[EnableCopyColorToRDRAM]=2
The requirements for depth emulation on non-NVIDIA GPUs are especially heavy on CPU.
Thanks. I'm not at my box to test right now but I'll give this a shot when I can.
Since you are using RetroPie, try:
--set Video-GLideN64[ThreadedVideo]=True --set Video-GLideN64[EnableFBEmulation]=True --set Video-GLideN64[EnableN64DepthCompare]=2 --set Video-GLideN64[EnableCopyColorToRDRAM]=2
The requirements for depth emulation on non-NVIDIA GPUs are especially heavy on CPU.
I was able to test this out and unfortunately it didn't work.
Three of these were already set via mupen64plus.cfg
. The only one that wasn't (EnableN64DepthCompare = 2
) caused it to segfault immediately on startup (after the "load combiner shaders" screen, but before it ever gets to the "Nintendo64" splash.)
I also tried it with "1" and for a minute I almost thought it worked. I was able to activate the lens and walk around Mountain Village with it on, but as soon as I tried to activate it in Goron Village, it crashed again :(
N64depth compare option is not essential for Lens of Truth work.
I have no crash with it. Goron Village screen shot:
Probably the problem is with lack of video memory on Raspberry Pi 4. This effect uses several additional frame buffers. Try to use the original screen resolution, that is 320x240.
Probably the problem is with lack of video memory on Raspberry Pi 4. This effect uses several additional frame buffers. Try to use the original screen resolution, that is 320x240.
Thanks for looking.
It's obfuscated behind a couple layers of launch scripts but from what I can work out, I think this is the command that gets ultimately run on my system, when I launch it from the menu:
SDL_VIDEO_KMSDRM_CRTCID=87 SDL_VIDEO_KMSDRM_MODEID=24 SDL_AUDIODRIVER= SDL_VIDEO_RPI_SCALE_MODE=1 "/opt/retropie/emulators/mupen64plus/bin/mupen64plus" --noosd --set Video-GLideN64[UseNativeResolutionFactor]=1 --windowed --resolution 640x480 --rsp mupen64plus-rsp-hle.so --gfx mupen64plus-video-GLideN64.so --audio mupen64plus-audio-sdl.so --configdir /opt/retropie/configs/n64 --datadir /opt/retropie/configs/n64 "/home/pi/RetroPie/roms/n64/Legend of Zelda, The - Majora's Mask (USA).z64"
87-24 (those first two params it sets) is a 640x480 mode, that's the smallest available on my display (an old 720p VIZIO), there is no 320x240 available. So when I change the command to use --resolution 320x240
, it displays in the bottom corner, even when I change --windowed
to use --fullscreen
instead.
I've also got three more modes in that res, with 25, 26, and 27; I didn't know if this will make any difference so I tried them all, with no change. In all cases, I still get the crash.
Maybe this one just ain't run well on my RPi4 hardware...
there is no 320x240 available.
You need to set UseNativeResolutionFactor = 1 In that case all frame buffers will be rendered in native 320x240 resolution and then scaled to the screen resolution set in mupen64plus settings.
You need to set UseNativeResolutionFactor = 1
isn't that already done?
... --noosd --set Video-GLideN64[UseNativeResolutionFactor]=1 --windowed ...
How much VRAM do you have assigned to VideoCore? I hope that at least you are using 512 MB.
How much VRAM do you have assigned to VideoCore? I hope that at least you are using 512 MB.
manually assigning VRAM isn’t necessary/right for pi4: https://retropie.org.uk/docs/Memory-Split/#raspberry-pi-4
How much VRAM do you have assigned to VideoCore? I hope that at least you are using 512 MB.
manually assigning VRAM isn’t necessary/right for pi4: https://retropie.org.uk/docs/Memory-Split/#raspberry-pi-4
Regardless, I tried it anyway. (Everything I read mentions that "the 3D component" of the GPU is not affected by gpu_mem
setting, but I don't know if the Lens utilizes "the 3D component" or not. Nothing actually says it "doesn't matter" -- only that it doesn't matter "for 3D" specifically. While it didn't completely solve my problem, it did have some partial effect, in this case.)
On RPi, if I understand, we don't have "vram" and instead it's called "gpu_mem". Default for my Pi 4 is 76 MB, with a documented max of 256. 512 is out of spec. I tried setting 512 in my /boot/config.txt
anyway; I don't know if it actually did anything different than at 256, but it was reported as 512 by vcgencmd
, at least.
At 256+, I was able to use the lens in Mountain Village (previously it would crash here, at 76, so this setting does do something, at least) but with this, and even at 512 (out of spec), it still crashed in Goron Village.
Combining this (gpu_mem=256
) with my previous partial-success (EnableN64DepthCompare = 1
), crashed immediately when I activate the Lens in Mountain Village, again.
gpu_mem is on pi4 is only used for VPU (camera/decoding) - see this from one of the engineers: https://forums.raspberrypi.com/viewtopic.php?p=1491512&sid=49e4636f5ad380a0338772751b98df05#p1491512 - so reserving any more than the default is just wasting memory for emulation.
i suspect you're just seeing some placebo effect. i suspect better results may be possible on latest kernel, os, 64-bit and video drivers. what is packaged with retropie is 32-bit with outdated video drivers. there are lots of known/unknown issues with them, and lack of features.
i suspect better results may be possible on latest kernel, os, 64-bit and video drivers. what is packaged with retropie is 32-bit with outdated video drivers. there are lots of known/unknown issues with them, and lack of features.
Is there a good resource to learn more about this? I know that the "bullseye" OS is planned for a future release of RP, but not yet ready for prime-time. Is it mostly usable with just a few edge cases to work out, or is it still a bit more "experimental" than that?
I know absolutely nothing about the Raspberry Pi.
I don't have any graphics card with less than 256 MB. The experience is already bad enough with 512 MB and the limitations of OpenGL 3.3.
Happens equally in both:
2a0a8acb61538235bc1094d297fb6556 Legend of Zelda, The - Majora's Mask (USA).z64
...and:
ac0751dbc23ab2ec0c3144203aca0003 Legend of Zelda, The - Majora's Mask (USA) (GameCube).z64
(This was initially discovered during a playthrough using the "GameCube" version. Subsequent testing done with the "regular/original" version. Interestingly, the same save file works for both titles.)
Problem: in some areas, activating Lens of Truth crashes the game.
WORKS in Clock Town WORKS in Termina Field WORKS on the trail to Mountain Village WORKS (sometimes*) on the trail to Snowhead WORKS on the trail to Goron Village
CRASHES in Mountain Village CRASHES in Goron Village
*(on continued testing, sometimes it would crash in this area as well, a second or so after activating the lens. In the villages proper it would crash immediately and every time.)
To reproduce: the attached save file places you in Mountain Village. Exit to the south or southeast to confirm that the lens works. Then, return to Mountain Village or continue on to Goron Village, and activate the lens to initiate crash.
Save file: Legend of Zelda, The - Majora's Mask (U) [!].fla.zip
Log: https://pastebin.com/KCwcBfsW
Other things I have tried:
rice video plugin: lens works, but graphical glitches are pervasive (example: severe flickering on pause/item select screen, bomber's notebook inaccessible.)
libretro core: lens works, but game runs less performant with increased audio dropouts and a noticeably slower framerate.