Tearing with frame_delay on LCD

[Dogway]

Edit: uploaded a log
As the title says, as soon as I enable frame_delay I get screen tearing (similar to this guy), I set this globally but will tune locally in the future for certain problematic games.
I think the problem might be related to the wrong detection of my monitor refresh rate, I use a DELL U2715H 2560x1440@59.950Hz, yet GM detects it as 59.000Hz.
Eventually I want to use it on my 1080p HDTV for couch gaming, so I don't know if GM stores monitor information somewhere.

GroovyMAME 0.214
Win7 SP1 x64
i7-4790K, 16Gb
GTX 1070

my mame.ini, with syncrefresh to 1 to sync game to my refresh rate.

Code: [Select]

#
# CORE CONFIGURATION OPTIONS
#
readconfig                1
writeconfig               0

#
# CORE SEARCH PATH OPTIONS
#
homepath                  .
rompath                   roms
hashpath                  hash
samplepath                samples
artpath                   artwork
ctrlrpath                 ctrlr
inipath                   .;ini;ini/presets
fontpath                  .
cheatpath                 cheat
crosshairpath             crosshair
pluginspath               plugins
languagepath              language
swpath                    software

#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory             cfg
nvram_directory           nvram
input_directory           inp
state_directory           sta
snapshot_directory        snap
diff_directory            diff
comment_directory         comments

#
# CORE STATE/PLAYBACK OPTIONS
#
state                     
autosave                  0
rewind                    0
rewind_capacity           100
playback                 
record                   
record_timecode           0
exit_after_playback       0
mngwrite                 
aviwrite                 
wavwrite                 
snapname                  %g/%i
snapsize                  auto
snapview                  internal
snapbilinear              1
statename                 %g
burnin                    0

#
# CORE PERFORMANCE OPTIONS
#
autoframeskip             0
frameskip                 0
seconds_to_run            0
throttle                  1
syncrefresh               1
autosync                  1
sleep                     1
speed                     1.0
refreshspeed              0

#
# CORE RENDER OPTIONS
#
keepaspect                1
unevenstretch             0
unevenstretchx            1
unevenstretchy            0
autostretchxy             0
intoverscan               0
intscalex                 0
intscaley                 0

#
# CORE ROTATION OPTIONS
#
rotate                    1
ror                       0
rol                       0
autoror                   1
autorol                   0
flipx                     0
flipy                     0

#
# CORE ARTWORK OPTIONS
#
artwork_crop              1
fallback_artwork         
override_artwork         

#
# CORE SCREEN OPTIONS
#
brightness                1.0
contrast                  1.0
gamma                     1.0
pause_brightness          0.65
effect                    none

#
# CORE VECTOR OPTIONS
#
beam_width_min            1.0
beam_width_max            1.0
beam_intensity_weight     0
flicker                   0

#
# CORE SOUND OPTIONS
#
samplerate                48000
samples                   1
volume                    -25

#
# CORE INPUT OPTIONS
#
coin_lockout              1
ctrlr                     default
mouse                     0
joystick                  1
lightgun                  0
multikeyboard             0
multimouse                0
steadykey                 0
ui_active                 0
offscreen_reload          0
joystick_map              auto
joystick_deadzone         0.4
joystick_saturation       0.85
natural                   0
joystick_contradictory    0
coin_impulse              0

#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device             keyboard
adstick_device            keyboard
pedal_device              keyboard
dial_device               keyboard
trackball_device          keyboard
lightgun_device           keyboard
positional_device         keyboard
mouse_device              mouse

#
# CORE DEBUGGING OPTIONS
#
verbose                   0
log                       0
oslog                     0
debug                     0
update_in_pause           0
debugscript               

#
# CORE COMM OPTIONS
#
comm_localhost            0.0.0.0
comm_localport            15112
comm_remotehost           127.0.0.1
comm_remoteport           15112
comm_framesync            0

#
# CORE MISC OPTIONS
#
drc                       1
drc_use_c                 0
drc_log_uml               0
drc_log_native            0
bios                     
cheat                     0
skip_gameinfo             0
uifont                    default
ui                        cabinet
ramsize                   
confirm_quit              0
ui_mouse                  1
language                  English
nvram_save                1

#
# SCRIPTING OPTIONS
#
autoboot_command         
autoboot_delay            0
autoboot_script           
console                   0
plugins                   1
plugin                   
noplugin                 

#
# HTTP SERVER OPTIONS
#
http                      0
http_port                 8080
http_root                 web

#
# CORE SWITCHRES OPTIONS
#
modeline_generation       0
monitor                   lcd
orientation               horizontal
connector                 auto
interlace                 0
doublescan                1
super_width               2560
changeres                 1
powerstrip                0
lock_system_modes         1
lock_unsupported_modes    1
refresh_dont_care         0
dotclock_min              0
sync_refresh_tolerance    5.0
frame_delay               1
vsync_offset              0
black_frame_insertion     0
modeline                  auto
ps_timing                 auto
lcd_range                 auto
crt_range0                auto
crt_range1                auto
crt_range2                auto
crt_range3                auto
crt_range4                auto
crt_range5                auto
crt_range6                auto
crt_range7                auto
crt_range8                auto
crt_range9                auto

#
# OSD KEYBOARD MAPPING OPTIONS
#
uimodekey                 SCRLOCK

#
# OSD FONT OPTIONS
#
uifontprovider            auto

#
# OSD OUTPUT OPTIONS
#
output                    auto

#
# OSD INPUT OPTIONS
#
keyboardprovider          auto
mouseprovider             auto
lightgunprovider          auto
joystickprovider          auto

#
# OSD DEBUGGING OPTIONS
#
debugger                  auto
debugger_port             23946
debugger_font             auto
debugger_font_size        0
watchdog                  0

#
# OSD PERFORMANCE OPTIONS
#
numprocessors             auto
bench                     0

#
# OSD VIDEO OPTIONS
#
video                     auto
numscreens                1
window                    0
maximize                  1
waitvsync                 1
monitorprovider           auto

#
# OSD PER-WINDOW VIDEO OPTIONS
#
screen                    auto
aspect                    auto
resolution                auto
view                      auto
screen0                   auto
aspect0                   auto
resolution0               auto
view0                     auto
screen1                   auto
aspect1                   auto
resolution1               auto
view1                     auto
screen2                   auto
aspect2                   auto
resolution2               auto
view2                     auto
screen3                   auto
aspect3                   auto
resolution3               auto
view3                     auto

#
# OSD FULL SCREEN OPTIONS
#
switchres                 0

#
# OSD ACCELERATED VIDEO OPTIONS
#
filter                    0
prescale                  1

#
# OpenGL-SPECIFIC OPTIONS
#
gl_forcepow2texture       0
gl_notexturerect          0
gl_vbo                    1
gl_pbo                    1
gl_glsl                   0
gl_glsl_filter            1
glsl_shader_mame0         none
glsl_shader_mame1         none
glsl_shader_mame2         none
glsl_shader_mame3         none
glsl_shader_mame4         none
glsl_shader_mame5         none
glsl_shader_mame6         none
glsl_shader_mame7         none
glsl_shader_mame8         none
glsl_shader_mame9         none
glsl_shader_screen0       none
glsl_shader_screen1       none
glsl_shader_screen2       none
glsl_shader_screen3       none
glsl_shader_screen4       none
glsl_shader_screen5       none
glsl_shader_screen6       none
glsl_shader_screen7       none
glsl_shader_screen8       none
glsl_shader_screen9       none

#
# OSD SOUND OPTIONS
#
sound                     portaudio
audio_latency             0

#
# PORTAUDIO OPTIONS
#
pa_api                    "Windows WDM-KS"
pa_device                 none
pa_latency                0.01

#
# BGFX POST-PROCESSING OPTIONS
#
bgfx_path                 bgfx
bgfx_backend              auto
bgfx_debug                0
bgfx_screen_chains        default
bgfx_shadow_mask          slot-mask.png
bgfx_lut                 
bgfx_avi_name             auto

#
# WINDOWS PERFORMANCE OPTIONS
#
priority                  0
profile                   0

#
# WINDOWS VIDEO OPTIONS
#
menu                      0
attach_window             

#
# DIRECT3D POST-PROCESSING OPTIONS
#
hlslpath                  hlsl
hlsl_enable               0
hlsl_oversampling         0
hlsl_write                auto
hlsl_snap_width           2048
hlsl_snap_height          1536
shadow_mask_tile_mode     0
shadow_mask_alpha         0.0
shadow_mask_texture       shadow-mask.png
shadow_mask_x_count       6
shadow_mask_y_count       4
shadow_mask_usize         0.1875
shadow_mask_vsize         0.25
shadow_mask_uoffset       0.0
shadow_mask_voffset       0.0
distortion                0.0
cubic_distortion          0.0
distort_corner            0.0
round_corner              0.0
smooth_border             0.0
reflection                0.0
vignetting                0.0
scanline_alpha            0.0
scanline_size             1.0
scanline_height           1.0
scanline_variation        1.0
scanline_bright_scale     1.0
scanline_bright_offset    0.0
scanline_jitter           0.0
hum_bar_alpha             0.0
defocus                   0.0,0.0
converge_x                0.0,0.0,0.0
converge_y                0.0,0.0,0.0
radial_converge_x         0.0,0.0,0.0
radial_converge_y         0.0,0.0,0.0
red_ratio                 1.0,0.0,0.0
grn_ratio                 0.0,1.0,0.0
blu_ratio                 0.0,0.0,1.0
saturation                1.0
offset                    0.0,0.0,0.0
scale                     1.0,1.0,1.0
power                     1.0,1.0,1.0
floor                     0.0,0.0,0.0
phosphor_life             0.0,0.0,0.0
chroma_mode               3
chroma_conversion_gain    0.299,0.587,0.114
chroma_a                  0.64,0.33
chroma_b                  0.30,0.60
chroma_c                  0.15,0.06
chroma_y_gain             0.2126,0.7152,0.0722

#
# NTSC POST-PROCESSING OPTIONS
#
yiq_enable                0
yiq_jitter                0.0
yiq_cc                    3.57954545
yiq_a                     0.5
yiq_b                     0.5
yiq_o                     0.0
yiq_p                     1.0
yiq_n                     1.0
yiq_y                     6.0
yiq_i                     1.2
yiq_q                     0.6
yiq_scan_time             52.6
yiq_phase_count           2

#
# VECTOR POST-PROCESSING OPTIONS
#
vector_beam_smooth        0.0
vector_length_scale       0.5
vector_length_ratio       0.5

#
# BLOOM POST-PROCESSING OPTIONS
#
bloom_blend_mode          0
bloom_scale               0.0
bloom_overdrive           1.0,1.0,1.0
bloom_lvl0_weight         1.0
bloom_lvl1_weight         0.64
bloom_lvl2_weight         0.32
bloom_lvl3_weight         0.16
bloom_lvl4_weight         0.08
bloom_lvl5_weight         0.06
bloom_lvl6_weight         0.04
bloom_lvl7_weight         0.02
bloom_lvl8_weight         0.01
lut_texture               
lut_enable                0
ui_lut_texture           
ui_lut_enable             0

#
# FULL SCREEN OPTIONS
#
triplebuffer              0
full_screen_brightness    1.0
full_screen_contrast      1.0
full_screen_gamma         1.0

#
# INPUT DEVICE OPTIONS
#
global_inputs             0
dual_lightgun             0
joystick_id_1             0
joystick_id_2             1
joystick_id_3             2
joystick_id_4             3
joystick_id_5             4

[schmerzkaufen]

Your desktop is likely set to the NTSC standard 59.94 mode, which is typically labelled as '59p'.
It's stupid but this is what most graphics card drivers are set to pick by default instead of true 60Hz.
So force your Windows desktop to 60. If it refuses then try to create a custom resolution mode of 60 in the nVidia control panel and try again.

Anyway this is not what's causing the tearing you're seeing. You should disable syncrefresh and read below.

Tearing is expected to show show when using frame_delay, to eliminate it you're supposed to use the vsync_offset setting, by setting a value corresponding to the number of lines (monitor-side) comprised between the top of the screen and where the tearing line is located.

For instance you have a 1200p panel, and see a tearing line located about 1/5th distance from the top.: set vsync_offset to 240
If it's rather 1/4th then vsync_offset 300.

Typically the lower down it is showing on the screen, the more difficult it'll be to eliminate it, in which case it is better to lower frame_delay by -1 step and try again.

...

Now the problem is that frame_delay and vsync_offset are supposed to be set for each game independently (or each emulated system at the very least).

Normally it is not recommended to set frame_delay from the mame.ini, instead you're supposed to use the featured dedicated slider available ingame at TAB>sliders>frame delay.
Play and set it to the level best fitting the game for full stability, press F11 and watch the speed% meter while playing (your frame delay setting is automatically saved in the .cfg files stored in the cfg folder)

THEN to remove the tearing create a dedicated .ini file, like for instance rtype.ini, and drop it into the ini subfolder found in the main folder.
In that file you write the vsync_offset corresponding to the game you've just set frame_delay for, like;

Code: [Select]

vsync_offset              240(you can do this for an entire system, like create a cps2.ini to apply the same offset to all games of that system, then create a sub-subfolder called 'source' in the ini one and put that cps2.ini there)

...

Sure, this is not very convenient because:
1. it takes time to configure all games
2. this is not portable to another display, if you go and use the same Groovy to your 1080p TV you will understand that the vsync_offset values you've set for 1200p are not valid anymore (you could however set two Groovy's or keep two separate ini folders that you swap when you change displays)

To simplify things if you use a single frame_delay value like 1 for ALL games, then you could maybe find a single general vsync_offset value that pushes the tearing away enough for most games.
Like if on your setup the tearing line appears on average around 1/5th from the top, then try a common vsync_offset value of +/- 240 and see how it goes.
However since the results are dependent on CPU load, it is unlikely that something like that will work satisfyingly, as the position of the tearing line will vary with each different system you emulate anyway.

IIRC Calamity mentioned he may have a way to make all of this automatic in the future.

...





ADDENDUM: Groovy's features work best when dedicated to a particular display, and specifically a display that supports custom resolutions & refreshes modes (whether it's a CRT or LCD)
The current configuration you apply is basically sub-Groovy usage, which is less optimal and more annoying than a proper configuration with custom modes.

FYI even nVidia graphics cards can use custom modes with Groovy, though to a lesser extent, and feasability depends on you monitor's ability to support custom modes to make going through the somewhat convoluted initial configuration steps that I describe below worth the trouble;

That specific configuration for LCDs is explained here: http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=374
Though it is slightly different in your case since you have an nVidia;

1. try creating a number of custom resolutions from your nVidia control panel (like 1200p@59, 1200p@58, 1200p@57 etc down to maybe 54)
- stop here and give up if that didn't work at all -
2. find your monitor's 60Hz native modeline the way explained in this thread: http://forum.arcadecontrols.com/index.php/topic,161055.msg1696360.html#msg1696360
3. go back to the LCD guide I've linked, skipping the Arcade OSD part, and resume following it down to halfway (stop before the VMmaker part)
4. done. your games will play at almost their native refresh speed (at +/-1% near accuracy, check pressing F11 while playing to see the speed which will be stable at either 99%, 100% or 101%) and smoothly.

You will still need vsync_offset though...

[Dogway]

Thanks for the help. A question, without syncrefresh how do I get the game to sync to the monitor refresh rate? Is that autosync or am I mistaken?

I found that for 1943 a frame_delay of 7 is the max value before reducing performance. It gets saved as a .cfg. My tearing happens at the top, I tested 1440/4=360 and that worked for vsync_offset. Can I overshoot the pixels or has to be exact?

I guess that for another display like a 1080p TV 1080/4 can make it, but have to test.

So the thing is to test a few systems and configure the max frame_delay value your system allows before hitting performance -F11 key- (more powerful pcb's might need lower values), find the vsync_offset which is a constant between GPU power and game resolution, and if they are within the first 480px (1440/3) from the top, use that as an overshoot value, then adapt for other displays (Res/3).


On the addendum, I'm currently using custom modelines on my HDTV for Retroarch, it took me quite an amount of time to configure with CRU and still the modelines show on my monitor despite having configured it only for the TV. The thing is, I don't want to mess with it much more, I still have to configure custom modelines for madVR so as long as I get smooth motion and low input lag on MAME I'm fine, the odd system at +/- 3Hz or more from display refresh rate (checking vsync.ini), that might need a modeline, or maybe just leave it at original rate with stutter.

[schmerzkaufen]

Thanks for the help. A question, without syncrefresh how do I get the game to sync to the monitor refresh rate? Is that autosync or am I mistaken?

Yes you only need autosync, it's basically syncrefresh but that switches automatically to triplebuffer when you're running a game that's outside the range covered by sync_refresh_tolerance (saw you put 5 there so you won't ever see it happen with that value anyway)

Can I overshoot the pixels or has to be exact?

AFAIK it doesn't need to be exact. Exact value would be hard to tell anyway. If you put too much you'll know because the tearing line will come back to say hello at the bottom of the screen.

On the addendum, I'm currently using custom modelines on my HDTV for Retroarch, it took me quite an amount of time to configure with CRU and still the modelines show on my monitor despite having configured it only for the TV.

OMG good luck with that. I hate CRU.

so as long as I get smooth motion and low input lag on MAME I'm fine, the odd system at +/- 3Hz or more from display refresh rate (checking vsync.ini), that might need a modeline, or maybe just leave it at original rate with stutter.

As long as you don't play games that are between 54 and 57Hz too often you're fine then.
Personally in cases I don't have access to custom modes I set sync_refresh_tolerance to 2.5 so everything below 57.5 gets triplebuffered, b/c I prefer choppy scrollings over a much sped-up framerate.
On the bright side Groovy's triplebuffer delays less than a 'normal' triplebuffer, something like 1 or 2 frames instead of 3.
Actually everything in Groovy lags less than baseline MAME even if you don't use frame_delay, like Calamity managed to chop off 2 frames from BGFX recently. ^^

[Dogway]

So sync_refresh_tolerance is "frames", I was asssuming percentage, therefore yes 2.5 makes more sense. Outside that the triplebuffer is automatic I guess. I will test adding one or two modelines in a few weeks with VMMaker although I didn't quite understand the variable rate as I'm not on GSync displays. I might also force 54Hz games to a 57Hz modeline in case that's possible so game doesn't speed up as much.

[Foxhole]

One thing that will probably help you reduce/eliminate tearing would be to set your power management mode to prefer maximum performance. Of course that means your gpu will work harder.
Edit: just noticed you linked to my post.
In my case, on my emulation pc, now my arcade cabinet, a stronger gpu fixed the tearing.
On my main pc i use a gtx 1070 with maximum performance set in the nvidia panel, resolution is 1920x1200, i get no tearing even with high frame delay. Higher resolutions will require faster gpu, so you might still get tearing with 2560x1440 resolution.

[schmerzkaufen]

So sync_refresh_tolerance is "frames",I was asssuming percentage

Nope, neither, it's Hz.

When you set 5 it means everything 5Hz below 60Hz (or whatever available sync hook mode) will be handled by syncrefresh, so everything down to 55Hz.
If you set 3 it mean everything down to 57Hz, and what's below that will be triplebuffered.

Some redundant rant not necessarily for you but for casual nVidia readers: When you have an AMD and Emudrivers there's no concern about that since it can deliver any exact refresh rates, but when you have an nVidia and access to only a limited number of fixed/static modes, you understand why it's better to have enough of those to avoid having to deal with too large gaps and be forced to make a choice between too fast and choppy.
IF a display can handle several custom modes (54, 55, 56, 57, 58, 59, . , 61), everything becomes much more comfortable, since autosync will always hook syncrefresh to one of the available modes and the framerate differences will therefore always be small (less than 1% deviation from the real refresh of the game)


@Foxhole: GPU performance does matter yes, in particular with flat panels since the output resolution is much greater than a CRT's and there's much more calculation to do, but AFAIK it's still the CPU that deals with most of that load.
It is much more important to get your frame_delay + vsync_offset settings right anyway, no matter the hardware performance.


NB: about frame_delay level ceiling; sometimes it feels like it's not related to hardare limitations, rather that it depends on a game. Anyway higher doesn't necessarily means better, as Calamity said sometimes too much frame_delay can be counter-productive.
Personally even if that's not verifiable besides actually playing, for a long time I've been feeling that response is generally excellent with anything above 5 anyway, which is affordable for most games assuming using a not-too-wimpy computer.

[Dogway]

Yes sorry, I meant Hz, I usually refer to frames when presented synced to display's default rate.

Anyway I gave in with the vsync_offset, I spent too much time trying to figure out the correct value, after the 3rd or 4th game (2-3h later) I quit. The tear was about 1/4 at the top of my screen, but no offset made it disappear, tested with tmnt and a few more. I will test later with Foxhole suggestion.

I will make a few modelines ajusted to Naomi and Model2, and then force MAME games with similar rates to adapt to those modelines. I understand sync_refresh_tolerance is a delta, meaning below but also above tolerance, therefor the next applies (All Killer No Filler):

Code: [Select]

30 FPS
[30.000000],archrivl,maxrpm,pigskin,powerdrv,rbtapper,tapper

50 FPS
[49.764608],stonebal,ultennis
[49.890391],cubo
[50.000000],wingwar
[50.080128],aristmk5

54.00Hz
[53.178707],su2000
[53.986864],rdft,rdft2,rfjet,viprp1
[54.001512],psychic5
[54.253472],xexex
[54.706840],mk,mk2,mk3,nbahangt,nbajam,nbajamte,openice,revx,smashtv,term2,totcarn,umk3,wwfmania
[54.824186],narc
[54.877858],fshark
[54.877858],gulfwar2,twincobr,wardner
[55.000000],dbz,dbz2,kungfum,spelunk2,spelunkr,vigilant
[55.017606],airduel
[55.017606],cosmccop,dbreed,hharry,loht,majtitle,nspirit,rtype,rtype2,xmultipl
[55.161545],outzone,rallybik
[55.407801],raiden2,raidendx

57.524Hz (same to Model2 board modeline)
[55.838470],qix,sdungeon
[56.000000],denjinmk,powerins
[56.180000],acrobatm,blkheart,firehawk,grdnstrm,gunnail,macross,macross2,spec2k,ssmissin,stagger1,tdragon,tdragon2,tharrier
[56.191350],64street,astyanax,avspirit,cybattlr,edf,p47
[56.665468],mk4
[56.747000],mustache
[57.000000],calspeed,gauntdl,gauntleg,hyprdriv,mace,sfrush,tenthdeg,terraf
[57.230000],astorm,bloxeed,ddcrew1,desertbr,lghost,mwalk,shdancer,shdancer1
[57.349016],crusnusa,crusnwld,offroadc,wargods
[57.370000],sonson
[57.400000],airbustr
[57.420000],block,pang,twineagl,zingzip
[57.430000],superman
[57.444400],madgear,midres
[57.444853],apache3,baddudes,bigfight,blockout,ctribe,ddragon,ddragon2,ddragon3,decocass,mmonkey,robocop,shadfrce,spdodgeb,vball,wwfsstar,wwfwfest
[57.445800],deroon,tkdensho
[57.500000],djboy,hyperpac,snowbros
[57.524160],bnzabros,swa,vf,vformula,vr
[57.550645],agallet,ddonpach,donpachi,esprade,feversos,gaia,guwange,hotdogst,mazinger,metmqstr,plegends,pwrinst2,sailormn,theroes
[57.613169],truxton,zerowing,zerowing1,zerowingw
[57.799650],boogwing,captaven,captavenu,fghthist,mutantf,robocop2,supbtime,tumblep
[58.000000],avengrgs,cbuster,chainrec,charlien,hoops96,hvysmsh,hvyunit,joemacr,osman,skullfng,sslam,vaportra,wbeachvl,wcvol95,wizdfire
[58.232800],blzntrnd,gunmast,skyalert,vmetal
[58.238857],cninja,edrandy

61.7Hz (same to Naomi board modeline)
[61.000000],powerbal
[61.049285],ironhors
[61.310000],aerofgt,pspikes
[61.523438],asteroid,bwidow
[61.681173],tgm2,tgm2p
[85.449219],spiders

[schmerzkaufen]

Dunno, usually when it doesn't work I decrease frame_delay by -1, the tear line rises up and it becomes easier to eliminate it with vsync_offset.
Then I create .ini's for systems instead of per-game, as it's faster that way.

But I'm using a 1920x1080 display, which means there's less load on the CPU & GPU when I use frame_delay compared to your 2560x1440.
frame_delay doesn't scale well, so the higher the target display output resolution, the more demanding.

Other things of influence:
- filter, png effects or overlays, HLSL, every time you turn one of these things on or off (especially the latter) you need to re-adjust.
- something else in the way ? a frontend could disrupt Groovy
- whatever else in W7 or the control panel ?
- could the custom modelines not actually work with the display, a resampling is applied and therefore syncrefresh is not working as expected ?

Once I've tried overclocking my CPU to see if I could get better frame_delay levels, but that didn't seem to change anything (it can't OC much anyway...)
Trying different cards gave me a variety of results, the more powerful the GPU the less apparent the tearing (doesn't mean it's gone either but almost invisble at times)
Haven't tried overclocking the GPU yet though.

frame_delay isn't ideal for high-resolution displays, how CPU & GPU specs influence the results here is not very clear.
Calamity said something like the faster the CPU the better, but how fast for what resolution ? that's not really known, too few people use Groovy with a flat panel so we haven't 'benchmarked' the feature.
Same for GPU, I said a more powerful one is supposed to be better for frame_delay... it kinda is but not blatantly so. I wonder which of the typical GPU specs really matter.
I really should investigate that side of OC some day but I need a new PSU.

[NinjaZero]

On my dedicated Windows 7 Vewlix cab with I3 6100 and Nvidia GTX 1050TI I can set Frame Delay to 6 with HLSL enabled, any more and I will get frame drops. If I disable HLSL I can hit Frame Delay of 7.  On my 1080p LCD I need to set vsync_offset of 120 to get rid of tearing.

[Dogway]

I configured max performance in the nvidia panel, I don't think it's necessary though what did it was to lower frame_delay from 7 to 6 (I have HLSL on), I was testing Superman rom, there's a camera pan at the beggining to test. Anyway I tested another rom from the same driver (vertical though) and the same settings didn't apply, if we add into the mix the resolution and graphic card variables the frame_delay and vsync_offset become a very time consuming task, specially for shaving off only one frame of input lag. Running it on or off HyperSpin also didn't make a difference, although for HyperSpin I have to disable portaudio and use direct sound.

I think it has its meaning if you are playing a handful of games the you spend most of the time on.

[schmerzkaufen]

Anyway I tested another rom from the same driver (vertical though) and the same settings didn't apply

Yeah they don't always do, performance within a same-driver varies, but with some systems (like capcom's cps) it is quite steady so you can cover all games with a couple .ini's

frame_delay and vsync_offset become a very time consuming task

Personally I got used to it and can do this rather quickly now.

specially for shaving off only one frame of input lag.

Well, depends on what you seek, using frame_delay easily provides a 1 frame gain at 1, but the more you increase the more often if becomes 2, beyond 5 it is more often 2 than 1.
In total that makes 1~0 (or 1/2 a frame or better remaining if we talk in averages) vs. the solid 3 of baseline MAME (5 w/ bgfx!).
And that's all synced and smooth without oddities like it can happen when for instance you push RA's run-ahead too far.

Sure it's heavy but once set for working with your preferences, as long as you're at 5+ frame_delay, that's still a fantastic result.

although for HyperSpin I have to disable portaudio and use direct sound.

That's too bad, personally I got addicted to Portaudio.

I think it has its meaning if you are playing a handful of games the you spend most of the time on.

For games you don't play much yeah maybe that's tad too much effort.

However, I use Groovy 'naked' (no frontend) because of all the things it combines, think about it:
- perfect refresh rates accuracy (dynamic mode w/ AMD and Emudriver)
- or 1% refresh accuracy (static mode for most games with only 7 custom modes even w/ nVidia)
- Calamity made it that some odd interlaced modes found in monitors are skipped, without that many games would show a black screen. baseline lacks this)
- perfectly smoothly synced (baseline MAME's syncrefresh isn't perfect, some hiccups remain)
- combined with Portaudio lag reduction
- saving optional overclocking sliders per game for those that play better with some tweaking (only up-to-date build to feature that)
- did I mention it's always up-to-date with base MAME ?
- even without using frame_delay it is less laggy than baseline (d3d 2fr, bgfx 3fr VS. d3d 3fr, bgfx 5fr) and 1frame is affordable with only frame_delay @1 a relatively small load)
- 4K users even get custom resolutions w/ Emudrivers, that not even the official MAD drivers get right
- even with FreeSync and Gsync it is better as no lag at all remains (baseline MAME still has 1)
- and well there's also black frame insertion but that's more for ppl playing at doubled refresh rates (that doesn't combine with fearues like frame_delay tho)

What's limited or still lacking:
- heavy (to reach at least frame_delay 5 or 6 on heavy games, on a HD+ flat panel, you indeed need a FAST processor and not-too----smurfy--- GPU. old hardware and puny laptops are out)
- only shader available is HLSL (which is endangered species since mamedev talked about removing it)
- like in baseline HLSL UI settings don't save (I think they they do in other alt builds like ARCADE tho)
- vsync_offset being entirely manual is the sticking point for users who don't want to spend nights setting up their library, Calamity mentioned that potential auto-setting feature but no clue if it'll be a thing nor when
- Groovy being starkly different from other MAME builds and RA in some crucial areas, and having a learning curve, many newcomers get in trouble and confused quick, so it's kind of an advanced-user thing by default

Anyway, looking at the positives there's no other build for playing arcades on a flat panel that's so comprehensively and tightly sticking to accuracy, compatibility, and up-to-date-ness.
I read someone saying "it's MAME done right", if he was thinking of the pure technical side I fully agree.
It's tough to get into and requires fitting hardware, but once you get it right it's a no-compromises experience, you have the best period.

I should add "well of course it's not easy and the MAME basis is spartan", but again depends what people seek.
Demanding arcades players should naturally find the motivation to get into Groovy.
Players who want a fancy emu juke box with the essentials and more, plus tons more of aesthetic shaders and frontend-like conveniences, should maybe stick with RA or the likes.