Groovymame 0.261 - Switchres 2.002x

[DJO_Maverick]

Any chance we'll see that H-Freq unlock you mentioned coming in this month's update?  Maybe?  Possibly?  Pretty-please?   

*fingers-crossed*

[schmerzkaufen]

So...AMD Fluid Motion Frames support in Groovy...when ? 
Surely we can deal with ~60ms lag as long as we get doubled motion perception, right ? 

EDIT: or FSR3 Frame Generation idk. AMD like to make their new features announcements as confusing as nVidia's apparently.

FSR3FG must be implemented in a game by the devs to be used, and it uses motion vectors to generate the interpolated frames. FSR3FG can be used on any GPU.

AFMF can be enabled on any game that runs on DX11/12, doesn't need to be implemented by the devs, but that means that it can't use motion vectors, so the quality will always be worse than FSR3FG. AFMF can be used only on RDNA3.

[Calamity]

GroovyMAME 0.259 is out!

What's new in Switchres 2.002w (October 2023)

- [Linux] Added Switchres fixes to drmkms backend to properly poll dri devices.

--------------

Note: As of 0.259, baseline MAME supports fractional steps in the cpu overclocking sliders, so there's no need for our previous thing since it's officially supported now. Notice that in order to apply fractional steps you must hold the shift key while you use the cursors. Please check that everything works as intended with your previous overclock settings.

[Calamity]

Any chance we'll see that H-Freq unlock you mentioned coming in this month's update?  Maybe?  Possibly?  Pretty-please?   

*fingers-crossed*

If you mean the pixel clock upper limit, unfortunately that's needs an important modification to the AMD adl backend. I'd like to say it should be addressed soon but I can't promise it.

[schmerzkaufen]

Thanks ! 

[RobeeJ]

Thank you Calamity!!

[DJO_Maverick]

If you mean the pixel clock upper limit, unfortunately that's needs an important modification to the AMD adl backend. I'd like to say it should be addressed soon but I can't promise it.

Thank you.  Looking forward to it, I think it's about the only thing keeping this monitor from its full potential.

For the moment, I've been messing around and finding kind of arbitrary 18:16 desktop resolutions that are just low enough to allow switchres to function correctly for refresh swapping, and then letting the display upscale it...  not ideal, but, seems like the least-bad option?

[Milsancho]

Is anyone else with oldish CPUs noticing performance issues with recent Groovymame versions?

My card is an R7 200 series for a 15khz display and I can't get for the life of me full speed when I set frame_delay at 1 on relatively elementary games like Truxton or the Neogeo with a dual core Pentium G3258 at 4.2ghz, and I refuse to believe that's not enough for stuff like that! I'm not even using superresolutions and the only options I touched were the port audio settings. Am I wrong (and obsolete, lol)?

[Recapnation]

In old versions, previous to the existence of fame delay, the emulation speed was assumed to be perfectly constant, so syncaudio was a good compromise to deal with situations where the speed was slightly (or greatly) off 100%, provided it was a constant value. This tipically happened when running vertical games such as 1942 or galaga on a horizontal monitor. The pitch was lowered as a trade-off.

Now, since the introduction of frame delay, it's become common to have "erratic" speed rates, even if just in a few situations. These speed drops cause annoying pitch variations. If these cases are common, it's a better compromise to dissociate audio from video, and just maybe just cope with an sporadic sample underrun that will probably pass unperceived.

Other sources of these speed fluctuations may be the actual apis used for timing in C++, that might be changing their behaviour over time and provide bad measurements on certain hardware. This would explain some appearently random speed flutuations on otherwise perfectly capable hardware.

For all these reasons I think nowadays it's better to leave syncaudio disabled. You'll just notice crackling when speed can't follow the original like with vertical games on horizontal monitor and progressive modes, that you can bypass by lowering -syncrefresh_tolerance.

Maybe it's normal behaviour? Your CPU should be fine.

[Milsancho]

Indeed the games speed fluctuates eventually between 98 and 102%, depending on the game, and only with frame delay on (no matter if at 1 or at 7). Sometimes it goes down to 94% for a moment. Doesn't happen at all with other games, usually older.

I tested it with an older Groovymame (previous to v0.220) and it doesn't happen, so I wonder if it's now a normal thing (or non-important stuff related to the apis as you posted)? Windows 7 and d3d ex (video auto) here.

Thanks.

[Recapnation]

94 % sounds like a bit too much. Are you displaying games for vertical monitors on a horinzontal set-up? Post a log, in case.

- From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

[donluca]

Is anyone else with oldish CPUs noticing performance issues with recent Groovymame versions?

My card is an R7 200 series for a 15khz display and I can't get for the life of me full speed when I set frame_delay at 1 on relatively elementary games like Truxton or the Neogeo with a dual core Pentium G3258 at 4.2ghz, and I refuse to believe that's not enough for stuff like that! I'm not even using superresolutions and the only options I touched were the port audio settings. Am I wrong (and obsolete, lol)?

Cpu should be alright, although... only 4.2Ghz?
When I had it for my GroovyMAME box, I had mine hitting 4.8Ghz with two cores and 5Ghz on one core.
You must have been really unlucky with the silicon lottery :/

[RobeeJ]

When this happens to me it's usually because I've set the config to somehow not use any hardware video acceleration so the CPU is doing all the upscaling.

[Milsancho]

Cpu should be alright, although... only 4.2Ghz?
When I had it for my GroovyMAME box, I had mine hitting 4.8Ghz with two cores and 5Ghz on one core.
You must have been really unlucky with the silicon lottery :/

Do you mean that the CPU should be alright even at 4.2ghz or that I should o'c it even more to be good enough? I'm not sure it'll be safe if I do it with mine, which I got second hand after reading here it was good for Mame, though not in a recent post.

When this happens to me it's usually because I've set the config to somehow not use any hardware video acceleration so the CPU is doing all the upscaling.

Well, I'm testing without any scaling involved, or so I hope. I'm using a CRT and the native resolution. Unless you mean the card config? I haven't even installed anything aside from Emu Driver, so other than Windows resolution manager, I can't tweak much.

Anyway, here's a log.

Average speed: 99.94% (59 seconds)

I used Truxton as it's likely the one I get more speed fluctuations with. To make sure it has nothing to do with scaling, I set the native 3:4 resolution and orientation. This is with frame delay at 2, but it doesn't matter if it's at 1 or at 7 as I mentioned. With this game, I also get speed fluctuations according to Mame's display with frame delay at 0, though a bit less.

Aside from adding some resolutions when launching VideoModeMaker, I followed the guides without touching mame.ini much. The log says also this though: Direct3D: HLSL initialized and I have hlsl_enable at 0, not sure if that's normal?


-With Groovymame 0260 from the github, in case the log isn't noting this.-

[donluca]

Do you mean that the CPU should be alright even at 4.2ghz or that I should o'c it even more to be good enough? I'm not sure it'll be safe if I do it with mine, which I got second hand after reading here it was good for Mame, though not in a recent post.

Your CPU should be plenty, I was just pointing out that the G3258 generally OC much higher.
By going higher with the OC, it will give you better performance in 3D titles and will allow you to push frame delay further.

[Calamity]

GroovyMAME 0.261 is out!

What's new in Switchres 2.002x (December 2023)

- [Linux] Add new option -dri_device. Use to force vsync on a specific gpu, e.g. "card0", "card1", etc., or "auto" for automatic selection (currently it will pick the first device with a valid connector.

- [Windows] Raw input improvements. Workaround for devices with buggy drivers. PlayStation triggers hack removed. Should now be compatible with most existing gamepads. [star69rem]