PUAE 50 Hz multiple issues (core override, whdload game vs floppy one)

[bidinou]

Hi ! I’m encountering tons of strange issues when attempting to get a proper butter smooth 50 Hz scrolling on my setup (3200G / Vega 8 machines / amdgpu / 144 Hz screen / KDE Neon based on Ubuntu LTS / snap or flatpak packages / both Vulkan & OpenGL / every possible settings combinations attempted :).

I have no problem with non-Amiga cores. With the Amiga core

1. if I set a 50 Hz core override with a single line specifying a 50 Hz mode, sync to VBL is not applied anymore (cannot force it !) and I get horrible tearing

2. if I set it manually on the desktop, I also have to set in the general RA options (but then it’ll be applied to all cores, grrr !)

2a) even so, when starting a game, for instance, Disposable Hero in WHDLOAD mode, the scrolling is not smooth ; it’s inconsistent and gets micro-stutters

2b) HOWEVER when starting the very same game with the same core, same options etc. but in floppy disk mode, the scrolling is butter smooth !!! (a bit blurry but I think it’s normal)

I spent quite a few hours to pinpoint ths, ahah, it’s really strange !

My question is : how to get it to work consistently, even in whdload games, and how to automatize the 50 Hz switch so that other cores do get the needed frequency ?

Thanks a lot

Edit : bugreport here : https://github.com/libretro/libretro-uae/issues/471

[bidinou]

Okay, so, after investigating and with the help from the puae core maintainer I came to this set of conclusions :

1. core override is only partly applied when created manually. I have to create it from the GUI, otherwise, despite its containing the very same line in the very same file (video_refresh_rate = “50.000000” in PUAE.cfg), it trigger a monitor frequency change but the “0.0” freq. is still displayed as the RA core current freq.

2. My Disposable Hero test case triggers jerkiness when I use the WHDLOAD version + cycle exact A1200. No problem with cycle exact A500, no problem with the CD32 version, no problem with “normal / more compatible CPU”. So there is a subtle timing related issue causing stuttering in 50 Hz…

3. I cannot get my monitor to automatically switch to 50 Hz with the Flatpak version of RA but it does work with the SNAP version of the packages.

Finally, I got this working perfectly. Yes !

(tiny remaining issue : monitor doesn’t switch back to my native 144 Hz if I don’t close the core manually)

I guess I can still file a couple of bugreport regarding those remaining little issues.

[RealNC]

Doesn’t your 144Hz screen support freesync? That’s the best way to run RA. It will then take care of proper 50Hz support. (Or whatever the core in question is using.)

If not, then it might be better to use 100Hz instead of 50Hz, and set VSync swap interval to 2 in the RA video sync options.

[bidinou]

Thanks for your reply Yep, would be ideal if I could use Freesync but unfortunately my Vega 8 doesn’t support it over HDMI. As for the 100 Hz, for some reason, when I request it I get 99.something and it’s not perfectly smooth. Oh. Maybe I should try it again after altering the VSync swap. Gonna try again

PS : do you know if there is a way to ask RetroArch to restore the desktop freq. after quitting ? My desktop is 144, I use 60 or 120 in general settings and 50 in the UAE core… So if I quit RA with the Amiga core loaded, the desktop remains at 50 Hz and i fI close the core before my desktop is kept at 60/120 but not 144. OK I can make a simple script

[bidinou]

Hmm… Trying to reduce latency, someone suggested to use a Wayland session and disable VSync in single buffering mode. For some reason, there is no tearing (while there is tearing in single buffering under X).

Is it to be expected ?

However, I have a little issue. Under Wayland, RA doesn’t switch the screen refresh rate. Setting a custom refresh rate per system is taken into account by RA but the screen resolution doesn’t follow it. (while it does work under X).

Any idea ? Should I file a bug ?