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.
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.
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]