fbneo-screen flicker

[jgassie]

Hi, thanks for your efforts! Might you have an idea why on linux-arm when running space fury with fbneo_libretro the screen flickers wildly, and also causes some audio distortion? Not sure if it's related to the rom trying to use 40hz. The same setup under Windows+FBneo is fine for this same arcade game (spacfury.zip), I can't seem to find settings to resolve this under linux-arm. Other arcade roms tested so far (fbneo+arm) seem ok, although I haven't tried many, thank you!

[jgassie]

I tried the Jan 28 build, no difference for screen behavior there, but there still could be some setting to tweak this.

[zoltanvb]

I did a quick test but did not experience this, it plays slow (FPS counter confirms 40 fps) but not flickering. One option may be to try the same core extracted from a Lakka build if there is one that corresponds to your hardware, if it performs better, it may give a clue.

[jgassie]

Thank you. It is a custom build of RetroArch made by myarcade on an arm system, is it possible you could share your options settings or config under Linux? It's rather odd, but there could be some weird default value that is contributing. Note however, using RA+Mame2003-plus on the same system, there are no issues with the video and this specific game, so there's something different with the current FBNeo implementation causing the video anomaly, or perhaps a core-specific setting I'm missing I suppose.

[jgassie]

I've tried a lot of other retroarch configuration settings, but most settings match what I'm sending to RA-Mame2003, which doesn't have the display issue, so it's a bit baffling, although I still think it might be related to the 40hz setting in the game that FBNEO is not happy with in this case. But the video ratio settings essentially match what other platforms are running with. It wouldn't surprise me if there was a related issue with this 'custom' version of retroarch though.

[zoltanvb]

My tests were done with full default settings using an RPi 3 + recent nightly version of RA, nothing changed either in RA options or in core options. I'm afraid there is not much I can help with. Does not seem like a compilation problem.

[jgassie]

Thank you, it's probably something with the custom retroarch build that is effectively problematic under this scenario.

[jgassie]

Do you happen to have your own build of retroarch itself for linux-arm available? Let me know if you do, thank you!

[zoltanvb]

I did not upload it as it can vary a lot between systems, but I can do one. I assume OpenGL ES support is available on your HW, is it v2 or v3?

[jgassie]

The current build does list OpenGL ES under features, but the libglesv2 files are all size 0, I think it's using libglapi.so.0.0.0, the RA video driver is set to "gl"... I suppose it is just using OpenGL 1.1 by default? The usr/lib directory only has like 45 lib so files with any size. Other:

Linux version 4.4.194 (sunchip@sunchip-PowerEdge-R740) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05) ) #5148 SMP Fri Dec 8 14:45:50 CST 2023 CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: Rockchip RK3032 Dongle

[zoltanvb]

Okay, here is one attempt: https://github.com/zoltanvb/zoltanvb.github.io/blob/master/armv7-hf-neon/retroarch.zip

[jgassie]

Thank you, I'll give it a shot when I have the opportunity!!

On Thu, Feb 22, 2024 at 11:41 AM zoltanvb @.***> wrote:

Okay, here is one attempt:

https://github.com/zoltanvb/zoltanvb.github.io/blob/master/armv7-hf-neon/retroarch.zip

— Reply to this email directly, view it on GitHub https://github.com/zoltanvb/retroarch-cross-compile/issues/4#issuecomment-1959946256, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACL6GEJOGICB2574V2HRKJ3YU57L7AVCNFSM6AAAAABCODM4PSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJZHE2DMMRVGY . You are receiving this because you authored the thread.Message ID: @.***>

[jgassie]

The thing is with this build and another I found, is that it seems there are many libraries I'm missing that are required in order for the app to load completely.

I have downloaded many of the libraries, but I've been doing it one at a time, as the retroarch executable reports what's missing. I'm sure I'm mixing slightly different builds, sometimes for opensuse such as under rpmfind.net, or things I've found on archlinuxarm.org. Each time I get past one library, another comes up! I wish it could report all the missing libraries required at the same time!

On Thu, Feb 22, 2024 at 11:41 AM zoltanvb @.***> wrote:

Okay, here is one attempt:

https://github.com/zoltanvb/zoltanvb.github.io/blob/master/armv7-hf-neon/retroarch.zip

— Reply to this email directly, view it on GitHub https://github.com/zoltanvb/retroarch-cross-compile/issues/4#issuecomment-1959946256, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACL6GEJOGICB2574V2HRKJ3YU57L7AVCNFSM6AAAAABCODM4PSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJZHE2DMMRVGY . You are receiving this because you authored the thread.Message ID: @.***>

[zoltanvb]

Yes, that is annoying. The build container has most of the features supported, so it tries to enable them, while they are not present on the target machine.

Can you run this command for the working RA binary? I can probably set up the compilation based on that, readelf -d retroarch | grep Shared

[jgassie]

perhaps I needed quotes around retroarch, some errors at the end, but this did spit out readelf -d /usr/bin/retroarch | grep Shared

  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libhq2x.so]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libasound.so.2]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libxkbcommon.so.0]
 0x00000001 (NEEDED)                     Shared library: [libudev.so.1]
 0x00000001 (NEEDED)                     Shared library: [libmali.so.1]
 0x00000001 (NEEDED)                     Shared library: [libdrm.so.2]
 0x00000001 (NEEDED)                     Shared library: [libcrypto.so.1.0.0]
 0x00000001 (NEEDED)                     Shared library: [libz.so.1]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

of course, perhaps this isn't reasonable and is too limiting, as I did start placing other libraries where I define the library path on an SD card folder when I'm using a newer/more standard retroarch build.

[zoltanvb]

The binary behind the link is updated. I have tried to minimize dependencies, but there are still 3 libraries as extra, I hope it can be found (libEGL, libgbm, ld-linux-armhf). The libmali seems to be a quite elusive thing, a binary blob different per device, so I can not undertake to add it to the build environment.

Just for reference, this was the configuration: ./configure --disable-x11 --enable-kms --enable-egl --disable-pulse --disable-opengl1 --disable-opengl --disable-vulkan --disable-qt --disable-wayland --disable-freetype --disable-stb_font --disable-7zip --disable-v4l2 --disable-sdl --disable-sdl2 --disable-jack --disable-xdelta

[jgassie]

Well it's closer! Kept what I had before just in case, also needed:

libxcb-randr.so.0 
libGLdispatch.so.0
libXau.so.6
libXdmcp.so.6
libc.so.6

But now getting libc.so.6: symbol __nptl_set_robust_list_avail version GLIBC_PRIVATE not defined in file ld-linux-armhf.so.3 with link time reference

The libc and ld-linux-armhf files came from the same source, but there must be incompatibility somewhere, I'll see what else I can find out, thank you!

[jgassie]

I think part of the problem is that I've been trying to use LD_LIBRARY_PATH to point to a location on the sdcard, which has caused other issues I think, and trying get by with less files by renaming actual libraries to symlink matches looked at by the retroarch app, probably not the best approach. I do think though, that there are issues with some of the original library files being outdated or lacking, which cripples that version. Someone else had mentioned using CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++ with a build on this platform.

[zoltanvb]

Yep, it is quite hard to provide a generic RA linux executable for armv7 platforms. CC / CXX is less of a problem, it is rather the dependencies, in a bad case even libc version mismatch can cause failure. I don't think I can do much more about this.

[jgassie]

Thank you for your assistance! I may yet be able to use what you provided at some point.

[jgassie]

Curious, have you tried compiling a newer MAME release for linux-arm libretro such as 0.262 or newer?

[zoltanvb]

I did try a few times, but the build system was quite complex and did not lend itself to the cross-compile approach I am using here, it was always failing at some point.