GroovyMAME 0.264 - Switchres 2.220b

[rogerxyz]

Resolved with GM 0.253


Hi Calamity et al,

Great work on GM 0.252 and Switchres! Unfortunately I have to report an issue I'm having. I upgraded my windows 10, ATI R9 200, 15khz cabinet from GM 0.248 which was having no issues to 0.252, and I am experiencing an unhandled exception 100% of the time:
Exception at EIP=00007fff3023a060 (not found): ACCESS VIOLATION
While attempting to write memory at 00007fff3023a060

Full logs and ini attached. I reverted to 99% stock mame.ini including my custom modelines (though these did not work either). I tried the auto and ati backends.

When I launch a rom directly, interestingly enough, GM will switch to a proper modeline, run the game, and I only receive the exception when exiting gm. However, when launching into the gui via mame.exe, I get the exception and crash before GM switches modes. I believe I can rule out the romset (merged 0.252) as running the same rom on my main PC with switchres set to 0 is fine.

I am using crt_emudriver 2.0 beta 15, I haven't updated the driver since setting up the cab 1-2 years ago as I'm trying not to break anything that's already working, but I understand if this might be related.

If I can be of assistance collecting any additional information let me know. Thank you for your endless work on this project, I truly appreciate it!

Roger

[Robbbert]

I don't know about GroovyMAME, but standard MAME 0.252 has many bugs and crashes a lot. Perhaps you should wait for 0.253 and see if the situation has improved.

[MK3FANATIC]

There have been changes upstream that may have broken that, some fixes have been pushed after 0.252 release already. So hopefully things will be back to normal on 0.253.

MAME 0.253 released and the issues were fixed, working normally. Waiting for GM 0.253

[Calamity]

GroovyMAME 0.253 is out!

What's new in Switchres 2.002r (March 2023)

- Improve rendering of UI frames and lines in low resolutions. [Oomek]

- Correctly apply rotation after modeline adjustment (using the geometry sliders with rotated games now works).

- Correctly apply syncrefresh (it wasn't applied automatically since v_scale was changed from int to float).

[pakoman]

Thanks!

[b4nd1t0]

Tnanks

Inviato dal mio EML-L09 utilizzando Tapatalk

[RobeeJ]

Thank you Calamity! 💜

[rogerxyz]

Excellent work as always!

I can confirm with GM 0.253 the issue I posted earlier with GM 0.252 is resolved. Success!!!

[Jonny G]

So as I understand things from my own experience with attempting to compile 0.253 and a few posts on the MAME support forums, It is no longer possible to build an arcade only .exe using the subtarget option. I've also seen that B4nd1to who usually posts his custom builds here has stopped offering that particular option.

I seem to remember this happening for a while many, many, releases ago, but I cannot remember the fix. Perhaps it involved removing entries for the mechanical cabs, etc from the source files. Does anyone know a temp. workaround to sort this for now in the hope this change isn't permanent? 

Thanks

Jon

[makya]

So as I understand things from my own experience with attempting to compile 0.253 and a few posts on the MAME support forums, It is no longer possible to build an arcade only .exe using the subtarget option. I've also seen that B4nd1to who usually posts his custom builds here has stopped offering that particular option.

I seem to remember this happening for a while many, many, releases ago, but I cannot remember the fix. Perhaps it involved removing entries for the mechanical cabs, etc from the source files. Does anyone know a temp. workaround to sort this for now in the hope this change isn't permanent? 

Thanks

Jon

I believe you can make mame.lst to include only games you want. Then it will compile what's required to run those games only.

[Robbbert]

The subtarget option still works. All that's happened is instead of the devs keeping arcade.flt up to date for you, you have to do it yourself.

[Jonny G]

OK, well that's a positive. I used to use MAMECompiler64 and obviously that has a GUI so it's just been as easy as ticking a box for me to build an arcade only .exe. Any tips on what to do with arcade.flt please?

Thanks!

[Calamity]

OK, well that's a positive. I used to use MAMECompiler64 and obviously that has a GUI so it's just been as easy as ticking a box for me to build an arcade only .exe. Any tips on what to do with arcade.flt please?

Thanks!

Grab the arcade.flt file from a previous version, put it in src/mame, then:

Code: [Select]

make SOURCEFILTER=src/mame/arcade.flt
It will fail since a couple of files have been removed or renamed between 252 & 253. So edit arcade.flt and remove those lines and try again.

[Jonny G]

Grab the arcade.flt file from a previous version, put it in src/mame, then:

Code: [Select]

make SOURCEFILTER=src/mame/arcade.flt
It will fail since a couple of files have been removed or renamed between 252 & 253. So edit arcade.flt and remove those lines and try again.

Thank you so much Calamity, seems to have worked!

[crispux3]

Groovymame 0.239 - Switchres 2.002g can run with a crt_emudriver 12.6!
switchres_ini             1
and edit switchres.ini
api                       powerstrip
thats run perfect 240p & perfect refresh

If
    switchres_ini             0
   switchres_backend   powerstrip
thats only  480i,but perfect refresh

It's basically not working, unless you have Powerstrip installed, which is a nonsense. Please don't use 12.6. It's only there to support pre-HD 5000 cards.

unfortunately this card only 12.6 can installed

Oh,I edit C7299900.inf,change the card from "%AMD9802.1%" = ati2mtag_Wrestler, PCI\VEN_1002&DEV_9802   to    "%AMD9802.1%" = ati2mtag_Legacy, PCI\VEN_1002&DEV_9802.and crt_emudriver_&_tools_2.0_beta_15_16.2.1_W.7.8.10-64_nieg installed successfully!
above is no needed,only edit C7299900.inf,add AMD9802.1 = AMD Radeon HD 6310 (CRT Emudriver)" in ;;; KFD
all is ok,also can use Csync

I just received HP laptop with HD 6310 in it. I know how to edit file C7299900.inf, but where do you put the above line: AMD9802.1 = AMD Radeon HD 6310 (CRT Emudriver)" in ;;; KFD in the file itself?

What is the exact line that I need to put in the file and where do I actually put it (as it's a long file of information)? Thank you.

[schmerzkaufen]

MAME 0.254 brings that new improvement to the Cave CV1000 blitter delay code, this will be a great time !

I believe games will still require some adjustments contrary to Vas's statement, and therefore still have an use for the saving sliders, but with this it'll be the best way to do it and play those games so far.
Can't wait for this Groovy (and b4nd1to's) 

[b4nd1t0]

MAME 0.254 brings that new improvement to the Cave CV1000 blitter delay code, this will be a great time !

I believe games will still require some adjustments contrary to Vas's statement, and therefore still have an use for the saving sliders, but with this it'll be the best way to do it and play those games so far.
Can't wait for this Groovy (and b4nd1to's) 

if the groovy patch remain to "r" i can try to compile it today

[schmerzkaufen]

Not that much in a hurry though lol. we can probably wait a bit see what Calamity & Co. do this month 

EDIT: it looks like they have removed the both switch and slider for Blitter Delay, if so that's quite the confidence they have in the recent improvement I must say.
IIRC the author was not as radical in his statement regarding how much his new code improved on the matter.
This is slightly scary in that it smells like one of those 'good-enough, lets seize the opportunity to remove some old stuff period' mamedev moments, without much investigation if any.
Welp, time will tell.

In Groovy we should at least still have control over the CPU%, which from what I could gather around is still necessary for CV1000 anyway.

ED2: it's fine the author himself is behind it, found on shmups;

Tuning the CPU underclock can work as somewhat of an approximation of the actual pcb behavior, but theres not going to be an exact value thats best. With the Blitter slider (that this code removes) it was way worse though. The Blitter delay code prior to this had pretty much nothing to do with how things work on pcbs, so tuning it to specific values made no sense really.
That said, until proper wait state support is implemented for the cpu, picking some cpu value that feels mostly right is probably close-ish at least.

[Calamity]

The build is in the oven, should be ready in a few hours if github is happy.

EDIT: it looks like they have removed the both switch and slider for Blitter Delay, if so that's quite the confidence they have in the recent improvement I must say.

From what I could read, the blitter delay behaviour is now correctly understood and implemented, so the slider is worthless at this point. There's another source of delay in the SH-3 cpu wait states. This can't be emulated easily since MAME uses its dynamic recompiler for this cpu, otherwise it wouldn't be possible to emulate these games at full speed, as it was the case before Haze implemented it a few years ago.

[schmerzkaufen]

The build is in the oven, should be ready in a few hours if github is happy.

From what I could read, the blitter delay behaviour is now correctly understood and implemented, so the slider is worthless at this point. There's another source of delay in the SH-3 cpu wait states. This can't be emulated easily since MAME uses its dynamic recompiler for this cpu, otherwise it wouldn't be possible to emulate these games at full speed, as it was the case before Haze implemented it a few years ago.

Ah yes we've seen the topic mentioned here and there over the years, IIRC correct wait states for a lot of emulated hardwares would require a complete change of a massive part of MAME so it's a pipe dream, or something for the far future.

So games like those are getting close to the best they'll ever be emulated in the existing MAME at the very least, which is already damn awesome.
If we get gameplay results that don't pale - or even best - console ports, then there's only reasons to celebrate.

I gave this new code a try and indeed we can see some of the expected slowdown behaviour pop up during gaming without us having to randomly seek hypotetical 'working' blitter delay values anymore.
CPU underclock is still needed though, but that's only one slider left to deal with. Good ! 

PS: even that will eventually become obsolete, not yet but little by little. Like, some time ago Dark Seal's sound was fixed, and recently Garou's messed up background animation since the CPU is more accurately emulated now.

[Calamity]

PS: even that will eventually become obsolete, not yet but little by little. Like, some time ago Dark Seal's sound was fixed, and recently Garou's messed up background animation since the CPU is more accurately emulated now.

The long-awaited M68K wait states emulation was added by OG in previous release, this is what fixed Garou (and probably many other timing derived bugs). Since M68K is used almost everywhere in arcades, this is a truly major leap in emulation accuracy.

[schmerzkaufen]

Ah so that's what happened ? makes sense seeing the effect that had. Sounds like a milestone indeed.
I guess it's something that can be done for at least a part of MAME's already established hardwares without a major rewrite of like a third of MAME's code globally lol.

EDIT: take that MiSTer ! hmph. you're nothing special. 

[Calamity]

GroovyMAME 0.254 is out!

What's new in Switchres 2.002s (April 2023)

- Fix popup error with custom preset (switchres: error trying to fill monitor range with).

[Robbbert]

GroovyMAME 0.245 is out!

Er, don't you mean 0.254 ?

[Sociopathos]

PS: even that will eventually become obsolete, not yet but little by little. Like, some time ago Dark Seal's sound was fixed, and recently Garou's messed up background animation since the CPU is more accurately emulated now.

The long-awaited M68K wait states emulation was added by OG in previous release, this is what fixed Garou (and probably many other timing derived bugs). Since M68K is used almost everywhere in arcades, this is a truly major leap in emulation accuracy.

Yeah, too bad its not applied on the Cps1/2 drivers, so Sf2 Hyper Fighting is still too fast.

[Calamity]

GroovyMAME 0.245 is out!

Er, don't you mean 0.254 ?

Corrected, thanks.

[makya]

GroovyMAME 0.254 is out!

What's new in Switchres 2.002s (April 2023)

- Fix popup error with custom preset (switchres: error trying to fill monitor range with).

Many thanks Calamity!

[donluca]

GroovyMAME 0.245 is out!

Er, don't you mean 0.254 ?

We're going back, Marty!

[schmerzkaufen]

Noice, thanks for the new build!


PS: I went back to my old LCD monitor (non-VRR) and tried to use allow_hw_refresh again, set lcd_range 50-75, and for a while it seemed to work well as it did before.
Today I'm using W10 and a 6650 XT.

But then I must have touched something I shouldn't have, dunno how as I wasn't meddling with anything related to sync, and now it refuses to work anymore, no more correct refreshes. 

Please Calamity remind me of the required settings for that particular feature ? I can never remember every time I go back to using it and there's nothing written about it (well, somewhere deep down the forums I cannot find anymore). Here's how I'm set for now;

Code: [Select]

# OSD FULL SCREEN OPTIONS
#
switchres                 1
switchres_ini             0
switchres_backend         auto
modesetting               0
modeline_generation       1
monitor                   lcd
interlace                 1
doublescan                0
super_width               2560
changeres                 1
lock_system_modes         0
lock_unsupported_modes    0
refresh_dont_care         0
dotclock_min              0
h_size                    1
h_shift                   0
v_shift                   0
v_shift_correct           0
pixel_precision           1
sync_refresh_tolerance    2.0
interlace_force_even      0
autosync                  1
autofilter                1
autostretch               1
screen_compositing        0
screen_reordering         0
allow_hw_refresh          1
modeline                  auto
ps_timing                 auto
lcd_range                 50-75
crt_range0                auto

[Calamity]

But then I must have touched something I shouldn't have, dunno how as I wasn't meddling with anything related to sync, and now it refuses to work anymore, no more correct refreshes. 

No, it's a bug. It must have been introduced with latest Switchres api internal update. I'll fix it when I have some time.

[schmerzkaufen]

Ah ok this has been driving me mad for hours lol. 

Me for these past 20 years, every time I believe I finally have my hands on the ultimate MAME build of my dreams :

[RobeeJ]

But then I must have touched something I shouldn't have, dunno how as I wasn't meddling with anything related to sync, and now it refuses to work anymore, no more correct refreshes. 

Does it run way too fast? Mine has been doing this since 253, I wasn't sure if it was GM or an Arch Linux update so I was just turning off switchres. Didn't want to bug Calamity about it until I was sure it was GM, and also because I use an LCD which isn't quite the target audience I felt a little guilty mentioning it.

[Calamity]

Does it run way too fast? Mine has been doing this since 253, I wasn't sure if it was GM or an Arch Linux update so I was just turning off switchres. Didn't want to bug Calamity about it until I was sure it was GM, and also because I use an LCD which isn't quite the target audience I felt a little guilty mentioning it.

So your issue is also with the lcd monitor preset, right?

[schmerzkaufen]

Does it run way too fast? Mine has been doing this since 253, I wasn't sure if it was GM or an Arch Linux update so I was just turning off switchres. Didn't want to bug Calamity about it until I was sure it was GM, and also because I use an LCD which isn't quite the target audience I felt a little guilty mentioning it.

Nah it's just that the expected effect of the feature (running at correct refresh output) doesn't trigger anymore. Dunno which version introduced that bug though.

Note if need to repeat at least for some readers ; that allow_hw_refresh works for a few compatible flat panel displays, which you can only know by trying, and of course requires an AMD card.
Since I own a couple monitors with which the feature works I've been enjoying that, it basically provides the Groovy experience (smooth correct refresh and lag reduction) practically at the flick of a switch, no need for emudrivers nor any complicated set up.
So it's not for everyone but absolute gold when it works. 
(haven't tried it with CRTs yet but it'll come, in any case for the many who don't own any CRTs nor VRR setups and have a basic flat panel and AMD gpu lying around, if not a pretty phosphor image* it means at least correct gameplay at zero cost and effort)



*PS: though we're limited to D3D in Groovy which means flat panel users only have ye olde HLSL if they want an imitation of CRT, with time I've come to learn tame it better and find reatively decent settings that work well-enough for the general use. HLSL may feel obsolete and unintuitive these days compared to some other shader chains performing a more convincing imitation, but hey flat panel peasant aren't 100% butt naked lying in the dirt using GM.

*PPS: I won't talk about the software BFI feature since I don't know how to use it properly, got improper results on so I'm not sure it works and last time I tried my high-refresh capable IPS monitor displayed persistent flickering for a while, even if after just a couple minutes. This monitor's got its own strobing feature working better but way too dark. So, if there's one aspect flat panels still won't compensate even reasonably for vs. CRTs, it's very much that: motion. Until we get something like nVidia's frame generation but for retro emulators I'm not touching this again lol.

[RobeeJ]

So your issue is also with the lcd monitor preset, right?

Yes, correct! Works fine if I turn off switch_res, problem began in 253 I think.

If I was to describe the symptoms, some games run way too fast, and others like Contra have very noticeable sound slurring.

Note if need to repeat at least for some readers ; that allow_hw_refresh works for a few compatible flat panel displays, which you can only know by trying, and of course requires an AMD card.

Strangely the only affect this had for me was make GM eat 100% CPU rather than 15% 🤷‍♀️

[Calamity]

Keep calm, the issue with the lcd preset is simple to fix, I introduced it accidentaly trying to fix something else.

I'm happy to learn that some people are using the lcd preset haha.

[schmerzkaufen]

Oh I got it that it's not a big issue. 

BTW the 'LCD' preset isn't suspected to even exist, I guess. It's the one I've used the most goes without saying, but it felt lonely there.

Since the 'GroovyMAME is dedicated to CRTs' slogan is the only put forward, very few ppl know that it is also at the same time the most advanced MAME build for flat panel displays.
The CRT focus statement as I've seen even has adverse effects like I've read things like 'uh better not use Groovy if you dont have a CRT' or 'avoid because it is too esoteric if youre not a CRT connoisseur' kind of 'advice' certainly from non-users. 
There are sadly too many examples of how ill-known and misunderstood this build is. Same goes for the topic of lag I've kept an eye on it and today ppl are still globally confused about it (we gotta thank RA and YT snake-oil salesmen for that).
Even witnessed some braindead mofo once on a discord server saying frame_delay actually increases lag, I recommended him to quit smoking bizarre things, what can we do though really...
A lot of unaware ppl could have benefited from Groovy so many years, but in these internet-ruled times bullsh*t and prejudice always win. Welp. 

[Zebidee]

Y'know, most people (meaning people with mame cabs or interest in retrogaming) don't even know the difference between "Groovymame" (application) and "CRT_emulator" (driver)... so the confusion is understandable. The name does have "CRT" in it. Is just that not everyone is as clever and knowledgeable about such matters as enlightened persons like us.

I have occasionally had fun explaining the difference to people, that Groovymame is cool, essentially a "better mame", and can work on VGA & even LCD, it really depends on what the display can do (and the PC's ability to keep up), and watch their jaws drop as realisation dawns. If they still don't get it, well then at least persistent ignorance can be entertaining.

Now that I've dispensed wisdom, Ima gunna sit back in my armchair, grab a whisky and light up my pipe.
 

[Calamity]

This should fix the lcd_range issue:

https://github.com/antonioginer/GroovyMAME/releases/tag/gm0254sr002t

[schmerzkaufen]

Indeed it does ! 
Purrfect once again. Thanks a lot.

Must say, ain't it a shame in regards to VRR tech that I get actually even more perfect smoothness with Groovy's own implementation ?
Not kidding; either with FreeSync or G-Sync I see a faint hiccup once in a blue frame (very rare but it happens).
But GroovyMAME stays absolutely smooth at all times, would I spend scrutating scrolling backgrounds for hours. Flawless.

My newer monitor features WQHD and 170Hz VRR (free/Gsync compatible) and is faster, brighter, so it should be better, right ? Yet my older featureless slower, dimmer, glossy Full-HD 50-75Hz somehow makes the experience better, and the perfect scrollings smoothness is the cherry on top.