Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up --- Bug Reports --- Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: GroovyMAME 0.222 - Switchres v0.017q  (Read 226540 times)

0 Members and 1 Guest are viewing this topic.

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 615
  • Last login:Today at 08:18:05 am
  • I want a large cream coffee
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1080 on: July 01, 2020, 12:18:29 pm »
I've never bothered with vsync_offset as it's such a pain to set.
It's crucial to flat panels users, because tearing is always there on those, fixing offset so far is only possible through custom individual ini's.

That's right currently you have to exit MAME, try a value, relaunch game, again, again etc
It can take ages even for a modest roms collection
and from experience with PCs that are 'just enough' for using frame_delay, adjusting vsync_offset camuch, much more delicate and not intuitive, which can make the whole process much, much longer.

So far from all the people I've met who have tried Groovy expecting to benefit from its features on flat panels (the most out of any existing builds considering all the compatibility fixes unique to it) about 9 in 10 couldn't wrap their heads around the manual process and struggled until they gave up.

A vsync_offset slider is basically the missing pivotal feature that'll make the difference from "Groovy a complex build for a niche of high profile users", to "Groovy the MAME build that does everything the most right, no lossless BS features, anyone can use".

It's that crucial.

CPU overclock slider needs changing to actual CPU clock too!
Only just adding decimals to the slider would make it much more practical. you can see the Hz in the machine information menu.
Quote
Hit tab, adjust with arrows, hit tab, adjust with arrows - 1000x better than current adjustment method.
Assign tab to unused button, use stick/pad to adjust, that's what i do for frame_delay and othjer lsiders like CPU%
That's what should be for vsync_offset too.

The problem with a vsync_offset slider has already been explained: MAME's UI rendering is so slow that it actually affects the offset required when the slider is shown. Anyway this will be added at some point.
Explained? Sorry I never got that, or you said it in an implied manner assuming I would understand all the implications of a probably too esoteric quote for someone at my bottom-end-user level.
You should know I'm not the type that can for instance get anything from a github link and no related development news stated on the forums for like a year and a half.  :dunno
I have no idea what you're cooking with switchres and what rewriting it means or the reasons for it nor what happens in the shadows with groovy as a whole, haven't had a clue in ages because there's nothing posted here on BYOAC or anywhere else I can relate to.
Also that doesn't answer my concern about DX9 going away and seeing the sl_ider happen before that..
Not making up that, from a bottom-end user's point of view like me it's like Groovy development exists only in Zone 51, things happen but all we get is glimpses of alien material.

This happens at times using the frame delay's or CPU% sliders, it's no big deal, just exiting the menu to see how the setting value fares is as simple a button press.
And then adjust, tab slide, adjust, tab slide etc
If it's the same kind of issue and the same amount of slowdown then it already exists, it's s flaw but deosn't egt in the way of useability much if at all and having the sliders makes like 1000x times easier indeed.
if you decided against implementing a vsync_offset one because of something like that and that's why we had to wait for years...well that was a bad decision, because one even witht hat slodown issue yet available for the last two years would ahve been absolute bliss an a godsend, for me an many people.


FYI, we're rewriting the whole Switchres module in GroovyMAME, so this will be the build where you can expect to see new features in the near future.




[/quote]

GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6923
  • Last login:Today at 10:56:04 am
  • Quote me with care
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1081 on: July 01, 2020, 01:44:14 pm »
The theory is that vsync_offset, contrary to frame_delay, should be the same value for all games, since drawing a frame on the screen (a 2D bitmap) takes the same time whatever the emulated system is, so basically it's the power of your video card what determines the correct vsync_offset value. In this situation, you'd only need to set vsync_offset once and it'd be ok for all systems.

The reason why your experience is different (you actually need different values for each game) is because reality is more complex than theory, and probably frame_delay is interacting in some odd ways with vsync_offset. A possible reason is that we tend to set frame delay higher than we should.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 615
  • Last login:Today at 08:18:05 am
  • I want a large cream coffee
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1082 on: July 01, 2020, 02:43:37 pm »
Dunno why my draft post full of uncorrected crap ended uploaded, it probably happened the moment lightning hit my area and internet connection got cut lol. Even the heavens don't want me to post here.  :lol


Anyway, well I thought having a separate vsync_offset slider saving in each individual game's cfg was the point and the obvious purpose of one ? so I never even thought about whatever unique value, I know that works somewhat for individual systems but even so there are slight differences and using post-proc requires readjust.

I remember you mentioned some kind of automation which sounded insanely high-end, if that's what you have in mind, but honestly even a 'manual-only slider' to adjut per-game just like we do with frame_delay would be have been more than enough to wrap things up, then anything more advanced would have replaced that later (maybe that would have branched? dunno but if so why not if only for a few years?)

Sorry but from what you say I still don't get why that wouldn't be feasible, the cfg saving feature works like a charm after all, and managing two sliders or three is very much within anyone's reach (when estimating and editing all by .ini is almost a skill)

Oh God if Groovy has had it like a year or two ago, even an imperfect implementation with slowdowns when the UI's up, many things would have been different, and not just for me but for many people. If somehow you decided against it back then and been preparing for the better implementation instead, then again I definitely think that was a bad choice.

All I hope is that it'll happen before DX9's gone then, but even if it does it's kind of too late for the broad pool of users, RA has taken the throne, the idiot who makes ShmupArch is the new praised hero of 'accurate and low lag' emulation, or FPGA which is all the rage. Almost no one but the remaining old tiny niche dwellers care about actual MAME or Groovy now.
« Last Edit: July 01, 2020, 03:01:16 pm by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6923
  • Last login:Today at 10:56:04 am
  • Quote me with care
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1083 on: July 01, 2020, 05:13:07 pm »
That broad pool of users from the "shmup" forums are those who disable vsync anyway, so they give a sh*t about tearing and vsync_offset.

But anyway... I agree. I'm a poor sinner.

Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 639
  • Last login:Today at 02:17:44 pm
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1084 on: July 01, 2020, 05:28:51 pm »
There are no unused buttons on a cab (and I disable config shortcuts because kids), but yeah jumping in and out of the UI isnt a problem.

Always tearing on an LCD? Is that when using frame_delay? I was messing with HLSL the other day and didnt see any tearing.

And sod the mainstream. Go read the whole 222 whatsnew.txt and tell me it doesn't blow your mind the amount of effort the devs are putting in, which they do for free. RA is a piece of fluff in comparison to the heavyweight project that MAME is!

Anuskuss

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 5
  • Last login:July 10, 2020, 04:13:59 pm
  • I want to build my own arcade controls!
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1085 on: July 02, 2020, 01:43:05 am »
@Calamity Any idea why most games display the artwork just fine but Donkey Kong struggles to fill the screen? It's not a big deal but I'd like to use the full artwork and full screen if possible :)

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6923
  • Last login:Today at 10:56:04 am
  • Quote me with care
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1086 on: July 02, 2020, 01:58:56 pm »
@Calamity Any idea why most games display the artwork just fine but Donkey Kong struggles to fill the screen? It's not a big deal but I'd like to use the full artwork and full screen if possible :)

I'm not sure if I understand the issue. The option artwork_crop in GM is used to ensure that the native resolution of the game if preserved, even if this means cropping the artwork. If this is not what you want, then try disabling artwork_crop for dkong.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Anuskuss

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 5
  • Last login:July 10, 2020, 04:13:59 pm
  • I want to build my own arcade controls!
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1087 on: July 02, 2020, 05:42:04 pm »
The issue is that the game + artwork (like bezels) stretches to the whole screen (well, vertically at least) in MAME while it's kinda "zoomed out" in GroovyMAME (like when you select integer scaling in others emus and the image sits small in the center). I'll try to make a screenshot later (but it basically looks like this). Does dkong + any of Mr. Do's artworks work fine for you? If you wanna test it for yourself, set artwork_crop to 0 of course.
« Last Edit: July 02, 2020, 11:11:44 pm by Anuskuss »

R-Typer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 110
  • Last login:Today at 03:33:55 pm
  • C64 Rulez!!!!
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1088 on: July 08, 2020, 12:41:41 pm »
I see there is ongoing project on rewriting Switchres module for groovymame. Is there any release date estimate? Are we talking weeks, several months?

Not that I complain, just curious about getting new cool features.

Big THANKS for everyone involved in this huge and awesome project!!! :D

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6923
  • Last login:Today at 10:56:04 am
  • Quote me with care
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1089 on: July 09, 2020, 06:43:01 am »
The issue is that the game + artwork (like bezels) stretches to the whole screen (well, vertically at least) in MAME while it's kinda "zoomed out" in GroovyMAME (like when you select integer scaling in others emus and the image sits small in the center). I'll try to make a screenshot later (but it basically looks like this). Does dkong + any of Mr. Do's artworks work fine for you? If you wanna test it for yourself, set artwork_crop to 0 of course.

Hi Anuskuss. I don't use artwork here. Probably GM is using integer scaling for the game + artwork combination. Usually integer scaling is disabled when the resulting borders are too big. The reason why it's not happening there is imposible to guess without a log. You can always force fractional scaling by forcing -unevenstretch in a specific game ini.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6923
  • Last login:Today at 10:56:04 am
  • Quote me with care
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1090 on: July 09, 2020, 06:54:50 am »
I see there is ongoing project on rewriting Switchres module for groovymame. Is there any release date estimate? Are we talking weeks, several months?

It's not officially released yet because there are some outstanding issues with legacy cards in Windows and certain subtle things to iron out yet. It would be a matter of two weeks worth of work and testing in lockdown conditions. In the current situation I'd say a few months.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Anuskuss

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 5
  • Last login:July 10, 2020, 04:13:59 pm
  • I want to build my own arcade controls!
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1091 on: July 09, 2020, 04:47:27 pm »
Hi Anuskuss. I don't use artwork here. Probably GM is using integer scaling for the game + artwork combination. Usually integer scaling is disabled when the resulting borders are too big. The reason why it's not happening there is imposible to guess without a log. You can always force fractional scaling by forcing -unevenstretch in a specific game ini.

You're right, even though unevenstretch is set to 1 in my config (unevenstretchx and unevenstretchy don't preserve the aspect ratio), it only works by forcing -unevenstretch via command line. That's gotta be a bug in GroovyMAME, right? Using the identical config does work in MAME.



Looking at the log, SwitchRes sets these:
Code: [Select]
-rotate -noror -noautoror -norol -noautorol -keepaspect -nounevenstretch -nounevenstretchx -noblack_frame_insertion -syncrefresh -notriplebuffer -waitvsync -nofilter
It would be nice if one could deactivate SwitchRes entirely. I only use GroovyMAME for D3D9ex and frame_delay because I have no use for SwitchRes (on my LCD anyway).

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 639
  • Last login:Today at 02:17:44 pm
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1092 on: July 10, 2020, 07:42:17 am »
it only works by forcing -unevenstretch via command line. That's gotta be a bug in GroovyMAME, right? Using the identical config does work in MAME.

No. Groovy has some settings that take priority above MAME.INI. I can't find a link to the priority order at the moment but you are able to override it without needing to change your commandline.

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 6923
  • Last login:Today at 10:56:04 am
  • Quote me with care
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1093 on: July 10, 2020, 11:55:42 am »
Anuskuss,

Create a blank file called raster.ini, then place unevenstretch 1 in it (only that).

Switchres takes priority over mame.ini, but every other ini has priority over Switchres.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead or pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Anuskuss

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 5
  • Last login:July 10, 2020, 04:13:59 pm
  • I want to build my own arcade controls!
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1094 on: July 10, 2020, 04:13:59 pm »
@Calamity Okay, I think I understand it now. From this line
Code: [Select]
rng(0): 1920 x1080_60.000000p 0.000000 [integ] scale(5, 4, 1) diff(3.70, 5.19, -0.6061) ratio(8.571, 4.219)it seems that GM prefers integer scaling but only if the margin is small enough (in my case 5.19%). So now it enabled integer scaling but by using the artwork the output suddenly grows too big so it has to go from 4x to 3x. There's probably no way to know beforehand how big the output (game+artwork) is gonna be or to change the screen mid-game (e.g. when toggling the artwork) so I'm just gonna stick to the workaround. Thank you for your help!

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 56
  • Last login:July 25, 2020, 02:39:06 pm
  • I want to build my own arcade controls!
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1095 on: July 18, 2020, 09:29:11 pm »
Errm, it's been a longtime since I updated GM (last version I was using was .203).

I noticed some pages behind that "low_latency" now it's a thing even in mainline...

But... what wizardry is happening now that... I can reach full speed with FD 9 (before it would take a huge performance hit and even the pitch would change), and no matter what FD number I put I get screen tearing from time to time? I still use a PC CRT

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 615
  • Last login:Today at 08:18:05 am
  • I want a large cream coffee
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1096 on: July 19, 2020, 04:48:25 am »
The 'low latency' setting in baseline MAME is actually Calamity who managed to port something that we've been enjoying in Groovy for ages, like a decade (more or less?)
Only difference it makes for baseline MAME is that the old 1 frame discrepancy that had to do with input polling is gone, so now when using baseline with a VRR setup (or without vsync for people who still don't get that low lag vsync is Groovy's strenght) then you also get zero lag, or pcb-level lag if you prefer.
(when before MAME always added 1 more frame. I'm being redundant but deliberately b/c apparently this isn't clear at all for most ppl I've come across)

So in no way the new 'low_latency' setting Calamity coded into baseline MAME is something that can deal with reducing the full lag chain alone. It's not like baseline suddenly acquired benefits equal to the current d3d9ex and frame_delay in Groovy that have the power to shrink vsync lag along input lag to nearly nothing.

I bet mamedevs wanted to name the new option something rather impressive, so end users would misunderstand a bit (and they bloody did), be content and stop bothering devs with that topic for a while.
Or knowing their way of thinking if you ask questions the reply will be something like "About lag in MAME; see 'we' have just dealt with it. Any delay your system produces is not our business, case closed".

PS: 'getting frame_delay 9' but not telling with what ini/display/drivers etc settings...er...you know that's \(_o)/. The symptoms could mean a ton of things.
Often witnessed : ppl get a LCD or PC CRT, set up Groovy wrong and frame_delay is not actually working, there's no extra system load they can perceive (hence the easily reached 9), there is always tearing, and the lag isn't actually taken care of.
They are in fact not experiencing GroovyMAME period (and some who don't comprehend why then curse this build around)
PS2: tearing also happens when it is working (to make thing more confusing lol) but it's normal and more or less visible on screen depending on a variety of parameters (pc hardware, settings, options, display, etc) and it's meant to be dealt with using the vsync_offset setting, per-game (or per-system) using dedicated .ini files you create and drop in the ini folder. There is no way around that, people often chose to ignore that crucial part, well again skipping it is actually not experiencing GM (or nowhere near its full potential).
PS3: until Calamity & Co. are done with a long dev job they've been doing in the background, Groovy remains a build for advanced users, as it requires thorough compliance to its requirements, which are legion since they change depending on the kind of setup used/built.
PS4: don't really know where this is going, but a lot could change in a year or two, then Groovy will become MUCH more accessible. There will still be a lot to configure if you want a proper Hz-accurate CRT or LCD setup of course, but compared to the current implementation using frame_delay could become a breeze, no more struggling with manual a vsync_offset that people don't understand anyway. With that even in basic configurations (without Hz accuracy) users could finally begin to enjoy Groovy without needing to graduate from Mame-Groovy-University first.
« Last Edit: July 19, 2020, 05:09:29 am by schmerzkaufen »
GroovyMAME oddball LCD user: W7 64, viewsonic vx3211-mh, i5-4690k @4.1GHz, Rx 570, crt_emudriver 2.0b15

Dacasks

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 56
  • Last login:July 25, 2020, 02:39:06 pm
  • I want to build my own arcade controls!
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1097 on: July 19, 2020, 09:31:27 am »
The 'low latency' setting in baseline MAME...

Hm.

Yeah, okay, here's the thing: I use an old version (.203), with exact same settings, copied line by line but keeping new settings like, low_latency, for obvious reasons... and the behavior is different. If I use the same Ini in 203, it works. Now it doesn't.

So, something has changed, of course. I never had to mess with vsync_offset before, so it's set to 0. I know a "Log" would be great but... I thought it was something easier to figure out, something like "ahhh no no, since version X the thing now you need to... mess around with the Y setting. Sorry".
I don't care much about newer versions to be honest, the last one I cared was that one that Sunset Riders was fixed and.. the Namco System 22 games became more polished and got a performance increase.

Mame is getting heavier each version for emulating Tiger Handheld mini games for some years now, so... nobody gives s* about AT&T green phosphor terminals, I don't know why these guys care about that when there are tons of arcades still needing polishing, but...
it's great already, won't change much I guess.

So... I'm sorry. For anything.

**** Nvm, apparently manage to fix it by... doing... I don't know. I deleted some folders, notably the INI folder (even if wasn't being used anymore), and... cfg folders... now it works.
« Last Edit: July 19, 2020, 12:13:43 pm by Dacasks »

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 267
  • Last login:July 30, 2020, 06:41:13 am
    • Eiusdemmodi
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1098 on: July 19, 2020, 01:05:23 pm »
I don't care much about newer versions to be honest, the last one I cared was that one that Sunset Riders was fixed

Sunset Riders is not "fixed", though?

https://mametesters.org/view.php?id=03644

cools

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 639
  • Last login:Today at 02:17:44 pm
  • Arcade Otaku Sysadmin
    • Arcade Otaku
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1099 on: July 19, 2020, 01:27:12 pm »
The 'low latency' setting in baseline MAME...

Hm.

Yeah, okay, here's the thing: I use an old version (.203), with exact same settings, copied line by line but keeping new settings like, low_latency, for obvious reasons... and the behavior is different. If I use the same Ini in 203, it works. Now it doesn't.

So, something has changed, of course. I never had to mess with vsync_offset before, so it's set to 0. I know a "Log" would be great but... I thought it was something easier to figure out, something like "ahhh no no, since version X the thing now you need to... mess around with the Y setting. Sorry".
I don't care much about newer versions to be honest, the last one I cared was that one that Sunset Riders was fixed and.. the Namco System 22 games became more polished and got a performance increase.

Mame is getting heavier each version for emulating Tiger Handheld mini games for some years now, so... nobody gives s* about AT&T green phosphor terminals, I don't know why these guys care about that when there are tons of arcades still needing polishing, but...
it's great already, won't change much I guess.

So... I'm sorry. For anything.

**** Nvm, apparently manage to fix it by... doing... I don't know. I deleted some folders, notably the INI folder (even if wasn't being used anymore), and... cfg folders... now it works.

222 has an overall performance improvement worth having. And from 203-222... maybe thousands of fixes and new stuff on the arcade side.

josete2k

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 57
  • Last login:Today at 02:03:26 am
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1100 on: August 04, 2020, 10:37:41 am »
Hi, in 0.222 mame team made some changes in simpsons driver (clock and other minor fixes) can these changes affect to groovymame?

Doozer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 498
  • Last login:Yesterday at 01:54:36 pm
  • Z80 ERROR
Re: GroovyMAME 0.222 - Switchres v0.017q
« Reply #1101 on: August 06, 2020, 02:10:34 pm »

Hi Folks,

I have just uploaded the Linux GM 0.223 binary (based on 17q).

Enjoy!