search

libretro / RetroArch

Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.
http://www.libretro.com
GNU General Public License v3.0
10.34k stars 1.84k forks source link

fif_libretro (Fix-It Felix Jr.) compatibility issues (Debian Retroarch armhf) #15802

Closed Technoturnovers closed 1 year ago

Technoturnovers commented 1 year ago

Description

The core 'fif_libretro.so', the libretro core for the promotional Fix-It Felix Jr. arcade game licensed for AtGames cabinets and plug-n-play systems (originally developed by Code Mystics for Disney's promotional cabinets), crashes with a segmentation fault upon attempting to load with RetroArch for the armhf Linux platform (fif_libretro.so is a 32-bit ARMv8 ELF file).

Expected behavior

Pictured is the game running properly under Ludo, another libretro frontend that works on armhf Linux platforms: image

Actual behavior

Whenever I attempt to load fif_libretro.so, pointing it to the fif.rom dummy file (all actual game functionality is via the core, with assets loaded from the directory that contains fif.rom), it crashes with the following log output:

technoturnovers@debian-arm64:~/.config/retroarch/assets$ retroarch --verbose -L /usr/lib/aarch64-linux-gnu/libretro/fif_libretro.so /home/technoturnovers/.config/retroarch/assets/res_fif/fif.rom > log.txt
[INFO] [Config]: Looking for config in: "/home/technoturnovers/.config/retroarch/retroarch.cfg".
[INFO] RetroArch 1.15.0 (Git b2ceb50)
[INFO] === Build =======================================
[INFO] Capabilities: NEON ASIMD
[INFO] Built: Sep 29 2023
[INFO] Version: 1.15.0
[INFO] Git: b2ceb50
[INFO] =================================================
[INFO] [Input]: Found input driver: "x".
[INFO] [Core]: Loading dynamic libretro core from: "/usr/lib/aarch64-linux-gnu/libretro/fif_libretro.so"
[INFO] [Overrides]: Redirecting save file to "/home/technoturnovers/.config/retroarch/saves/fif.srm".
[INFO] [Overrides]: Redirecting save state to "/home/technoturnovers/.config/retroarch/states/fif.state".
[INFO] [Content]: Loading content file: "/home/technoturnovers/.config/retroarch/assets/res_fif/fif.rom".
[INFO] [Environ]: SET_INPUT_DESCRIPTORS:
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Replay]: Found last replay slot: #0
[INFO] [SRAM]: Skipping SRAM load.
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
Segmentation fault

It's worth noting that I've been unable to get Retroarch's actual frontend GUI working under this particular configuration without unusable levels of lag (it always throws a libEGL error, which is another issue entirely), but I was able to verify that it actually works by using the command line to launch the mgba core directly with a test ROM.

Steps to reproduce the bug

You are going to need to install Debian Testing ARM64 onto qemu-system-aarch64's generic 'virt' machine type. This is a painful experience that will likely involve switching to TTY3 multiple times to fix broken packages on the fly, as it will often take multiple attempts for dpkg to actually install all of the selected system packages without crashing mid LZMA extraction. After that, you are going to need to add the armhf platform to your system's multiarch configuration; merely installing a Debian armhf system is unsuitable, as Debian armhf targets ARMv7 as opposed to 32-bit ARMv8 like we want. Finally, install libretro:armhf, try to launch the fif_libretro core, and watch it segfault.

Here's the QEMU launch string that got everything mostly working for me (even getting it to show the mouse cursor was an adventure):

qemu-system-aarch64 -machine virt,gic-version=max -cpu cortex-a53 -m 4G -smp 4 -netdev user,id=vnet,hostfwd=:127.0.0.1:0-:22 -device virtio-net-pci,netdev=vnet -drive file=harddisk.img,if=none,id=drive0,cache=writeback -device virtio-blk,drive=drive0,bootindex=0 -drive file=flash0.img,format=raw,if=pflash -drive file=flash1.img,format=raw,if=pflash -device virtio-gpu-pci -device qemu-xhci -device usb-kbd -device usb-tablet -display sdl,show-cursor=on

flash0.img is the AArch64 EFI image, flash1.img is a 64mb blank img for EFI vars, and harddisk.img is self explanatory (I advise at least 10gigs for the image). You're also going to need to specify install media, of course (I used the arm64 netinst iso).

As for getting AtGames's version of Fix-It Felix Jr. (NOT the leaked alpha build for Windows)..... uhhhhhh........... good luck. Or you could buy an overpriced AtGames Legends Flashback and telnet into it to grab the files, I guess.

Version/Commit

Environment information

gouchi commented 1 year ago

Hi,

Where is the source of this core ?

Moreover, could you make some test with latest stable release ?

Thank you.

Technoturnovers commented 1 year ago

Hi,

Where is the source of this core ?

Moreover, could you make some test with latest stable release ?

Thank you.

The core is loaded onto AtGames's home arcade and plug-n-play systems, and it's also online through a couple of sources- although I can't link to them, because that would effectively be linking to a ROM.

I'll try to use the latest stable release- is there an ARMHF deb package or binary tarball suitable for Debian, or will I need to compile it myself?

gouchi commented 1 year ago

Debian packages have not been updated yet to latest stable version so you should try to compile it by yourself using something like 

apt build-dep retroarch
apt install -y build-essential git
git clone https://github.com/libretro/RetroArch.git
cd RetroArch
git checkout v1.16.0.3
./configure && make -j$(nproc) && sudo make install
Technoturnovers commented 1 year ago

Alright, I'll do that as soon as I'm back at my computer, although it'll take a while given how slow this VM is. Although as another question- how do I get it to compile for armhf? Because if I just leave it to defaults it will compile for arm64, and that's incorrect. EDIT: figured out how to configure for cross-comp, just needed to install gcc-arm-linux-gnueabihf and g++-arm-linux-gnueabihf, then run ./configure- problem is, make is still trying to use my ARM64 library path

Technoturnovers commented 1 year ago

I can't get this to cross-compile, at least, not without a lot more toolchain knowledge than I have now (which is basically none)

hizzlekizzle commented 1 year ago

cross-compiling RetroArch is a hassle due to the dependencies. It's usually easier to just wait on it to compile natively in my experience.

Technoturnovers commented 1 year ago

cross-compiling RetroArch is a hassle due to the dependencies. It's usually easier to just wait on it to compile natively in my experience.

Except in that case, I can't do that- the VM I have is ARM64 Debian, and the libretro core is 32-bit ARMv8. I could spin up an ARMHF Debian VM, but just installing an ARMHF version of Debian would take another all-nighter on my part babysitting the installer. Thankfully, Snap allegedly has a Debian armhf version of retroarch, so I should be able to get it via snap

EDIT: Using the snap version didn't work out, I'm gonna need to install armhf debian I guess.

zoltanvb commented 1 year ago

Check https://github.com/zoltanvb/retroarch-cross-compile for cross-compiling.

Do you think the problem can be reproduced on a Raspberry Pi 3/4?

Technoturnovers commented 1 year ago

Check https://github.com/zoltanvb/retroarch-cross-compile for cross-compiling.

Do you think the problem can be reproduced on a Raspberry Pi 3/4?

I think testing on the Raspberry Pi is absolutely worthwhile in any case, since running this on the RPi is going to be the actual main usecase for the setup I created (emulation is just too laggy to be really playable)- the problem is, I don't have a spare Raspberry Pi to test with, or I would have done so already, hence the screwing around with VMs.

Also, I just installed Debian armhf already, so I'm going to try to compile there first and see if that works.

Technoturnovers commented 1 year ago

Alright, I compiled the latest RetroArch version for armhf and it still segfaulted, so I think that means that the issue can be confirmed.

technoturnovers@debian-arm64:~/RetroArch$ ./retroarch --verbose -L /home/technoturnovers/Documents/fif_libretro.so /home/technoturnovers/.config/retroarch/assets/res_fif/fif.rom > ~/retroarch1.log
[INFO] [Config]: Looking for config in: "/home/technoturnovers/.config/retroarch/retroarch.cfg".
[INFO] RetroArch 1.16.0 (Git 6c2cc45628)
[INFO] === Build =======================================
[INFO] Capabilities: ASIMD 
[INFO] Version: 1.16.0
[INFO] Git: 6c2cc45628
[INFO] Built: Oct 16 2023
[INFO] =================================================
[INFO] [Input]: Found input driver: "x".
[INFO] [Core]: Loading dynamic libretro core from: "/home/technoturnovers/Documents/fif_libretro.so"
[INFO] [Overrides]: Redirecting save file to "/home/technoturnovers/.config/retroarch/saves/fif.srm".
[INFO] [Overrides]: Redirecting save state to "/home/technoturnovers/.config/retroarch/states/fif.state".
[INFO] [Content]: Loading content file: "/home/technoturnovers/.config/retroarch/assets/res_fif/fif.rom".
[INFO] [Environ]: SET_INPUT_DESCRIPTORS:
[INFO] [Environ]: SET_PIXEL_FORMAT: RGB565.
[INFO] [Replay]: Found last replay slot: #0
[INFO] [SRAM]: Skipping SRAM load.
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Core]: Geometry: 240x320, Aspect: 0.000, FPS: 60.00, Sample rate: 44100.00 Hz.
Segmentation fault
Technoturnovers commented 1 year ago

So, something strange that I noticed: with the new version I compiled I was able to get into the RetroArch GUI with usable performance, but when I try to load fif_libretro.so from there, it doesn't crash, it just kicks me back to the main menu and doesn't load the core at all. I checked the logs, but when this happens it doesn't actually produce any log output, even set at debug loglevel, it's completely silent. Not sure what this might suggest in terms of the issue, but it seemed notable to me.

gouchi commented 1 year ago

Thank you for the log.

I am afraid we will need the core to be compiled also with DEBUG.

Technoturnovers commented 1 year ago

Thank you for the log.

I am afraid we will need the core to be compiled also with DEBUG.

Unfortunately, that is impossible due to the core being proprietary; while the core was inexplicably compiled with all of the function names and whatnot intact, as evident through objdump, they did not go as far as to leave in actual debug symbols. What I'm going to try next is to compile an older version of RetroArch and see if that works- this is a standard compliant libretro core, as evident from it working under Ludo, and as far as I'm aware the AtGames systems use compliant libretro frontends, but this core was originally released in 2019, and this dump is from 2021, so there's the possibility that some RetroArch version made a breaking change. There's also the remaining (if unlikely) possibility that this is some sort of emulation or architecture issue, although I won't be able to test with an ARM64 Raspberry Pi for some time, since my only current one is acting as my KVM over IP device.

If I do manage to get this working under an older version of RetroArch, then this issue can pretty much be considered fixed for at least my purposes, because this core requires deliberate effort to make work in the first place due to the architecture requirements, so having to compile an older version of RetroArch wouldn't be terribly more strenuous than having to install an armhf version of RetroArch in the first place.

Technoturnovers commented 1 year ago

image Confirmed WORKING on RetroArch 1.9.0- I had to compile it with ffmpeg disabled due to an apparent breaking library change between when 1.9.0 was released and now, (scratch that, apparently I never actually installed ffmpeg) but otherwise, I just used the defaults for compilation. It also doesn't have the blurry rendering artifacts apparent in Ludo, which is interesting. I haven't been able to test audio yet, since I didn't install any audio packages on this particular VM, but I'll do that as soon as possible.

hizzlekizzle commented 1 year ago

any chance you could bisect and see where it broke? Ideally, old cores should work on new RetroArch builds and vice versa, so if that's not happening, we'd like to fix it.

Technoturnovers commented 1 year ago

I'll try, although this VM is really really slow to compile on, so it's going to take a while- first I'm recompiling 1.9.0 just so I can verify sound works and that ffmpeg will at least compile, then I think I'll test out RA 1.13.0. If that works then I'll know to test 1.14.0 (since 16 and 15 are already confirmed nonworking), if not then I'll continue down the line.

hizzlekizzle commented 1 year ago

sounds good. thanks for your help tracking it down :)

Technoturnovers commented 1 year ago

Alright, ffmpeg doesn't compile even with the package installed, but I went to my existing compile and confirmed audio works- now to compile 1.13

Technoturnovers commented 1 year ago

1.13.0 compiles with defaults, but segfaults upon attempting to load the core. Attempting to compile 1.11.1 now

Technoturnovers commented 1 year ago

1.11.1 compiles with defaults, but also segfaults- now attempting with 1.10.3

Technoturnovers commented 1 year ago

Retroarch 1.10.3 compiled with defaults, and it WORKS, now I'm going to try 1.11.0 to eliminate the last unknown version

Technoturnovers commented 1 year ago

Alright, 1.11.0 compiled with default settings and crashed with a segfault, so that more or less confirms that 1.11.0 introduced some sort of breaking change. One interesting thing I noticed, however, is that even on the versions where Fix-It Felix Jr. works, closing the program forcefully (ie, hitting the window's X button) rather than exiting properly using the menu will also make it complain about a segfault in the console; that makes me wonder if this isn't actually a segmentation fault that's the cause of the crash here, but rather just a side effect of some other crash scenario causing a sudden exit to the program.

Also, I said earlier that using an older version of RA would work for my purposes, but then it occurred to me that re-recording (replay anchored savestates) was only added in 1.15.0, so it actually would be helpful if this could be made to work in a new version of RA. In the meantime, 1.10.3 works well enough, and while I was hoping to be able to use an ARM64 Raspberry Pi for native hardware testing purposes, that just isn't going to happen in a reasonable amount of time, so I'm going to see if I can use my crappy old Pi 1 model B. It should work, since I've been doing my latest tests on an ARMv7 VM, although there's still a slight chance that this could mean performance issues, if unlikely. I'll report back with my findings on native hardware.

Technoturnovers commented 1 year ago

This idea just occurred to me- would it be helpful if I started to try bisecting down to the individual commits? It would take a lot of time, but hopefully not an impossible amount of time if I just split by half every attempt. EDIT: ahhhhh, that's what git bisect is for, I've been doing it manually, whoops.

hizzlekizzle commented 1 year ago

heh, yes, that is ultimately necessary for tracking down whatever changed, so if that's something you're willing to do, it would be most helpful.

Re: re-recording, if you meant the button-log replays, they've existed since the very beginning, they just weren't exposed in the menus, so if you play around with the command line switches in older versions, you should still be able to do it.

Technoturnovers commented 1 year ago

heh, yes, that is ultimately necessary for tracking down whatever changed, so if that's something you're willing to do, it would be most helpful.

Re: re-recording, if you meant the button-log replays, they've existed since the very beginning, they just weren't exposed in the menus, so if you play around with the command line switches in older versions, you should still be able to do it.

Working on it right now. And by re-recording, I mean the ability to load a savestate and continue recording while maintaining input log integrity in accordance with TASing standards, which has only been a thing since the 1.15.0 release.

Technoturnovers commented 1 year ago

I found the breaking commit: b2634ea5885b6f09697c4b0d13e8d9c93ca381ea 

b2634ea5885b6f09697c4b0d13e8d9c93ca381ea is the first bad commit
commit b2634ea5885b6f09697c4b0d13e8d9c93ca381ea
Author: LibretroAdmin <reallibretroretroarch@gmail.com>
Date:   Thu Aug 4 14:18:11 2022 +0200

    * Create fill_pathname_join_special - and specify fill_pathname_join
    as deprecated.
    * Use fill_pathname_join_special in the vast majority of cases where
    we can ensure out_path is a new empty string
    * Get rid of some extension concatenation with strlcat where encountered
    * Some general cleanups with NULL termination of strings that get immediately
    passed to strlcpy/strlcpy-adjacent functions

While I'm not really a very experienced programmer, so I don't really know what this commit actually does, I think it might be useful if I explained what the fif_libretro core requires in terms of files in order to run, since this seems to have to do with file paths.

fif_libretro.so is a core with no accompanying info file that takes a "rom" in the form of fif.rom; however, fif.rom is just a text file containing the plaintext 'FIF', so all it effectively is is a dummy file that serves as a way for the core to receive the directory with the actual image and sound assets in it, of which there are the following (SHA-1 hashes included):

SHA-1:
709f2f1a9147d9987a00c2c86ad1beced4ed4b75  ./fif_libretro.so
7a40f13a4f3cab9348f71cef4f3cbe155eadcb4f  ./res_fif/controls.log
2314358705f32d68c8709a990e724ecef3ed7b4c  ./res_fif/fif.rom
74f346a151e16e479de68e7ede99f6077749971a  ./res_fif/fif.rom.l.png
1f764f5f5b4387dd7853719b707aa5e852672108  ./res_fif/fif.rom.png
3fac5a8704d8f97e378152132e7e6ceb3288940f  ./res_fif/fif.rom.s.png
34a5dca2810f31ea7336b167b2e89dfba953db94  ./res_fif/sound0.wav
c9e41e0a3ef7b8b99bc04922135d4d9e772e0b8c  ./res_fif/sound1.wav
fb0fcd30c2736faec27cb2e6ae392c0ba997204f  ./res_fif/sound10.wav
f4fe6d07446e633d327fa0b5e8f77b51812236d9  ./res_fif/sound11.wav
c30eab4db02adf7be7fe4f1fc8bffd5b949e292c  ./res_fif/sound12.wav
c60445a5afc41fa1c7306e494de3d977c1860054  ./res_fif/sound13.wav
43619830a69d1541c432afcb27937ee928668e79  ./res_fif/sound14.wav
393f02665bccc12c71d78c8b406a81b623ff660d  ./res_fif/sound15.wav
9f3146264532fe42083fdfc5beef902046a91d20  ./res_fif/sound16.wav
56aa52bb0032aaa9edcdfe476b7af853b0a873d7  ./res_fif/sound17.wav
dba72e4253047894170d7b1b4fa48ea7f9b74f32  ./res_fif/sound18.wav
3517443234d3d75e485e23607fc34b699d5700d1  ./res_fif/sound19.wav
d296e8eef2059c6d2b00a49f78ada9828e6fb395  ./res_fif/sound2.wav
3bbd8ca70019b2123143d6397732b5877c5fc304  ./res_fif/sound20.wav
022138961a374d4eda7a133796b476edf87cb3b7  ./res_fif/sound21.wav
a89280408c43b5624b2ff4c84cbe66f1d83ddd18  ./res_fif/sound22.wav
8401b37e7bcaa4eef7caac2c3ef05a47c0f29847  ./res_fif/sound23.wav
2798b239ce23a22847cda2936cdfbb00e280b395  ./res_fif/sound24.wav
2bed76ffe0e3aa7137b4611b10dac1296dc6ffee  ./res_fif/sound25.wav
a93a3593b729444591f616afb981f454e2177a0c  ./res_fif/sound26.wav
5effb7b0fd79033973d7a66601cfe589a65893c2  ./res_fif/sound27.wav
0f0043be3fb2b97e207ee15684d8fb1f12fa9f3d  ./res_fif/sound28.wav
63a43994cc3a8fd92011e5a3b5d1ba8d501d07a5  ./res_fif/sound29.wav
404de5cb7d6a56ab9a17405e9241494693f79021  ./res_fif/sound3.wav
8f75836a9ba115b77c1e1002560b2896c62b61af  ./res_fif/sound30.wav
672ba3d47cdd654f82b8ee6c84572ee20ae7117c  ./res_fif/sound31.wav
a44af75d16a9e2f79d1dcead24dba35001913b09  ./res_fif/sound4.wav
6ecb91ac9534eaaa4069a043661c9c16e21942d2  ./res_fif/sound5.wav
66365bd6dc650d714547cfd46278da692b40fe22  ./res_fif/sound6.wav
ed09b930615429362628cde3713ec31cd2ce1a31  ./res_fif/sound7.wav
e21920b85c2edae9e7614251e0cf90b808de0072  ./res_fif/sound8.wav
1bd8cb6c168db29ecfa73e6e776277af21166579  ./res_fif/sound9.wav
3bd2ad5d0d481b813b00024cb0e290133238c5ba  ./res_fif/texture2.bmp

If any further info on the core is needed, I'm all up for answering any questions or doing any tests that I can, since this is a seriously hard file to acquire (although is IS out there).

EDIT: Also, since we now know where the breaking change was introduced, should this issue get a name change, and maybe some tags?

hizzlekizzle commented 1 year ago

oh jeez, that commit's gonna be a tough one to pin down. It touched a lot of files

Technoturnovers commented 1 year ago

oh jeez, that commit's gonna be a tough one to pin down. It touched a lot of files

What I plan on doing is first compiling with debug enabled, to see if that reveals any useful information- if not, then I think I'm going to compile with all features disabled except those required for RetroArch's functioning (if anyone could give me a short list of such required parameters, that would help)

Technoturnovers commented 1 year ago

Alright, here's the full log from my GDB session:

GDB backtrace ``` technoturnovers@debian-armhf:~/retroarch-broken/RetroArch$ gdb --args ./retroarch --verbose -L /home/technoturnovers/fif_libretro.so /home/technoturnovers/res_fif/fif.rom GNU gdb (Debian 13.2-1) 13.2 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabihf". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./retroarch... (gdb) run Starting program: /home/technoturnovers/retroarch-broken/RetroArch/retroarch --verbose -L /home/technoturnovers/fif_libretro.so /home/technoturnovers/res_fif/fif.rom [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [INFO] [Config]: Loading default config. [INFO] [Config]: Looking for config in: "/home/technoturnovers/.config/retroarch/retroarch.cfg". [New Thread 0xad0ed9a0 (LWP 7346)] Thread 1 "retroarch" received signal SIGSEGV, Segmentation fault. 0x0050abb8 in string_is_empty (data=0x3e8 ) at ./libretro-common/include/string/stdstring.h:67 67 return !data || (*data == '\0'); (gdb) bt full #0 0x0050abb8 in string_is_empty (data=0x3e8 ) at ./libretro-common/include/string/stdstring.h:67 #1 0x0050c86a in cheat_manager_get_game_specific_filename (s=0xbeffdc28 "\250\276\217\266", len=4096, path_cheat_database=0xad1000b6 "/home/technoturnovers/.config/retroarch/cheats", saving=false) at cheat_manager.c:722 s1 = "m\312\333\"m\312\333\"\350A", '\000' , "\377\027\000\000\000\020\000\000\000\000\000\000\000\000\000\000\002\000\000\000\350\003\000\000\350\003\000\000\350A\000\000\232:\t\000\000\000\000\000\000\020\000\000\000\000\000\000\b\000\000\000\000\000\000\000t80\000\000\000\000\000\200\2150e\000\000\000\000QK`\"", '\000' ... system_info = {library_name = 0x3e8 , library_version = 0x3e8 , valid_extensions = 0x1000 , need_fullpath = 81, block_extract = 75} runloop_st = 0x11fbad0 core_name = 0x3e8 game_name = 0x120e026 "fif.cht" #2 0x0050c938 in cheat_manager_load_game_specific_cheats (path_cheat_database=0xad1000b6 "/home/technoturnovers/.config/retroarch/cheats") at cheat_manager.c:746 cheat_file = "\250\276\217\266\000`\246\265\030]\272\2658Z\272\265\230N\272\265\240K\272\265\250H\272\265\300E\272\265\340B\272\265\000@\272\265(z\272\265@t\272\265Xq\272\265xn\272\265\210k\272\265\240h\272\265\300e\272\265\340b\272\265@(\302\265`%\302\265\230\037\302\265XW\272\265\260\034\302\265x\312\217\266\230\304\217\266\260r\246\265\bg\246\265\340$\214\266\210x\246\265\360\343\375\266\360\030\214\266x{\246\265h\373\375\266\000@\246\265\230u\246\265\370B\246\265\350E\246\265\260o\206\266\000\000\000\000#1(\264\370\330\217\266\000\020\302\265\210\347\217\266\360b\246\265(O\246\265\bR\246\265xU\246\265\320Y\246\265\224\374\036\264\263\221\226\006"... #3 0x00490a0e in command_event_init_cheats (apply_cheats_after_load=false, path_cheat_db=0xad1000b6 "/home/technoturnovers/.config/retroarch/cheats", bsv_movie_data=0x0) at command.c:1187 allow_cheats = true bsv_movie_state_handle = 0x0 #4 0x0047a8fe in retroarch_main_init (argc=5, argv=0xbefff2d4) at retroarch.c:5450 verbosity_enabled = true init_failed = false p_rarch = 0x11f25f0 --Type for more, q to quit, c to continue without paging-- runloop_st = 0x11fbad0 input_st = 0x1248360 video_st = 0x125f6c8 settings = 0xad0ef008 recording_st = 0x12181a8 global = 0x11fb818 access_st = 0x11fb80c accessibility_enable = false accessibility_narrator_speech_speed = 5 menu_st = 0x12b9290 #5 0x004b7c2a in content_load (info=0xbefff118, p_content=0x11fbf14 ) at tasks/task_content.c:1451 i = 0 success = false rarch_argc = 0 rarch_argv = {0x0 } argv_copy = {0x0 } rarch_argv_ptr = 0xbefff2d4 rarch_argc_ptr = 0xbefff124 wrap_args = 0x133ba78 #6 0x004b9320 in task_load_content_internal (content_info=0xbefff118, loading_from_menu=true, loading_from_cli=true, loading_from_companion_ui=false) at tasks/task_content.c:2526 content_ctx = {name_ips = 0x0, name_bps = 0x0, name_ups = 0x0, valid_extensions = 0x0, directory_cache = 0x0, directory_system = 0x0, subsystem = {data = 0x0, size = 0}, block_extract = false, need_fullpath = false, set_supports_no_game_enable = false, is_ips_pref = false, is_bps_pref = false, is_ups_pref = false, patch_is_blocked = false, bios_is_missing = false, check_firmware_before_loading = false} p_content = 0x11fbf14 ret = false runloop_st = 0x11fbad0 sys_info = 0x11ff028 settings = 0xad0ef008 check_firmware_before_loading = false --Type for more, q to quit, c to continue without paging-- set_supports_no_game_enable = false path_dir_system = 0xad11e0b6 "/home/technoturnovers/.config/retroarch/system" path_dir_cache = 0xad11f0b6 "" #7 0x004b94b8 in task_push_load_content_from_cli (core_path=0x0, fullpath=0x0, content_info=0xbefff118, type=CORE_TYPE_PLAIN, cb=0x0, user_data=0x0) at tasks/task_content.c:2606 #8 0x00476a4e in rarch_main (argc=5, argv=0xbefff2d4, data=0x0) at retroarch.c:3847 info = {argv = 0xbefff2d4, args = 0x0, environ_get = 0x46d555 , argc = 5} p_rarch = 0x11f25f0 runloop_st = 0x11fbad0 video_st = 0x125f6c8 #9 0x007b1d84 in main(int, char**) (argc=5, argv=0xbefff2d4) at ui/drivers/ui_qt.cpp:4318 ```

Best as I can tell, RA seems to be freaking out about the fact that fif_libretro gives literally zero info about itself; if that's the case, then it should be as simple as making it so that it doesn't just faceplant when that happens, although that could be problematic considering all of the areas where this behavior could appear.

Technoturnovers commented 1 year ago

Alright, it looks like the cause of the immediate crash is cheat_manager, since I was able to get it to run on the breaking commit by compiling with --disable-cheats set, although I need to do another compile just to verify since I also had --disable-qt set from a previous attempt. I'm also going to examine the configuration menu, shader settings, and the recording feature, since those also might be a potential source of crashes from what I'm seeing as far as similar variables used (although it's possible that they have working checks against this sort of thing).

Technoturnovers commented 1 year ago

image Alright, here is what I have found so far:

EDIT: To clarify, this is with the breaking commit with just --disable-cheats and debug options set on compile.

Technoturnovers commented 1 year ago

Just at a glance, it looks like those issues might be present in earlier versions too (1.10.3, as I just tried), which is very worrying since it means that there might be a LOT more broken with this core than I initially anticipated. I wasn't able to load via menu for 1.10.3 either, only via command line. At the very least, 1.10.3 is able to list "Core: fif_libretro.so" in the core information screen, which is something.

hizzlekizzle commented 1 year ago

So, if you make a core info file for it, does that help with any of those things? Have you tried it with up-to-date RetroArch with cheats disabled?

Technoturnovers commented 1 year ago

So, if you make a core info file for it, does that help with any of those things? Have you tried it with up-to-date RetroArch with cheats disabled?

I'm going to compile the latest RA with cheats disabled soon, although I'm not sure what name my core info file needs to be, where to put it, or what parameters it needs to have in order for RA to recognize it as belonging to fif_libretro.

Technoturnovers commented 1 year ago

Alright, I determined that the core info file needs to be named "fif_libretro.info" and placed in the RA cores directory; this might be typical, but it's new to me, so I'm writing it down for reference.

Technoturnovers commented 1 year ago

fif_libretro.info:

# Software Information
display_name = "Fix-It Felix Jr."
authors = "Code Mystics, Disney"
supported_extensions = "rom"
corename = "fif_libretro"
categories = "Game"
license = "Proprietary (All rights reserved)"
permissions = ""
categories = "Game"

# Hardware Information
manufacturer = "AtGames"
systemname = "FOCAL Engine"

# Libretro features
supports_no_game = "false"
savestate = "true"
cheats = "false"
needs_fullpath = "true"
hw_render = "false"

Here's the quick core info file I made. I'll need to do more experimentation on what parameters the core supports, and I'm still not sure whether or not this core is actually deterministic or not (for some weird reason, it ports the "win32_srand" and "win32_rand" functions into itself rather than using native Linux random functions), but this makes it functional from the menu.

It does run on the latest RetroArch with cheats disabled, although the bottom status message still shows "No core". It still crashes with cheats enabled on compile, and I have yet to test whether remaps or overrides work or not with this info file in place.

EDIT: Running the strings command on the core, I noticed the string "rand_seed", so that might mean this is deterministic

Technoturnovers commented 1 year ago

Alright, even with the current info file in place, it still has trouble saving overrides and remaps, still no new information out of the console. Also, one thing to note is that the game is rendering squeezed in when it really shouldn't be- this game is 3:4 aspect ratio, and the window size is created correctly, but the placement of the frame within the window seemingly is not.

Technoturnovers commented 1 year ago

I managed to pull several AtGames firmware images- none of them full, but many containing what I believe is the original launch setup for fif_libretro. The bad news is that, if these firmware update and CFW images are to be believed, the launcher passes no parameters to fif_libretro via retroplayer (AtGame's proprietary libretro frontend) other than some control binds, which means that this core must be relying on retroplayer's defaults. I'm going to try and sus out what these retroplayer defaults are. Although this is somewhat difficult, because while this frontend actually can run on my armhf VM, it seems to expect some particular system configurations, one of which being DRM/kernel modesetting enabled (which I don't have right now). Naturally I also can't link to these firmware images cuz copyright, but I'm willing to field any questions on these too if it will help here.

Technoturnovers commented 1 year ago

Closing in favor of #15821