Build Your Own Arcade Controls Forum
Software Support => GroovyMAME => Topic started by: Dogway on September 30, 2019, 01:34:23 pm
-
Edit: uploaded a log
As the title says, as soon as I enable frame_delay I get screen tearing (similar to this (http://forum.arcadecontrols.com/index.php/topic,149390.msg1558477.html#msg1558477)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.
#
# 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
-
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;
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...
-
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.
-
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. ^^
-
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.
-
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.
-
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.
-
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):
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
-
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.
-
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.
-
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.
-
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.