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 - Input Lag tests 2019 (new method)  (Read 27213 times)

0 Members and 1 Guest are viewing this topic.


  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 28
  • Last login:January 09, 2021, 11:32:25 am
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #280 on: September 21, 2020, 08:16:00 am »
Guys, curious as to why the higher frame delay setting in GroovyMAME actually reduces lag according to the OPs tests?  Shouldnt increasing frame delay add lag?  Im obviously ignorant about something, please educate me.

*EDIT - Did some digging and understand now.  So I guess the question is, is frame delay the only option in GM to reduce input lag?  Any other tips / tricks that might help?  Ive read certain versions of Direct3D 9 such as Direct3D9 Ex have certain lag reducing features enabled by default or something?  Any clues?
« Last Edit: September 21, 2020, 10:25:36 am by Josh128 »


  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 698
  • Last login:Yesterday at 05:02:49 pm
  • I want that recipe
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #281 on: September 23, 2020, 08:05:56 am »
Groovy has been using D3D9EX for years as its default backend. You don't even have to write anything under 'video' in the mame.ini
Calamity attempted a switch to BGFX but it turned out still too laggy, so back to 9EX until further developments.

And there's no need for other lag reduction features when frame_delay's efficiency is tested and proven, with it we can drop delay down to pcb-level or close.
(in most games with few exceptions, and depending how good is your PC, of course)

edit: it could be replaced by a different method in the future, like the obscure frame_slice. who knows about the likeliness tho? not me.

If you seek to reduce even the game's built-in natural delay (breaking emulation accuracy and gameplay legitimacy though) see with RetroArch and its often nonsensitical mishmash of backends and features that include the lossy Run-Ahead.
« Last Edit: September 23, 2020, 08:26:37 am by schmerzkaufen »
GravyMOM LCD user i5-4690k @3.9GHz, RX Vega 56, W7 64, crt_emudriver 2.0b15 18.5.1
PSA: general warning regarding internet communities where emulation is an important discussion topic: freedom of speech stops where criticism of MAME and its devs begins.