50 Hz core override partly taken into account with manual override

[bidinou]

Trying to get a butter smooth 50 Hz scrolling - with a screen that does support 50 Hz and 100 Hz modes, with a default at 144 Hz (and does deliver a butter smooth scrolling with a MiSTer FPGA) -- I use Disposable Hero to test its horizontal scrolling.

• when using a core override containing this single line "video_refresh_rate = “50.0”, the horizontal scrolling is a bit jerky / inconsistent and DOES have tearing. In RA, for some reason, the vertical frequency is "0" (but the detected screen frequency is 50). Also, I had to disable frame delay otherwise the sound would get trashed (which doesn't happen in other frequencies)

• when adding a 100 Hz override... The screen is still switched to 100 !

• when manually switching my desktop to 50 Hz (or 100 Hz), starting RetroArch, and "applying" the current screen rate, the scrolling is slightly scrolling and there is no tearing -- actually, it feels very similar (if not exactly the same) to what I get when leaving my screen at 144 Hz

I'm using KDE Neon / based on Ubuntu 20.04 / snap packages. I tried tons of settings combinations to no avail. Cheers :)

[sonninnos]

I can only speak for Windows, which can deliver 100% perfect scrolling at 50Hz, but as much as I know, in Linux the desktop rate has to be changed first, as in automatic rate switching via video_refresh_rate and SET_SYSTEM_AV_INFO only works with Windows.

Frame delay also works here fine, so these can't be core problems only, or at all, since I think the core is already doing everything it possibly can regarding rates n stuff.

[bidinou]

Well, I'm dropping the towel, I've tried tons of combinations etc. (OpenGL / Vulkan / X / Wayland / tons of options etc) during about 5 hours ;). In both 50 Hz and 144 Hz modes it feels equally "almost smooth" with constant micro-stutters. (and with the core override, there is no vsync). (that is to say, if feels smooth for a fraction of a second, then it feels as if the horizontal scrolling "made a jump" of several pixels then smooth again etc)

I cannot enable Freesync unfortunately (not supported by my Vega 8 with no Display Port output) Do you know Linux users successfully getting a smooth 50 Hz output ?

For some reason, I feel no micro-stutters in 60 Hz cores even when my screen is set to 144 Hz (or any other native stuff). Also, when using FS-UAE, even at 144 Hz, which obviously is not optimal as not a multiple of 50 Hz, there are no such micro-stutters - it actually feels smooth & consistent. (and it's perfect in 50 Hz but well, it has tons of input lag and no great shaders support etc :)

Thanks so much for taking the time to reply :)

[bidinou]

As a side note, the jerkiness is less obvious in other games... I tried a couple of ADF games instead of my Whdload Disposable Hero : it doesn't feel "super butter smooth" but there are no "hiccups / micro-stutters".

[bidinou]

OH MY ! I found another strange thing. When running the floppy disk version of Disposable Hero, there is no such micro stutter ! (in 50 Hz)

[bidinou]

I've summed those strange results in a RA forum post : https://forums.libretro.com/t/puae-50-hz-multiple-issues-core-override-whdload-game-vs-floppy-one/35717

To sum up, I did find a way to get it working but that's a bit over complicated as I have to use floppy disk version of the game, and have to manually switch the desktop frequency and apply it globally in the RA video settings. Even more complicated as I have to do strange things to get disk swapping working as you know :)

At least I'm making progress !! :)

[sonninnos]

I have no idea how that could be the core's fault. I have no difference between Disposable Hero versions, as in scrolling is smooth with CD32 and WHDLoad versions.

Again debug log will tell something.

[bidinou]

Hi, here are my 2 first debug logs. One with the floppy version and the other with the whdload version ! Floppy = butter smooth Whdload = stutters

Please let me know. Probably too verbose ?

https://easyupload.io/m/7cjuex

In both cases : desktop set to 50 Hz and 50 Hz set in the global options (because when using the core override, I lose vsync !!!!)

[sonninnos]

Ah, I know what you mean now, it is game/slave specific and it only happens with Cycle-exact A1200/68020, so if you need Cycle-exact, use A600/68000 instead. Otherwise Normal CPU seems to work also with A1200.

Floppy versions launch A500, and WHDLoad versions launch A1200 by default if not stated otherwise, AGA etc.

[bidinou]

Hi, thanks a lot for your reply ! So it means, cycle exact A1200 induces different video timings ? Could it work better by altering the vertical frequency (not exactly 50.0 Hz), or is it something more subtle like setting the right pixel clock ? Or having some horizontal integer scaling ?

Just guessing, all this is beyond my understanding ;-)

[sonninnos]

No, those kind of timings are correct. It is something game/slave/emulation incompatibility related, nothing else. It is not 68020 directly, since CD32 version with Cycle-exact does not judder either. So there must be some kind of extra waits added to the WHDLoad slave to more suit faster Amigas.

Oddly enough the CD32 WHDLoad version also has no judder with CE, but it does not have any music either..

The current CPU emulation code which is also very old, so Cycle-exact 68020 is not as accurate as current WinUAE, where it does not happen with the same config. Just use non-CE or A600 setup for now.

[bidinou]

Thank you for your reply !! :-)

Okay, I give up on cycle exact for the moment. "Better" setting will probably be good enough for the time being :)

Remaining issue is the following : I'd like the 50 Hz mode to be applied only by the PUAE core. It's almost there :

in myPUAE.cfg file, I have video_refresh_rate = “50.0” when starting the PUAE core, my monitor DOES switch properly to 50 Hz. In the RA/video settings, the monitor display rate is displayed properly. But the current rate is set to "0.0 Hz". (So it disabled the VSync actually.) I have to manually set it to 50 Hz and, tadaaa, butter smooth tear-free scrolling. But I have to do it each time.

Any idea ? cheers ! :) regards

[bidinou]

Some news. That's beyond my understanding but finally I got a satisfying result.

As you know I have a simple puae.cfg core override with the 50 Hz vertical frequency which was taken into account at least partly because indeed it did trigger a monitor frequency change -- but the frequency in RA was "0.0".

I tried to regenerate the core override from the RA GUI, it overwrote the puae.cfg file with the "0.0" value. I changed it back to "50". And now. IT WORKS.

To sum up : when I manually created the core override it was half taken into account ! I guess I can report this upstream ?

HOWEVER it only works with the SNAP packages it seems. Because with the FLATPAK ones, this is the other way around. The override is taken into account as the current core freq. but the monitor doesn't switch. Unless I'm overlooking something.

Edit : last thing : I have to close manually the core if I want my monitor to be switched back automatically to its native 144 Hz.

[bidinou]

I'll close the issue soon, as my problems were due to RA itself and not Libretro, after all ! (apart from the strange cycle-exact Disposable Hero timing issue)

[bidinou]

I filed this upstream : https://github.com/libretro/RetroArch/issues/13273

[sonninnos]

Graphical issues in Disposable Hero are now gone!

[bidinou]

Oh, thank you for those accuracy improvements !