Feature request: adding DuckStation standalone

[CometHunter92]

DuckStation standalone is preferable to the slowish and bugged libretro core (not officially supported by the author too). Will be good to try to compile an Aarch64 standalone version, to include in ArkOS, to see if it runs full speed on the 351 devices. It will basically solve the PS1 issues with the 351 devices (Metal Gear Solid, Soul Blade, R-Type Delta, Quake II, Crash Bash, Battle Arena Toshinden and other games that are bugged with the pcsx_rearmed core).

[christianhaitian]

I don't think it will work due to the qt5 requirement but I'll try and see. What issues are you having the MGS and BAT with pcsx-rearmed? I run those fine on my end with the pcsx-rearmed core updated from the repo a couple of weeks ago.

[CometHunter92]

With the libretro pcsx_rearmed core MGS has several visual glitches (for example the transistion just after the elevator is completely broken, BAT needs the PEOPS plugin to properly work (several effects don't works in the arm32 neon version). Soul Blade crashes too. Did you have build your core from the notaz repo? I heard that some glitches are corrected. However there a lot of famous games (like ISS Pro Evolution 2) that has serious problems in pcsx, being able to load a standalone version of DuckStation will be great (with no enhancements obviosly): the libretro core can run at least a full speed R-Type Delta, Crash Bash and ISS Pro Evolution 2; MGS and Soul Blade, for example, are just some frames below the full speed. If I remember correctly, Batocera has a no-gui standalone version.

[CometHunter92]

Tested more games: sadly games that worked perfectly full speed on my PS Classic (pcsx_rearmed based) don't work good in ArkOS (even in Lakka). There are a lot of stuttering, espexially at screen transutions (strange). The strange thing is that after the stutter happened, it won't repeat anymore, as a sort of "caching". If you reload the game it will reappen. Examples: first kick in a Football match in ISS Pro Evolution; selecting a car and starting a race in Gran Turismo (stucks badly at the race start); Kula World opening screen (the transition between copyright screen and menu is glitched) -> if you restart the game without closing retroarch it won't happen as badly as the firse loading (lol). It is a bug? They're happening only on the rg351: my mini classic consoles, my pi4, my PS Classic doesnt do that (and I don't think PS Classic is more powerful that an rk3326)

[christianhaitian]

What is your specific unit? If you know how to manually add/change cores, try restoring this older version of pcsx-rearmed and see if it performs any differently: https://github.com/christianhaitian/retroarch-cores/raw/4592a499af429368ee1e5737f8343fa332060600/arm7hf/pcsx_rearmed_libretro.so.zip

[CometHunter92]

I have an RG351V. Tried your old core and behave exactly like my old core. Made some videos to show you what's happening. I'd like to know if they're performance issues related to the rk3326, or something is wrong with my unit, or there are some bugs inherently to how retroarch works on this device. It happens in Lakka 3.4, 3.6, ArkOS, 351elec and stock firmware. It's driving me crazy because the stutterings and framerate problems happens only at the first "play": if you restart the race or match, the hiccups fade away. That's so so strange, like some slow storage problems: I have already tried 4 different SanDisk SDs, and even the stock ones -> same problem. Here's the videos: https://youtube.com/shorts/fN99SUZIbIs?feature=share https://youtu.be/8aP0DXJyf_8 https://youtu.be/FSC-ltCbl-c They happen on your unit too?

[christianhaitian]

Have you tried the non rumble enabled core?

[CometHunter92]

Yes. Tried a lot of cores, the last, the one you sent to me, the rumble version and a core for arm32 I compiled myself in may. My issue seems something like this one, no one answered (https://www.reddit.com/r/RG351/comments/nyao1n/ps1_games_audio_stutter_between_screen_transitions/). I wasn't expecting full PS1 compatibility, due to pcsx_rearmed core (duckstation works without issues with few games) but I always read that RG351 devices has "perfect" ps1 emulation speed. Fun fact: the duckstation core does the same stutterings in the same moments and they clean after the first "play" too. I'm thinking some problems in reading the sd cards. Did you try those games to see if your unit does the same?

[christianhaitian]

Not yet. What program did you use to flash ArkOS onto your sd card?

[CometHunter92]

Raspberry Pi imager, Win32DiskImager. Tried different times, different combinations and different sd cards.

[christianhaitian]

Did you try going to the retroarch settings menu>quick menu>options>CD Access Method>Aynschronous or precache.?

[CometHunter92]

Yes. The videos are with asynchronous option: it's the same. Tried precache with a CHD too (precache doesnt work with a bin+cue): it's the same. I'm puzzled by the fact that the stutters are only present when you first load a thing. Those devices uses some kind of cache?

[christianhaitian]

Where did you get your Sandisk sd card from?

[CometHunter92]

Some from Amazon, some from a physical shop. I don't think it's an SD problem: I use the same SDs on a Pi4 and it's all fine. Maybe the rk3326 needa some kind of "threaded rendering: async" option like in the 3ds core. Downloaded the vm image from you: I'll do a final try trying to compile a core with built_in_gpu option as UNAI renderer. Maybe half of the games needs that.

[christianhaitian]

Are you using a dual sd card setup on the 351v? If so, what file format are you using for the second sd card? If using exfat, try ntfs and see if there's any difference there.

[CometHunter92]

Yes, I'm using dual SD setup. Tried launching games from the internal SD and it's the same. I'm using exFAT with the second SD, I'll try NTFS. Allocation unit size? Some differences?

[CometHunter92]

Neither on an NTFS card. I think it's something that can be resolved, it is not like cpu related slowdowns in N64 or Dreamcast games: tried to activate the frame throttle and, aside from general slowdown (not too hard) it behaves the same: stuttering when first loading something, no more stuttering after restarting the "play", even in frame throttle. If it was a cpu related problem, it will continue to stutter with frame throttle on. Fun fact: in some games, even after shutting down the device, if you load back a save state it stutters less. What is happening? I'm not an expert: is something related to the swapfile? I checked: the ram is essentially "empty" when playing, is strange.

[christianhaitian]

One more item you can test is if you're experiencing issues with the updated screen timings. You can try the stock timings by go to the options section and select switch to original screen timings.

[christianhaitian]

You must have updated ArkOS to the 2.0 11/09/2021 version

[CometHunter92]

Eheh found the culprit. In DuckStation core, with 32 sectors of readahead buffer (213kb) the stucks are gone eheh. Too bad that DuckStation isn't full speed in many games (like Gran turismo). Doesn't work with the standard 8 sectors option (53kb) of buffer. In cdriso.c https://github.com/libretro/pcsx_rearmed/blob/master/libpcsxcore/cdriso.c <the buffer is only 4096 byte eheh. Wanna try recompile the core with 213kb of buffer?> (I'm stupid, I am tired, it isn't so straightforward) Maybe the RG351 is intrinsically a slow reading device. (P.S. it will be great to have a ~may 2021 version of the core too: many cd timing corrections of the last months solved many games issues but broken mamy others that worked flawlessy before. It will be great to have an "old fast" and a "new accurate" version of the core too eheh, I have quite a compatibility list here. Maybe we can made a "perfect" ps1 for ArkOS eheh).

[christianhaitian]

Interesting. It's an idea.

[christianhaitian]

Maybe this core build from May of this year solves the issue?

https://github.com/christianhaitian/retroarch-cores/commit/c8624fea53cf6c1f9ae4d6ca7eb67f59ea1f7aef#diff-db05b6f2b9e479f0e7be6e63a0120f2bf2b3c5f14376bf16f556c0251e6bd714

[CometHunter92]

mmm let me try

[CometHunter92]

nope, it is the same. I'm trying to compile the standalone upstream version: how to launch it from emulation station??

[christianhaitian]

you'd have to edit /etc/emulationstation/es_systems.cfg

[CometHunter92]

tried to compile some core from the chroot armhf environment you did: if I compile with "make -f Makefile.libretro" I got errors like "cpu doesn't support blabla in arm mode" when it encounters "gte.neon.S". If I compile with "./configure --platform=libretro" and then "make -f Makefile" it works, and the core works on the RG351V but doesn't have the dynarec, so it is slow (managed to compile with UNAI gpu too, that can resolve some graphic issues in some games". How do you compile the 32 bit cores for the rk3326?

[christianhaitian]

You can use scripts from here. Those that support 64bit only I've marked in the README.MD. If no particular bit is listed, it means that core or standalone can be built in 32bit or 64bit.

[CometHunter92]

Ooooh thanks! I used a different version of your script to compile. I'm experimenting: I compiled a an UNAI version and it plays finally MGS without graphical glitches and slowdowns :D. I'll tell you more but first, how to use different version of the same core and launch it from Emulationstation? For now I'm renaming one as pcsx_rearmed_rumble to launch it differently from the frontend eheh

[christianhaitian]

If it’s still a libretro core, just add another <core>corename_without_libretro</core> to the psx section of /etc/emulationstation/es_systems.cfg

[christianhaitian]

Maybe try the 1.9.14 build of Retroarch that just released today?

[CometHunter92]

Ok, I'm experimenting. Found some interesting things (like MGS full speed without visual glitches). Can I wrote here in this issue or I'm messing it up?

[christianhaitian]

Here is fine

[CometHunter92]

Ok, Gran Turismo is performing better with CPU >85 but there is still a "freeze" when starting the first race of the play session. I'm using a core compiled as: make -f Makefile.libretro HAVE_NEON=1 ARCH=arm BUILTIN_GPU=neon DYNAREC=ari64 platform=rk3326 -j4 with the device # (armv8 a35, hard point, neon based) ### # RG351

else ifeq ($(platform), rk3326)
    TARGET := $(TARGET_NAME)_libretro.so
    fpic := -fPIC
    CFLAGS += -Ofast \
    -fmerge-all-constants -fno-math-errno -march=armv8-a \
    -marm -mtune=cortex-a35 -mfpu=neon-fp-armv8 -mfloat-abi=hard
    HAVE_NEON = 1
    ARCH = arm
    BUILTIN_GPU = neon
    DYNAREC = ari64
    LDFLAGS += -static-libgcc -static-libstdc++ -fPIC`

added in the Makefile.libretro. You were compiling with Pi3 option: Pi3 is a cortex a53, rk3326 is a cortex a35, as the PSC. I managed to play MGS without graphical glitches and slowdowns with a core built with UNAI gpu, not NEON: it is a little slower, so you have to enable threaded rendering to async (sync works but a little slowdown in the end of the opening cinematic): the async option eats some frames sometimes but it runs fullspeed all the time with "perfect graphics" (no more glitches during cutscenes and slowdowns). make -f Makefile.libretro HAVE_NEON=1 ARCH=arm BUILTIN_GPU=unai THREAD_RENDERING=1 DYNAREC=ari64 platform=rk3326 -j4 Is "perfmax" on when launching PSX games? Checked the governor, max cpu speed is set to 1416 MHz

[CometHunter92]

Ok, using the core compiled from the notaz repository solve the stutterings. BUT in the libretro version of that you cannot change the psx_clock value, so I'm adding this option to obtain a smoother framerate.

[christianhaitian]

perfmax is enabled when launching psx. You should submit a PR to the libretro psx repo to have the rk3326 platform added. Until then, what's your recommendation at this point for pcsx-rearmed?

[CometHunter92]

Sorry for the late response, now that I added the option to overclock the psx cpu to the notaz repo (the libretro core) basically the emulation of the psx on the rg351 is "perfect". I have to submit some PR to the libretro and notaz repos. We can make it even better if we made some sligthly modifications more. Basically you have to choose a specific core per game and you're ok with most games. I'm kinda busy at the moment, later I'll tell you all the stuff. If you want I can make a wiki section for the psx settings for ArkOS.

[christianhaitian]

No problem. For now, I just want to use your modified compile flags. I can create a patch for it until it's upstreamed. Thanks

[CometHunter92]

Ok, basically pcsx_rearmed is kind of a "mess": you have to use specific core (+ configuration) per game, for the optimal experience (like the POPS plugins for the psp). I'm testing games and finding the right core/option combination to run them optimally. I have never pushed a PR on Github, I'm kind of a noob, if you tell me how to do it I'll do it. Per now the best is to use the Notaz upstream version for everything that doesn't need the UNAI gpu, because the upstream version for now doesn't have the threaded rendering needed to run the UNAI gpu fullspeed on these potato devices. The notaz repo has no dualshock support in the libretro version, but I've added the CPU clock option that was needed to run games with the right framerate (for now I added 4 options: default (57), PAL optimized (70), NTSC optimized (85) and max (100) (https://www.reddit.com/r/PlaystationClassic/comments/aa2d5q/finding_the_optimal_clock_speed/). Because of the no dualshock (and messy analog support) and no rumble in the notaz libretro version (we can add to it without problems later I think) it's good to keep the pcsx_rearmed_rumble version too (basically the last libretro NEON gpu version with the rumble patch, if I understand correctly). https://drive.google.com/drive/folders/1IN_J75x8DhDl8EHfnxC2h2pdi1v5pE1p?usp=sharing try these core: the libretro UNAI solves graphical issues in FF VII, No Fear Downhill, MGS (remember to use threaded rendering on sync for better performances, on MGS you need the async option for fullspeed. Try the "notaz" core and you will see no stuttering (Gran Turismo is amazing now with CPU at 100) and things like no more open polygons in Crash Team Racing. Recent cd fixes solved some issues in games like Castlevania and Medievil but introduced glitches in the music of games like ISS Pro Evolution, Ballistic etc... so I use a fourth old core (the ones from may that you sent to me). I'm writing a spreadsheet for the exact optimal core/configuration per game. Thanks for your patience.

[christianhaitian]

I tried building the notaz pcsx_rearmed core using your makefile settings for unai and make command but it fails with a EOF error on my end. Can you document exactly how you build it?

[CometHunter92]

That makefile and settings (unai gpu) are for the libretro version, the notaz repo doesn't have the threaded rendering, so it's useless with the unai for the rk3326. Later I'll send you all the stuff and the modification I made to to the notaz for using the cpu clock. I'm not goot at english so, for the cores I compiled in the drive link: libretro repo -> unai and neon notaz repo -> neon (with added option to overclock the cpu)

[christianhaitian]

I tried with the libretro repo and got the same results. I'll wait for your notes.

[CometHunter92]

I'm a n00b so, try to compile that https://github.com/CometHunter92/pcsx_rearmed with make -f Makefile.libretro HAVE_NEON=1 ARCH=arm BUILTIN_GPU=neon DYNAREC=ari64 platform=rk3326 -j4 that's forked from the notaz repo

[CometHunter92]

here's the libretro version https://we.tl/t-TgkMsPDBGO for the NEON version try: make -f Makefile.libretro HAVE_NEON=1 ARCH=arm BUILTIN_GPU=neon DYNAREC=ari64 platform=rk3326 -j4

for the unai version try: make -f Makefile.libretro HAVE_NEON=1 ARCH=arm BUILTIN_GPU=unai DYNAREC=ari64 THREAD_RENDERING=1 platform=rk3326 -j4

[christianhaitian]

Still no dice to compile on my end using the libretro repo for unai. Can you fork the libretro repo to your github, and provide your changes, confirm it compiles with unai and let me know if it works for you?

[CometHunter92]

Have you tried to compile locally the libretro version in the WeTransfer link? I'm a n00b, I forked the notaz repo and now cannot fork the libretro one, for that I put all the directory of the libretro one in that zipped file. If you want you can fork the libretro repo and upload that zipped repo. It works for me.

[christianhaitian]

I have not tried that one. Did you make your changes in it?

[CometHunter92]

Yep, that's why I uploaded it for you. I managed to fork only the notaz repo, these repos have the same name and when I try to fork the libretro one too it pushes me back because I have already one "pcsx_rearmed" forked from notaz.

[CometHunter92]

Compiled a standalone version of DuckStation with wayland. How can I try it?

[christianhaitian]

Copy it to the device, make sure to set it as executable, with a chmod 777, then see if it runs

[CometHunter92]

Ok, doesn't work, it says

ark@rg351v:/opt/duckstation$ ./duckstation-nogui
Program directory "/opt/duckstation"
User directory: "/home/ark/.local/share/duckstation"
[    0.0023] I/SDLControllerInterface: Loading game controller mappings from '/opt/duckstation/database/gamecontrollerdb.txt'
[    0.3739] E(GetPlatformWindowInfo): Unhandled syswm subsystem 0
[    0.3740] E(ReportError): Failed to get platform window info
[    0.3740] E(Initialize): Failed to create host display

Tried to launch standalone scummvm from the ssh and it worked, so...

Is it possible to launch duckstation from retrorun to get a little more performances?

[christianhaitian]

you can try it and see what you get.