GroovyMAME 0.264 - Switchres 2.220b

[totozero]

Hi, glad to see a new build is out Calamity, thanks man !

I'm a bit confused with these 2 options :

- New option -[no]syncaudio: Make audio synchronization (resampling) optional. Default is enabled. Disable to avoid sound wobble with erratic emulation speeds (like that caused by frame delay on some systems).

Is the resampling needed in case you output a game to its native frequency ? Should I leave it off or on with an arcade monitor ?

- New option -[no]autofilter: Make auto filter optional. Default is enabled, so GM will apply bilinear filtering when fractional scaling or an interlaced mode are used.

I almost dropped my coffee cup when I saw bilinear filering. Wait, what ? Has it been always applied on horizontal fractional scaling and you added the choice to disable it, or is it a new feature !?
Interlaced I get it but with progressive what's the purpose besides adding some butter on the screen ?

Again thanks for the hard work

[Calamity]

I see the new options are not being understood. These options, as the description says, just make optional one behaviour that previously was forced.

The idea is that now you can control all the stuff that GM sets automatically, instead of having to do ini overrides, with these options:

-autosync
-autostretch
-autofilter

And optionally, use -syncaudio to control audio synchronization associated to -syncrefresh, that previously was always on. This has been a long time request, now it's here. If the target refresh is matched, audio synchronization is probably not required in most cases, since the tiny mismatch (there will always be one) won't probably be audible.

With regards to -autofilter, this filtering was forced on GM 227 (pre SR2), then it was dropped completely, then I've recovered it but made it optional. Super resolutions won't be filtered because they're treated as integer scaling.

[schmerzkaufen]

Still investigating the 59Hz issue and indeed, the 'modern' Radeon software completely hands the control of desktop modes to Windows, but the two don't speak exactly the same language and where Windows sees 60Hz, Radeon is stuck at 59.94 and there is no way, even switching back and forth, to set the desktop to 60Hz again.

GroovyMAME's SR and my monitor's built-in software, as well as most games I have, aren't mistaken as they really see 59.94

I'm still looking for a way to fix that but it seems I will have to uninstall the AMD drivers, and either re-install and then don't try allow_hw_refresh again until I find a way to bring back true 60Hz, or install an older version of Catalyst which features the old-fashioned resolution controls.

EDIT: wrote a warning in my previous post.

EDIT: note that full use (allow_hw_refresh + lcd_range) is not affected of course, this way all required modes are picked and effectivly matching the games as they should.
The issue really happened when using allow_hw_refresh alone without setting LCD range, making it seek modes within the narrow 59.94~60Hz available, and for unknown absurd reasons Radeon decided that 59.94 should be the default desktop refresh now, and if I had complaints I needed to talk to Windows...but the latter of course denied the issue like "what are you talking about? me, Im seeing 60Hz period")

[Calamity]

@schmerzkaufen,

If this mode override was created by the -allow_hw_refresh option, then it should be simple to remove it. Launch vmmaker (it doesn't matter if you're using official drivers), settings->video card->delete all modes from driver.

You may need to restart Windows.

[schmerzkaufen]

Yay that worked! thanks.

Didn't have to restart Windows btw.

PS: gonna keep an eye on it, see if it ever happens again I'll notify about it.

[Calamity]

One of the reasons this option is disabled by default, it's that if GM crashes for some reason, it won't be able to handle cleanup on exit. Then you may need do the cleanup manually.

[schmerzkaufen]

Yeah I'll remember that, when you guys update the guides threads or whatever new written for SR2 Groovy, you might want to add that VMmaker wipeout button reminder.

But seriously, AMD handing such elmementaery controls to Windows, what sort of messed up age do we live in? tsk tsk...

(I've missed which version of Catalist the switch from the previous software-UI was changed to the current terrible 'radeon software', but this is silly. Until recently even Intel somehow abandoned their own iGPUs simplistic control panel, handing all controls to Windows. but that didn't last too long and they've brought back their new in-house control panel - which is honestly better than the old and even features custom resolutions - So yeah even Intel for the sake of their puny iGPUs, were smarter than AMD here. Welp.)

[Calamity]

The Radeon settings app I have here has a custom resolutions section in the screen tab, it's from 2020 appearently.

[schmerzkaufen]

Yeah mine too, but unlike the previous (likely the one you're using and the one still featured in AMD's FAQ screenshots) the current doesn't let you pick whatever custom resolution to set it as the desktop's.

Which is exactly what I did until about last year with both the Vega 56 and RX 570.

But with today's UI nope. They'll tell you to 'go to windows display settings and make sure its set to the resolution and refresh you want'.

And you can bet that doesn't work right, it never really did even long ago. On my W8 laptop it's the same story, 59Hz or 59p mode is like a magnet, all software and OS these days are permanently waiting for an opportunity to set the desktop to that mode, as long as it's a 'HDTV' resolution they're detecting.
Except on W8 I still somehow have the power to force back 60.

In any case, handing elementary, essential controls to Windows, was never a good idea, never will be...

[schmerzkaufen]

Hey another 'bug' to report.

I dunno if it's related to my previous issue and action, but after that I went back to full allow_hw_refresh + lcd_range 50-75, and tested the same games I usually do, then I've noticed Xexex (JAA) was now running @ 59.25Hz or something. 
I mean from MAME's POV, which for some reason wasn't reading the correct original refresh for that game anymore.

Had a hunch, went and erased xexexj.cfg

-> that fixed it.

EDIT: so, going back to testing the asynchronous mode, I am again getting variable results.
Note that in any case SR(0) picks 59.939 instead of 60, even after I've cleaned up and have the desktop back to proper 60.

I still don't know the reason for this, but in short I have experienced the asynchronous mode in two flavours;
1. super choppy
2. super smooth (possibly smoother than even what the old triplebuffer was able to produce)

¯\(°_o)/¯

EDIT: and in fact async mode's inconsistent results, may or may not, be related to that strange 59Hz obsession SR seems to have, I dunno.
If I ever find what affects async's smoothness I'll let this thread know, of course, but for now I have no clue.

EDIT: going back to 227sr1, its triplebuffer mode suffers the same 59.939 obsession.
Checking Radeon after rebooting Windows: it's indeed back to 59.9394, which wasn't appearing a minute ago.

EDIT: last update for now because it's a bit draining, but yeah no matter what since the first occurence, the 59.939 mode is the only one Groovy 227sr1 and 232 want to see as being the desktop's, even after wiping out modes with VMmaker, it comes back.
Even, in 'normal' mode with default settings, syncrefreshed games like async/triplebuffered, are hooked to SR(0) 59.939 like a 60 desktop mode never existed.
And restarting Windows after playing either Groovy, shows that the desktop is actually back to 59.939.
 

EDIT: Fresh AMD install after proper cleanup with their utility. Fresh GM232 install. Fresh log. At that instant the desktop mode is @60, no attempt to use allow_hw_refresh has been made since the cleanup and resintall of everything.
Looks like there is no 'pure' 60 mode available. Yet the first time I've used 232 I could swear it was seeing the desktop at 60, and it's after trying things with allow_hw_refresh that 60 was gone...

[Calamity]

I don't understand the issue you're reporting. Your log after a fresh install shows this:

AMD ADL timing "1920x1080_60 67.431000KHz 59.938667Hz" 148.350000 1920 2008 2052 2200 1080 1084 1089 1125   +hsync +vsync

That's the mode the driver is reporting. Maybe it's grabbed directly from your monitor's EDID, can't say.

The integer refresh that Windows reports is misleading. The exact timing is very unlikely going to be exact 60 Hz regardless of what Windows says.

[schmerzkaufen]

Maybe my monitor's EDID been changed yes, I don't know what happened and don't know how to explain that absence of real 60.

The integer 60 is indeed false, and reported by both AMD software and Windows.

I don't understand either, I have reset my monitor as well. Maybe I'll try that again. (EDIT: nope that did nothing)

PS: also tested 232 on my laptop (W8.1, nvidia 880m + iGPU 'optimus' -> no issues)

Maybe the current AMD driver is garbage. I'm going to try an older one, same as yours maybe.

[Calamity]

Anyway, I don't think that particular issue has any link to the odd stuttering you were getting. From GM's point of view, 59.94 is as good as 60.00.

[schmerzkaufen]

Yeah so the source of that particular issue is likely different indeed.

But I have to fix that lack of actual 60Hz before looking into that again. I'm downloading Adrenalin 18.5.1, we'll see.

EDIT: welp, same story with 18.5.1 

Could allow_hw_refresh have edited my monitor's EDID somehow ? I'll see if I can manually re-install its drivers.
EDIT: nope that did nothing.


HOWEVER, since I have now the old Adrenalin UI, I am getting back direct control of desktop resolution via the custom ones, which unlike the in newer AMD software's, can apply directly to the desktop.
And the result is as seen in the new attached log.

We have a partial answer, the AMD software likely cannot find an integer 60Hz on my setup by itself, not until I actually force one using a custom desktop mode, which is impossible in the newer/current AMD software.

[Calamity]

Could allow_hw_refresh have edited my monitor's EDID somehow ?

No, that's absolutely impossible. Frankly, I think you never had an exact 60 Hz mode. And it doesn't matter at all.

[Calamity]

We have a partial answer, the AMD software likely cannot find an integer 60Hz on my setup by itself, not until I actually force one using a custom desktop mode, which is impossible in the newer/current AMD software.

Well that makes sense, when you've seen 60 Hz it's probably because you were using an override. If you check the new log, it shows a pixelclock of 148.50, vs your previous 148.35 that likely comes from your monitor, in an attempt to match NTSC refresh rather than 60 Hz.

[schmerzkaufen]

Frankly, I think you never had an exact 60 Hz mode. And it doesn't matter at all.

No I definitely did and have experienced enough applications where a difference between 59.94 and 60.00 was crucial, as the former would introduce stuttering.
Really until maybe a day or two at the furthest I can swear sevral games and emus were reporting proper 60, but today I've seen that change, so something definitely happened.

AMD, Crosoft and whomever always attempted to introduce the argument that it doesn't matter, but oh boy how wrong they are.

Also I see plenty of reasons why this is a problem with MAME games assuming we really want them to match to an actual clean 60Hz mode for those that are concerned.

Until I find a method to force a real integer 60 using the current Adrenalin, I'm staying away from it (which is kind of a bummer since I don't know if that affects the actual PC games performance)

Well that makes sense, when you've seen 60 Hz it's probably because you were using an override. If you check the new log, it shows a pixelclock of 148.50, vs your previous 148.35 that likely comes from your monitor, in an attempt to match NTSC refresh rather than 60 Hz.

I wasn't using an override since I couldn't do that with the current AMD soft anyway, again until recently all was fine and actual 60.

Maybe a sneaky update introduced something disruptive, I dunno.

PS: an that's another argument in favor of fixed, dedicated setups for emulation.

PPS: I like that nothing can fool SR though, while everything else made by the big names fails to see reality.

[schmerzkaufen]

So after finally making sure I could compare in ideal and identical conditions, I can now state the following;

I can hardly see any difference at all in motion quality, between the old triplebuffer and the new asynchronous mode.

(can't say if they're identical lag-wise though, d3d9ex's triplebuffer 'cost' was supposedly 2 frames but that was never confirmed with hard testing figures, so anyway if asynchronous is the same then all that remains is to play enough to compare and confirm they're at least as responsive)

Any difference in 'smoothness' I've experienced before, the brutal hiccups while comparing triplebuffer and asynchronous, though I can't explain why those happened, must have been because of what I went through with the drivers issue, or mis-configuration.

Note I've crashed 227sr1 a couple of times. Dunno why.

Conclusion for now it's the Most Perfect GroovyMAME and MAME ever been period...MK.II 



(of course saying that within context I'm focused on flat panels use and Windows now, but I guess most CRT users must think something equivalent for what concerns the primary dimension of Groovy, and the progress of its Linux alter-ego)

[b4nd1t0]

thanks @Calamity

[schmerzkaufen]

Probably stupid question but: was there ever a need for keeping super_width at 2560 even if you're a fixed matrix / flat panel user like me ?
I have a 1920 wide panel, wouldn't I save a bit of GPU time for frame_delay if I was using that instead ? or even less ? or no super width at all ?
Or nope it's not directly related to the video output and I too, need it to be 2560 period ?

[wolfsoft]

I tried gmgroovymame_0232.002b_win-7-8-10 on a fresh installed windows 10 prof System (19.Mai.2021 21H1 Build 19043.1052)
and got a Exception access_violation when running it.

I tried gmame 0.227 and it works.

Any hint for me?

See attached error message.

Many thanks and GO ON! groovymame rules!

[fred92]

Hello,


i have compiled my own no nag version here if interrested.

[wolfsoft]

@fred92
thanks for your effords but got the same error with your version.

I tried a fresh new install of windows 10 and used the "newer" Emudriver based on Adrenalin 18.5.1
(CRT Emudriver & CRT Tools 2.0 beta 15 (Adrenalin 18.5.1 for GCN cards) for Windows 10 64-bits)
instead of
CRT Emudriver & CRT Tools 2.0 beta 15 (Catalyst 12.6) for Windows 7810 64-bits

And with the emudriver for Adrenaline 18.5.1 groovymame 0.223b is working :-)

[Calamity]

GroovyMAME v0.233 is out!

[Calamity]

Probably stupid question but: was there ever a need for keeping super_width at 2560 even if you're a fixed matrix / flat panel user like me ?
I have a 1920 wide panel, wouldn't I save a bit of GPU time for frame_delay if I was using that instead ? or even less ? or no super width at all ?
Or nope it's not directly related to the video output and I too, need it to be 2560 period ?

Setting super_width at 1920 on your setup would force horizontal scaling as fractional for all games. You might see a small picture degradation in cases where integer scaling would be picked otherwise, just maybe not noticeable. I don't know whether this would have an impact on GPU load, I'd say it won't.

[benimaru7]

Hi Calamity, thanks for your efforts on Groovymame it’s such a great piece of software.

I’m not sure if you could check on your setup, but running a Neo Geo game in AES console mode such as Fatal Fury 2 results in broken audio, well it plays but like it’s been very downsampled! Running the same game in MVS results in crystal clear audio. I’ll pull a log for you, but just wanted to check if you had the same issue?

[schmerzkaufen]

Interesting, thanks!

[Calamity]

So after finally making sure I could compare in ideal and identical conditions, I can now state the following;

I can hardly see any difference at all in motion quality, between the old triplebuffer and the new asynchronous mode.

(can't say if they're identical lag-wise though, d3d9ex's triplebuffer 'cost' was supposedly 2 frames but that was never confirmed with hard testing figures, so anyway if asynchronous is the same then all that remains is to play enough to compare and confirm they're at least as responsive)

I can say I did saw differences when the refresh gap is small enough but since this is the situation where you'd force syncrefresh anyway I don't think it's a concern. The new implementation is definitely more robust and less hacky if that matters.

With regards to the latency, we have the same problem as with triplebuffer where GILT will fail the test after a second or two due to uneven framerate. But I can see that the latency is definitely 0.5-1.5  frames (7-25 ms) by the readings I get before it stops, so the value fluctuates within that range fast as the 2 independent frame rates interact. Which makes sense when compared to the figures we get with syncrefresh/frame delay.

[schmerzkaufen]

Indeed, since you've released it I could also tell by playing more of the sub-57Hz* games I'm most used to, that it performs about the same delay-wise.
You have really saved that feature which - if minor and not related to Groovy's primary purpose - is a convenient and unique lifesaver for a number of users who will be glad it's still there when they need it. 





* Personal choice already redundantly stated but; on a system where I cannot benefit from dynamic resolutions, I usually set sync_refresh_tolerance to 3.0 so it limits sync'd acceleraction to 105%.
(or 2.771 if desktop is in "59Hz" a.k.a "59p" mode. Man if only we had a 1-click button for like "force true 60.00Hz desktop showing both your stupid gfx card drivers and Windows who's boss", i have really experienced many times that it's not a given. btw I think the last Adrenalin version to let the user set a custom mode as desktop was 19.10.1)

[psakhis]

@Calamity, thanks for this great version! 

These changes i have noticed with new switchres version:
 - "noues" (abbreviation for unevenstretch 0) not working anymore BUT isn't necessary with new switchres version, now all neogeo games (304x224, 288x224, etc.) are centered perfectly!!
 - "ror" argument isn't necessary now for non-rotate vertical games on horizontal monitor, but "rol" argument is needed for rotate vertical games on horizontal monitor

Very happy with switchres 2.0

 

[Calamity]

GroovyMAME v0.234 is out!

Note: Due to this modification to baseline MAME, now -keepaspect works slightly different with super resolutions (-unevenstretchx). This change should be transparent to GM users as long as -autostretch is on.

If you notice any regression (0.233 vs 0.234) regarding aspect ratio handling please report.

[RobeeJ]

Thank you Calamity!!! 💜

[R-Typer]

 

[Endprodukt]

Can someone confirm booting problems with Carnival King and GTFore06 and the like?

It will hang itself on the bootscreen (initialization), then switching the DIP for video to low and back to medium and resetting will make the games boot. Kinda weird.

[Sociopathos]

Ok, so I just gave this 234 build a try, and noticed there's tearing at the top of the screen. On previous versions, I only had it when Frame Delay was on. but now its happening even when its disabled. Im using a PC CRT with no Crt_emudriver installed. Does anyone knows how to solve this? Thanks in advance.

[feltz]

Hello, was attempting to save a mame config, and i get an exception.
Running GM 0.235 on Windows 10 x64

Caught unhandled 25options_warning_exception exception: Illegal boolean value for keepaspect: "48"; reverting to 1

[DaddyLongLegs]

I noticed after downloading the newest groovymame that mame.exe is no longer named mame64.exe (it used to be). Is there no longer a 64 bit version of groovymame?

I also noticed CORE SWITCHRES OPTIONS was removed from the mame.ini. I still have it in my old ini. Should I keep it there or remove it? Was this feature removed from groovymame or something?

[Calamity]

It's the 32-bit build the one that's gone, that's why now the exe is no longer named mame64.exe but just mame.exe, it's still 64 bits. The correct .ini is the one provided with my package, take that one and just modify the options that you need.

[DaddyLongLegs]

It's the 32-bit build the one that's gone, that's why now the exe is no longer named mame64.exe but just mame.exe, it's still 64 bits. The correct .ini is the one provided with my package, take that one and just modify the options that you need.

Thank you as always.

I am using a Wells Gardner standard res monitor, k7x series with Atom-15 and crtemudriver.

In the groovymame's mame.ini, what is the difference between monitor generic_15 and monitor k7000?

Which one am I better off using? Does groovymame actually do something different between the two options?

[Calamity]

GroovyMAME v0.235 is out!

What's new in Switchres 2.002c (September 2021):

- [Windows] Fixed bug that caused games using interlaced modes run at dobble speed.