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 Try the site in https mode Site News

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

  

Author Topic: GroovyMAME input lag is still faster than MAME  (Read 3202 times)

0 Members and 1 Guest are viewing this topic.

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
GroovyMAME input lag is still faster than MAME
« on: July 02, 2022, 05:50:51 pm »
I was doing some input lag tests and need some help from the experts here.

As far as I was aware, all the GroovyMAME input lag improvements were back ported to MAME several months ago. Am I correct in saying that stock MAME should now have the same input-lag as stock GroovyMAME?


In my tests stock MAME is actually 1 frame slower than stock GM.

I know the Frame Delay feature is exclusive to GM and improves input lag even more. (I measure an extra 1 frame improvement with Frame Delay set to 6).


Here is what I have measured:


SUPER STREET FIGHTER 2
MAME: 6 FRAMES
GROOVYMAME with DEFAULTS: 5 FRAMES
GROOVYMAME with FRAMEDELAY 6: 4 FRAMES

BUBBLE MEMORIES
MAME: 4 FRAMES
GROOVYMAME with DEFAULTS: 3 FRAMES
GROOVYMAME with FRAMEDELAY 6: 2 FRAMES

METAL SLUG
MAME: 7 FRAMES
GROOVYMAME with DEFAULTS: 6 FRAMES
GROOVYMAME with FRAMEDELAY 6: 6 FRAMES (no improvement?)


JACKAL
MAME: 6 FRAMES
GROOVYMAME with DEFAULTS: 4 FRAMES (two frame improvement over MAME?)
GROOVYMAME with FRAMEDELAY 6: 3 FRAMES (this is faster than the PCB and MISTER...)


Definitely GM input lag is still faster than MAME by at least 1 frame and 2 frames with "frame delay 6". Are there more code changes that could be back ported to put MAME on par with GM?


« Last Edit: July 02, 2022, 06:06:44 pm by flybynight »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7414
  • Last login:April 10, 2024, 02:02:31 pm
  • Quote me with care
Re: GroovyMAME input lag is still faster than MAME
« Reply #1 on: July 03, 2022, 10:28:57 am »
Make sure your mame.ini has the option -lowlatency enabled (it's not by default in the official build).

I don't know how or what you're measuring exactly (if it includes the monitor's lag, the game's built-in lag, etc.)

If it's just the bare input lag, it's very bad. With GM + frame delay you get sub-frame latency on a CRT (not considering game's built in lag).
« Last Edit: July 03, 2022, 10:30:54 am by Calamity »
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 of pasting it.

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

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #2 on: July 03, 2022, 11:04:11 am »
Awesome. Will try that parameter in mame and test it out will report back the results.

I wonder why mamedev does not enable lowlatency by default?


I'm using a slow-motion camera and led light hooked up to player 1 button 1 on the super gun. Camera points at the screen and records at 1000fps. I'm just counting the frames between the led light change and the sprite reacting to the button press. In slow motion you can see the crt gun scanning the glass top to bottom and is easy to count the frames.


Groovymame with framedelay 6 is the same as PCB. Faster in some cases. Although as you say, it's possible to be out by a frame depending on if the button is pressed at the start or end of a frame (subframe).

Great job calamity!

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #3 on: July 03, 2022, 06:02:45 pm »
Hi Calamity, I did some more testing with official mame this time setting lowlatency 1. I didn't measure any change at first. However when I also change
"video auto" to "video d3d9ex" then I get the same as groovymame (of course without the "frame delay" improvement).

Is that expected? Does "video auto" in mame default to bgfx and is bgfx a frame slower than d3d9ex? I tested setting "video bgfx" and it measures the same as auto:

Here is the updated measurements:

SUPER STREET FIGHTER 2
MAME: VIDEO AUTO, LOWLATENCY 0: 6 FRAMES
MAME: VIDEO AUTO, LOWLATENCY 1: 6 FRAMES
MAME: VIDEO BGFX, LOWLATENCY 1: 6 FRAMES
MAME: VIDEO D3D9EX, LOWLATENCY 1: 5 FRAMES
GROOVYMAME with DEFAULTS: 5 FRAMES
GROOVYMAME with FRAMEDELAY 6: 4 FRAMES (Same as PCB)

BUBBLE MEMORIES
MAME: VIDEO AUTO, LOWLATENCY 0: 4 FRAMES
MAME: VIDEO AUTO, LOWLATENCY 1: 4 FRAMES
MAME: VIDEO BGFX, LOWLATENCY 1: 4 FRAMES
MAME: VIDEO D3D9EX, LOWLATENCY 1: 3 FRAMES
GROOVYMAME with DEFAULTS: 3 FRAMES
GROOVYMAME with FRAMEDELAY 6: 2 FRAMES (Same as PCB)

METAL SLUG
MAME: VIDEO AUTO, LOWLATENCY 0: 7 FRAMES
MAME: VIDEO AUTO, LOWLATENCY 1: 7 FRAMES
MAME: VIDEO BGFX, LOWLATENCY 1: 7 FRAMES
MAME: VIDEO D3D9EX, LOWLATENCY 1: 6 FRAMES
GROOVYMAME with DEFAULTS: 6 FRAMES
GROOVYMAME with FRAMEDELAY 6: 6 FRAMES (no improvement? I'll record this one again) (MVS PCB is 5 Frames)


JACKAL
MAME: VIDEO AUTO, LOWLATENCY 0: 6 FRAMES
MAME: VIDEO AUTO, LOWLATENCY 1: 5 FRAMES
MAME: VIDEO BGFX, LOWLATENCY 1: 5 FRAMES
MAME: VIDEO D3D9EX, LOWLATENCY 1: 4 FRAMES
GROOVYMAME with DEFAULTS: 4 FRAMES
GROOVYMAME with FRAMEDELAY 6: 3 FRAMES (this is faster than the PCB and MISTER...) (PCB is 4 frames. A Pi running this game through a Pi2Jamma is 9 Frames).

BAD DUDES
MAME: VIDEO AUTO, LOWLATENCY 0: 4 FRAMES
MAME: VIDEO AUTO, LOWLATENCY 1: 4 FRAMES
MAME: VIDEO BGFX, LOWLATENCY 1: 4 FRAMES
MAME: VIDEO D3D9EX, LOWLATENCY 1: 3 FRAMES
GROOVYMAME with DEFAULTS: 3 FRAMES
GROOVYMAME with FRAMEDELAY 6: 2 FRAMES (PCB is 1 frame.)


I can post the video captures if interested.
« Last Edit: July 03, 2022, 06:27:06 pm by flybynight »

buttersoft

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1758
  • Last login:March 22, 2024, 12:55:20 am
  • Is running at 15kHz
Re: GroovyMAME input lag is still faster than MAME
« Reply #4 on: July 03, 2022, 07:10:11 pm »
Always interested to see results of tests like these, thank you for posting!

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME input lag is still faster than MAME
« Reply #5 on: July 04, 2022, 09:13:02 am »
- Video 'auto' uses d3d9ex by default (unless that has changed but I haven't noticed)

- IIRC the way frame_delay acts, when it is effective (input caught the right moment), then there is no actual lag left besides the game's inherent one (= the pcb's), so it is zero, or maybe there's a little of the GPU drivers overhead but that's it.

- IIRC also lag reduction as intended in GM isn't implemented with BGFX yet, and yeah BGFX is laggier than d3d9ex. Oomek's GILT tester demonstrated that, even though the graph he posted is outdated as the measurements were from before -lowlatency had been added to mainline for comparison.

- But yeah with GM set properly at and at a sufficient frame_delay level, in a non-laggy setup (display, controls etc), the only lag left is practically the same as the game's pcb.
Note however that contrary to retroarch's run_ahead it won't touch the game's inherent lag, so it's not possible to obtain a delay lower than the real thing.

- NB: it is usually wise to post your full settings, like attach a copy of your mame.ini if you haven't already, so we can actually tell what's going on in Groovy (also a log if possible which is even more useful to Calamity). I remember some time ago there were people who didn't understand how GroovyMAME works, and were making similar lag tests but they had disabled vsync (autosync), which basically turns frame_delay - and therefore lag reduction feature - off, resulting in completely wrong measurements.

I wonder why mamedev does not enable lowlatency by default?
Some games don't work properly with it, I think that was the reason.
« Last Edit: July 04, 2022, 09:18:48 am by schmerzkaufen »

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #6 on: July 04, 2022, 10:04:17 am »
Is there any way to check what "video auto" in mame is picking? It looks to be bgfx from the measurements (auto is measuring the same as bgfx for me)



I'm using GroovyMAME 244 and MAME 244 with default downloaded packages extracted to a clean new folder. Default mame.ini files for both.

Modifications to ini file are:

GM: Modified the path to the roms plus pointed VMmaker to the GM folder when installing the resolutions.

MAME:
Modified the path to the roms
lowlatency 0 change to 1
video auto changed to bgfx then to d3d9ex
(This is noted in the results)


« Last Edit: July 04, 2022, 10:30:22 am by flybynight »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7414
  • Last login:April 10, 2024, 02:02:31 pm
  • Quote me with care
Re: GroovyMAME input lag is still faster than MAME
« Reply #7 on: July 04, 2022, 10:54:15 am »
Option -video d3d9ex doesn't exist. It's either auto, d3d, opengl, bgfx.

-video auto defaults to d3d on Windows, but to bgfx on Linux.
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 of pasting it.

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

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #8 on: July 04, 2022, 11:43:59 am »
Thanks for the explanation.


On stock MAME (not GM) on Windows 10, if I set:
  video auto
  lowlatency 1
or
  video bgfx
  lowlatency 1
It's the same number of frames as
  video auto
  lowlatency 0



However I do
  video d3d9ex (invalid option - what does MAME do here?)
  lowlatency 1

It's on average 1 frame faster.


I will measure stock MAME again with "video d3d" next weekend.



flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #9 on: July 04, 2022, 01:23:59 pm »
I had a look at baseline MAME code on github and found this logic below. 
"video auto" does indeed seem to default to D3D.

To my untrained eye it seems if an invalid video mode is entered (like I did with d3d9ex) it defaults to another mode called "GDI"? So does this mean in baseline MAME that "video GDI" is 1 frame faster than D3D based on my measurements?

https://github.com/mamedev/mame/blob/ee1e4f9683a4953cb9d88f9256017fcbc38e3144/src/osd/windows/video.cpp
Row 166:
   // video options: extract the data
   stemp = options().video();
   if (strcmp(stemp, "d3d") == 0)
      video_config.mode = VIDEO_MODE_D3D;
   else if (strcmp(stemp, "auto") == 0)
      video_config.mode = VIDEO_MODE_D3D;
   else if (strcmp(stemp, "gdi") == 0)
      video_config.mode = VIDEO_MODE_GDI;
   else if (strcmp(stemp, "bgfx") == 0)
      video_config.mode = VIDEO_MODE_BGFX;
   else if (strcmp(stemp, "none") == 0)
   {
      video_config.mode = VIDEO_MODE_NONE;
      if (!emulator_info::standalone() && options().seconds_to_run() == 0)
         osd_printf_warning("Warning: -video none doesn't make much sense without -seconds_to_run\n");
   }
#if (USE_OPENGL)
   else if (strcmp(stemp, "opengl") == 0)
      video_config.mode = VIDEO_MODE_OPENGL;
#endif
   else //NOTHING MATCHED SO DEFAULT TO GDI
   {
      osd_printf_warning("Invalid video value %s; reverting to gdi\n", stemp);
      video_config.mode = VIDEO_MODE_GDI;
   }


« Last Edit: July 05, 2022, 06:18:23 am by flybynight »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME input lag is still faster than MAME
« Reply #10 on: July 05, 2022, 06:03:24 am »
Just to confirm @ Calamity

'video auto' in baseline MAME = d3d (afaik d3d9ex is no longer supported in baseline anyway)
'video auto' in GroovyMAME = d3d9ex (though the term is just 'd3d')

Right ?

EDIT:

also confirm roughly
GM and Baseline on default settings (with or without -lowlatency) = same amount of lag (same under a CRT or VRR setup for instance if you turn vsync/autosync off)
GM with -lowlatency (default) + frame_delay 1 = 1 frame faster than Baseline with -lowlatency (in total 2 frames faster without)
GM with -lowlatency (default) + frame delay higher working setting (7~8 whatever works best) = 2 frames faster than Baseline with -lowlatency (in total 3 frames faster without)

In fact you don't really need to measure this, it's how it works so those amounts of lag reduction are what is roughly to expect. What accurate measurements may capture are the slight discrepancies, like when an input registers at the wrong moment for frame_delay to be effective, or the miliseconds of added drivers overhead.
The GILT tester has already demonstrated an,d confirmed all this.
Then if you wan to count the whole lag chain add the game's internal/inherent latency which can be roughly revealed with the pause + frame advance method (which may not be very accurate since it can only count full frames, because Windows yadda yadda)

TL;DR since -lowlatency works for most games in both builds, we can say that with frame_delay at a high enough working setting, GroovyMAME is roughly 2 frames 'faster' than Baseline MAME.
(And...just think about it; before Calamity added -lowlatency to Baseline MAME, which represent -1 frame, GroovyMAME users had been enjoying a total of roughly -3 frames of delay...since 2012! yet people outside of this community here, never really realized :lol. To their credit until recently GM was, depending on the requirements, quite difficult to understand and configure properly, I've seen a lot of ppl remain very confused with GM all those years. But since recently Calamity basically made it noob-friendly by adding the sliders and saving settings, anyone can enjoy it now)
« Last Edit: July 05, 2022, 07:04:30 am by schmerzkaufen »

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #11 on: July 05, 2022, 08:38:35 am »

That is what I am roughly measuring except for one thing:

GM and Baseline on default settings (with or without -lowlatency) = same amount of lag (same under a CRT or VRR setup for instance if you turn vsync/autosync off)


I do not measure this for some reason and I'm 99% sure it's to do with hte default mame.ini from baseline.

From the default GM and baseline MAME packages extracted, no changes to the ini files I measure GM as 1 frame faster always.


Calamity did mention above lowlatency is off in baseline mame.ini and he was right so I enabled it and.. no difference! So I'm doing something wrong in baseline mame.ini as from what I've ready, baseline mame should be the same as GM without any Frame Delay configured.


Overall what Im doing is measuring input lag in my setup for
1. Real PCB
2. GroovyMAME (default then frame delay)
3. Baseline MAME
4. Mister
5. Pi

GroovyMAME with framedelay 6 / Mister / PCB are (mostly) the same.

Baseline MAME is two frames over but I think I have to be missing something in the config.

Also the Pi I really have to read up on as It's way off (4 frames extra)








dchase

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 23
  • Last login:July 21, 2022, 05:13:35 am
  • -Banned-
Re: GroovyMAME input lag is still faster than MAME
« Reply #12 on: July 05, 2022, 08:48:55 am »
Mainline MAME never incorporated the D3D9ex patch. It really should.
-Banned-

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME input lag is still faster than MAME
« Reply #13 on: July 05, 2022, 09:48:02 am »
Calamity did mention above lowlatency is off in baseline mame.ini and he was right so I enabled it and.. no difference! So I'm doing something wrong in baseline mame.ini as from what I've ready, baseline mame should be the same as GM without any Frame Delay configured.
Yes that's what I intended to say, worded differently in short when things are working as they should, you should have;

. baseline MAME & GroovyMAME (-lowlatency OFF) = same delay
. baseline MAME & GroovyMAME (-lowlatency ON) = same delay

That's the base delay on VRR or CRT when no vsync or buffering of any sort is applied, which means virtually zero delay for both.

Then, in a different configuration and setup, when vsync/autosync is required, GroovyMAME wins by being up to 2 frames faster thanks to frame_delay (video 'auto' which is afaik d3d9ex)

Side note for people who want to preserve the original speed in certain games like 53,54,55Hz refresh ones, while lacking VRR or CRT, and sacrifice the smooth scrollings: triplebuffer (asynchronous mode) is still activating itself for frequencies outside of the sync_refresh_tolerance value. Calamity salvaged/updated that feature, it is important to remember that it adds a bit of lag (about 0.5-1.5  frames or 7-25ms), yet if measured it should be in a separate chart. Personally when I'm on my laptop I increase sync_refresh_tolerance to 2.78 or 3 so that mode only activates for games that would otherwise accelerate beyond +5% speed)

--

We're being very redundant but that's fine if that makes it ever clearer in reader's minds.

Hopefully some day Calamity & Co. will have an alternative working with BGFX too, maybe something really esoteric, maybe involving 'frame slice' I dunno.
Though VRR is becoming more common and accessible these days, even I ended up getting equipped with it, and yeah that makes old systems emulation much simpler, so even though there will still be quite a number of ppl who will need the lag reduction features etc, it will remain a package of unique features, kinda bleeding edge old tech for remaining niche users.

Must say though, I'm not always sitting at my desktop and while away stuck with a crappy laptop, Groovy is still the obvious go-to choice when I have that arcade itch.
I don't picture VRR becoming the standard for even cheapo mobile devices nor even entry-level hardware in general, before still many, many years, therefore such special emulator builds will continue to be relevant.

(PS: of course the CRT side is the primary intent of GM, but the lag reduction topic expands to all scenarios)

« Last Edit: July 05, 2022, 01:34:53 pm by schmerzkaufen »

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #14 on: July 05, 2022, 01:42:27 pm »
My apologies! When I said "no difference" when toggling lowlatency on in baseline MAME, I should have said was there is "no improvement" in input lag (I didn't mean "no difference between GM and MAME")


When measuring baseline MAME toggling lowlatency on or off showed no improvement in input lag.


It was only when I played around with the "video" parameter I found that when I combined "lowlatency 1" with the (invalid) "video d3d9ex" there was a 1 frame improvement in baseline MAME and this finally matched GroovyMAME.  However since "video d3d9ex" is invalid, this is confusing matters further. I believe an invalid video parameter defaults to "video gdi" as per the mame source code but gdi is supposed to be the the slowest of them all, not faster.


I'll test again with correct video parameters next weekend and will also throw "video gdi" into the tests. (CRT with slow motion camera).


If you know of any mame.ini setting in baseline MAME that can inadvertently disable the "lowlatency" setting in baseline MAME please do let me know.
e.g. you mention "autosync" parameter must be 1 and it is in the GroovyMAME mame.ini but baseline MAME mame.ini doesn't have this parameter.










dchase

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 23
  • Last login:July 21, 2022, 05:13:35 am
  • -Banned-
Re: GroovyMAME input lag is still faster than MAME
« Reply #15 on: July 05, 2022, 02:28:02 pm »
There's a non GroovyMAME build that incorporates the Direct3D 9ex changes from Calamity.

-Banned-

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7414
  • Last login:April 10, 2024, 02:02:31 pm
  • Quote me with care
Re: GroovyMAME input lag is still faster than MAME
« Reply #16 on: July 05, 2022, 05:31:50 pm »
@flybynight,

Please check this PR where the -lowlatency feature is explained: https://github.com/mamedev/mame/pull/5901

Specifically, this:

The longer the emulator stays idle (throttling), the greater latency reduction achieved. In other words, systems that are emulated faster will have less latency. The optimal benefit is obtained with v-sync off (e.g. VRR) where all throttling is based on CPU.

With v-sync on, there's still some potential benefit too, but it depends of how long the emulator stays in throttling, which in turn depends on how the game's refresh aligns with the screen's refresh. However, if throttling is disabled with v-sync on (-nothrottle -waitvsync), like it's usually done to achieve smooth scrolling, there will be no benefit, since inputs will be polled immediately after rendering. Latency figures with vsync-on are terrible nevertheless.


It sounds like you might have enabled v-sync on baseline MAME, that's why the benefits of -lowlatency would be minimized.

Basically -lowlatency arranges the emulator's loop in an optimal way with regards to input polling. This optimization is broken when vsync comes into place. VRR monitors don't need vsync so -lowlatency is all they need to be "lagless" (pcb-like).

When vsync is enabled, in addition to -lowlatency, we need another trick to compensate for the latency associated to buffering: -frame_delay. CRT screens require vsync to look good so -lowlatency + frame_delay allows achieving a lagless experience.

Shmup's forum guys don't use vsync, that's why frame delay does nothing for them:

For the same reason, -lowlatency alone works great in their case.
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 of pasting it.

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

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #17 on: July 06, 2022, 03:57:09 am »
Hello Calamity!

I will read that PR link today. Thank you.


I'm using the default mame.ini from baseline MAME.

Searching the baseline MAME default mame.ini file for the word "sync" if has the following sync related defaults set:
waitvsync                 0
syncrefresh               0


GroovyMAME has "autosync 1" but this is not in the baseline MAME mame.ini file

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME input lag is still faster than MAME
« Reply #18 on: July 06, 2022, 06:16:21 am »
Shmup's forum guys don't use vsync, that's why frame delay does nothing for them:
You could try explaining a hundred times that GM achieves lagless even with vsync, they'd still not trust you and keep going with their BS settings, because they've heard long ago of vsync off being THE thing to do once in their lives, and that's the maximum amount of info people just playing games can process period.
They weren't bothered playing with obviously lower-than-original delay achieved with novsync and run-ahead either, some claiming legit high score achievements with that posing no issues it seems.  :dunno

I mean ok, it's always been like this, the moment software does even the smallest thing that isn't crystal clear to even the newbiest of noobs on Earth, there will be confusion and it will stay.
I remember when you ported -lowlatency to baseline MAME, just the naming of the feature which I think was mamedev's idea completely confused everyone, from there it has been pointless trying to explain its effect, where it came from, whatever, people would be making their own theories to describe it. Still today many are confused, there is no fckn way some will listen still. Technical talk about emulation and features is clearly not easy sharing between the handful of developers and skilled people, and the vast pool of end-users who don't have much knowledge on the topic, but neither 'side' ever seriously invested the amount of communication effort required to quash the erroneous narratives and limit the confusion (being part of the unskilled demographics I've tried my best and yet could only ever scratch the surface, so imagine the multitudes who never even tried)

NB: tbh this yt channel you linked is not representative of the 'shmups forum' (which long split into a number of churches on social media etc anyway), rather it is one aspiring influencer who's long been trashing GroovyMAME because he could never grasp how it works, refused help like it was insulting his ego-reputation (tbh few ppl could deal with GM before the sliders, and after it was kind of too late already as this guy somehow managed to become the little emu guru he wanted to be), instead he offered people pre-configured RA builds with terrible settings promising emulation virtues he never himself understood the nature of, but that earned him popularity which was, is, clearly his priority.
The thirst for online glory and the hubris of some people is literally limitless. Internet influencers in a nutshell, pure ego, zero shame. When he was on shmups forums he was trying to bring people to join his own community and got pissed over time that he wasn't getting full approval nor enough attention to his liking, logical conclusion; it's the shmups forums community that's bad!  :lol
I don't waste much time in forums or social media anymore and don't game much anymore either, but I still wanted to underline that shmups forums was never actually that bad a community, it was even great for a long time but the genre got old, and some individuals with big egoes tore it apart with their own selfishness (the owner included). I think the few that remain on it today are mostly fine ppl though, but personally seeing that putting effort into helping fellow members with GM weighed nothing next to nasty individuals wielding 'alternative emulation facts' and way more skilled than me at generating internet buzz, made me lose interest. We're in an era in history where idiots and villains win period. Internet gave village idiots and crooks the power they always lacked and they will exploit that new weakness of civilization to the full extent. Better stay away from that shitshow as much as we can.

Man, I hadn't ranted on the internet so much in quite a while. It's true that it is tedious, most ppl don't read anyway no need to remind me of that.  :lol

TL;DR random reader; Groovy's the best MAME build with lag reduction period, roughly 2 frames faster than baseline, which it manages without sacrificing vsync, nor betraying the original game's delay. With it you get as close as possible to pcb-level of lag for those beloved arcade games, if you don't own a CRT or VRR setup and value things done correctly it is your best friend, has been for a decade already, and it's free ! What you didn't know ? shame on you random peasant !  :P :lol
(plus caveheads can tweak those cv1k slowdowns with saving slider settings and always up-to-date drivers from mamedev, howbow da?)
« Last Edit: July 06, 2022, 06:20:31 am by schmerzkaufen »

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #19 on: July 06, 2022, 07:52:23 am »
In fairness there is an absolute ton of incorrect info online about the settings. I'm only interested in CRT and have no clue about LCD or VRR LCD settings. Perhaps an updated FAQ on the top of this forum would be good?

something like:

For GroovyMAME best input lag results:

on CRT:
-Use the default mame.ini that comes with the GroovyMAME zip package.
-Enable Frame Delay via tab and select the highest number you computer allows without slow down.

on standard LCD:
-??

on VRR LCD:
-??


For baseline MAME best input lag results: (will never be as good as GroovyMAME with Frame Delay)

Note: Baseline MAME doesn't come with a mame.ini file any more. You have generate it from MAME. Open MAME, open options, toggle a random setting and save the configuration to generate the default mame.ini file.  Then toggle the random setting back to the default and save again.

on CRT:
-Edit the default mame.ini and change
lowlatency 0 to lowlatency 1
(anything else??)

on standard LCD:
-??

on VRR LCD:
-??



« Last Edit: July 06, 2022, 08:16:20 am by flybynight »

schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME input lag is still faster than MAME
« Reply #20 on: July 11, 2022, 06:34:31 am »
In fairness there is an absolute ton of incorrect info online about the settings. I'm only interested in CRT and have no clue about LCD or VRR LCD settings. Perhaps an updated FAQ on the top of this forum would be good?
I know some tell ridiculous things about GroovyMAME settings but one thing's for sure is that they could always come ask questions here instead of spreading BS, I've never asked elsewhere myself, why would one do that ? the very developers are here in person.
Anyway.
Though arguably this forum has long periods of non-responsiveness, you will see tumbleweeds and hear only ghostly whispers for answers, because the one person who's best at helping is Calamity himself who's sometimes too busy IRL.
Also I think he and the people who contributed to GM don't care too much anymore if people understand their build or not, since they've basically explained and provided support to the best of their ability for over a decade but failed to make things clear to the majority despite that, I think they're fine with only a small users base, mostly of the usual CRT builders kind, who are educated-enough to manage the bulk of it without extensive 'from scratch' support.

There IS a 'quick guide' available on another forum, I've never understood why there since it hurts visibility https://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=433
Newcomers to GM typically miss it, they naturally first come here on BYOAC unaware of its existence.
Anyway, its contents at some point might fall behind development evolution and lack mention of some settings, though the author will update chapters from time to time.
Despite calling itself 'quick' it looks quite dense which discourages some readers I think lol, but note that it covers most essential topics for a basic use, which are impossible to summarize in just a few words.
You don't need to know everything anyway.

on standard LCD:
edit Groovy's mame.ini
Code: [Select]
monitor                   lcdThen ingame press TAB and in the SLIDERS menu adjust frame_delay and vsync_offset (the latter is for if you see tearing, balance the two sliders to eliminate it).
Note vsync_offset increases CPU/GPU load so don't try to set it too high, instead reduce frame_delay by a step then try adjusting the offset again.
Your settings save automatically.

NB1: about games that are originally less than 58Hz refresh: frame_delay will only work as long as vertical sync is active, on a normal 60Hz flat panel display because of autosync vertical sync turns itself off and hands it to triplebuffer (better called 'asynchronous' mode now) in order to avoid speeding up the games too much, like for instance playing R-Type's ~55Hz locked to 60Hz would run the game at something like 109% which is unacceptable for some players. Remember that by default sync_refresh_tolerance is set to 2 (= 2Hz which means actual vertical sync with frame_delay will only be active for games down to 58Hz and therefore not R-Type and many others that are less than 58).
Since again frame_delay does not work when that asynchronous/triplebuffer mode is active, the concerned game's speed becomes correct but scrollings are no longer smooth and the lag is increased (up to 0.5-1.5  frames as I've already mentioned, which is afaik still faster than typical triplebuffer).
So, to take control of that you are free to increase sync_refresh_tolerance to cover more or less games. Personally when I use a simple 60Hz monitor like my laptop's, I set it to 2.78 so it will properly sync games down to Sega sytem18 hardware without accelerating gameplay more than 105% (you can just set tolerance to 3 to make it simpler), but if someone wants even games like R-Type to have real sync with frame_delay benefit, then they're free to increase that setting to 6 or 7 or even more, set it to 10 and all games emulated in MAME down to 50Hz will by covered by smooth vertical sync and frame_delay (though very accelerated for the lower end!)
Alternatively you can also of course fine-configure by creating individual game.ini files if you prefer that to a single fixed limit.

NB2: with a small number of standard LCDs/flat panels, GroovyMAME is still able to generate its own 'homemade' VRR working with AMD GPUs...yes...and even without CRT_Emudriver installed.
Thanks to the setting allow_hw_refresh, personally besides my current main VRR desktop monitor, I own two simpler NON-VRR monitors that will still play all games at their native refresh rate thanks to that setting.
One is a 2007 monitor, the other 2017 iirc, neither is officially VRR capable, yet with GroovyMAME it works. This is a kind of hack ppl also experience using CRU and that Calamity has long implemented in Groovy, now it works even without installing Emudriver.
It is a niche feature that won't work on all monitors but it is worth a try.
TBH though FreeSync/G-Sync monitors have become rather affordable, for instance I own a Gigabyte M32Q which I've seen under 400 on sale recently.

on VRR LCD:
Code: [Select]
monitor                   lcd
...
autosync                  0
Done.
If you still notice tearing or choppy scrollings then the problem might come from your setup and not from GM.
Recently I've had bizarre issues with G-Sync (but not just using GM, also with PC games) that wasn't 100% smooth, seems it fixed itself but not sure how tbh.
No issues with FreeSync.
PS: if necessary remember to reset your individual ingame settings like the SLIDERS ! since you don't need them anymore.

For baseline MAME best input lag results: (will never be as good as GroovyMAME with Frame Delay)
They're as good as long as you use VRR/CRT (edit: but who uses baseline for CRT btw?)
You just need to to set lowlatency 1 and make sure that any kind of vsync setting is 0 in baseline.
Done.


In regards to the common confusion about GroovyMAME;
Besides the obvious CRT dedication then, Groovy can also maintain real refresh rates and input lag identical or quite close to the real hardware...even on a standard LCD/flat panel, and that still without sacrificing vsync.
That's the point of its features besides the real CRT resolutions ability.
Yet I've met many people who were not aware of that even having heard and even tried GM. Not shitting you.
Some are confused with what GM is actutally capable of besides the first thing they've heard maybe 10 years ago "its meant for CRTs period".
In fact it packs LCD/flat panel features that are unique to it and way more advanced that other build's.

In regards to lag reduction;
The only thing some ppl ever heard about to achieve that is disabling vsync on everything - PC games or emulators - even if that means to endure tearing. It is just too much of a stretch for them that one could keep vsync yet not suffer lag.
Also some have only ever known RetroArch with run_ahead - despite Groovy being way older - and they don't understand the difference between the two, and try to set Groovy like they would RA (which of course doesn't work and is even counter-productive lol)

GroovyMAME has earned itself a reputation of being obscure and esoteric, which is not deserved...or rather not anymore since Calamity has added the sliders.
But I guess for many it happened too late, the greater popularity it should logically have achieved after becoming more accessible never came because of how things changed, old retrogaming communities heavy users of emulators kinda declined in activity, and anyway remaining enthusiast players went to RA or whatever pre-configured or hacked builds disregarding the questionable results or issues.
More bad timing made it that at the same time GM was leaping forward in ease of use and accessibility, the up-to-date MAME rom sets became nearly invisible and inaccessible to most, which made keeping up with development and releases a PITA for many.

Aside from that there's also been quite a number of console ports with many more than decent, and the MisTer thing of course which I find kind of overkill in cost and limited in output for processing power reasons, sometimes not bringing in much benefit vs. GM, but that has kind of re-ignited development enthusiasm so I guess = progress is always good anyway.
« Last Edit: July 11, 2022, 06:53:01 am by schmerzkaufen »

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 332
  • Last login:December 01, 2023, 07:39:55 pm
    • Eiusdemmodi
Re: GroovyMAME input lag is still faster than MAME
« Reply #21 on: July 11, 2022, 07:19:08 pm »
A Mister device is the perfect complement of a Groovy MAME setup, not just because home systems are in general quite poorly emulated in MAME whereas they shine in a Mister, but also because the Mister project has this man for arcade games, which get [much] better emulation than with MAME in many cases thanks to his scrupulousness. MAME, you know, has many incomplete things and sadly they (we) didn't get somebody like Jotego.


Quote
There IS a 'quick guide' available on another forum, I've never understood why there since it hurts visibility https://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=433

What I called "quick" is the configuration itself; the guide explains every instruction (which you often don't need to comprehend), so yeah, it cannot be "quick". I hope to get the time to update it this year, but who knows. It's not here because of that very reason -- it's outdated and unofficial. It got over 200,000 readers along with the old version, so I'd say it's not eluding visibilty. And this forum is a mess in that regard, anyway.



schmerzkaufen

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 791
  • Last login:October 03, 2023, 02:27:31 pm
  • Multiple Electronic Machine Emulator
Re: GroovyMAME input lag is still faster than MAME
« Reply #22 on: July 12, 2022, 05:33:36 am »
A Mister device is the perfect complement of a Groovy MAME setup, not just because home systems are in general quite poorly emulated in MAME whereas they shine in a Mister, but also because the Mister project has this man for arcade games, which get [much] better emulation than with MAME in many cases thanks to his scrupulousness. MAME, you know, has many incomplete things and sadly they (we) didn't get somebody like Jotego.
Yes, though MiSTer isn't for everyone, personally I own most consoles with flashcarts and modchips, and the arcade systems that are emulated or in development aren't the ones I'd most enjoy seeing get the MiSTer treatment either, apparently because it's too weak a hardware so it won't happen anyway.
Maybe if MiSTer had happened 10 years ago, I would have been drooling all over it, but I don't care nearly enough these days.

As for the lackings of MAME, well, ima avoid talking mamedev politics here lol. Some things will simply never change, some never happen, people will be people, end of subtopic for me. I still enjoy old games and emulation from time to time of course, and Groovy has achieved the status I hoped it would, basically fixing all of the major practical lackings of baseline outside of the core/drivers emulation domain. So yeah if ONE thing actually happened and delivered it's Groovy.
Tho in the same time I got too old and busy with IRL crap for dedicating any serious time to frantic arcade gaming, so today I'm focused on building a couple of PCs and selling most of my old games anyway. Things I used to care about all archived in digital form on hard drives and moving on to other things.

What I called "quick" is the configuration itself; the guide explains every instruction (which you often don't need to comprehend), so yeah, it cannot be "quick". I hope to get the time to update it this year, but who knows. It's not here because of that very reason -- it's outdated and unofficial. It got over 200,000 readers along with the old version, so I'd say it's not eluding visibilty. And this forum is a mess in that regard, anyway.
Well, clicks are one thing then there's what you experience meeting with people and exchanging on the topic on a regular basis for many years over in communities. What is GM in general and how to use it even in its basic form largely remained an obscure topic and links to eiusdemmodi missed, maybe not in clicks counts for you looking over the years, but in IRL communication with users trust me it remained very elusive.
I mean look, can you even find a link in the opening post of this the very main GroovyMAME release thread ? things like that and the sometimes extensive tumbleweeds periods on BYOAC always held down the spread and adoption of Groovy. I understand documenting and providing support is a PITA, especially if that means putting oneself in the shoes of noob's minds, and we couldn't even start a wiki or anything, but denying it was always an issue would be...do I need to spell it?
Just looking here and now, we're in an archetypal discussion thread that's a case of an end user being confused with GM, I've talked with tons of people like flybynight, and that definitely isn't exclusively the result of some ppl spreading false information outside, it's also because when you're curious about GM and land here it's...barren, when it should be in-you-face centralized everything that matters then unmissable directions to more detailed info and support. With flashing giant fonts.
Thankfully we have the sliders now, and Oomek confirmed the lag performance*, because before that these kind of discussions naturally moving on to configuration support, were many times more dense and intense.
(*experiment most ppl who've heard the GroovyMAME name are still largely not aware of and the only chart published would help an update, anyway)

This build's long been a thing of small but more educated/skilled or mostly more dedicated niche that doesn't really share with the bulk of what we would think are ppl with the same hobby interests, but with enough small differences that an actual rift would remain open as a kind of 'inside community classes split' for as long as the hobby has existed. In short elite nerds and gaming nerds, with very few individuals having the traits to bridge on both sides.
That's why the sliders and saving cfg's were essential too, besides written tutorials such features would massively impact the learning curve and therfore accessibility and adoption, but these appeared late somewhat after the shape the internet adopted in recent years changed everything, made it that understanding, cohesion and cooperation don't matter anymore, or say, community exchange morphed in multi-variety of flavors that don't mix these days (which also explains in parts how RA or even stupidier things like ShmupMame managed to steal the popularity that rather MAME and Groovy deserved)
It's not really getting old that sucks, rather it is the consequences of not managing (or not wanting) to adapt the right way and in time to avoid being negatively impacted by the changes that does.
Overall GroovyMAME is a brillant success technically speaking, but in terms of popularity for the broad bulk of end users into retro gaming it remained a bit of an obscure esoteric outsider, from their perspective it didn't end up standing on the high podium of emulation and arcade gaming, while RA or even Pi did receive much love, mainly thanks to their ability at showing off and 'marketing' themselves. And now it's MiSTer that's overshadowing Groovy because of the consequence of being able to display actual better emulation than MAME, so in the end I can't help but still be a bit bitter about it, even if I'm now moving away from the hobby. :p
« Last Edit: July 12, 2022, 05:37:12 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7414
  • Last login:April 10, 2024, 02:02:31 pm
  • Quote me with care
Re: GroovyMAME input lag is still faster than MAME
« Reply #23 on: July 13, 2022, 08:56:30 am »
@flybynight

I redid the tests here:

* MAME vs GM: both with lowlatency, no vsync: SAME measured latency (that's what I expected).

Using an AMD card here, Windows 10. The reason you get an extra frame for baseline in this situation, could be due to the drivers/gpu in use, that for some reason buffer one frame even with vsync off (forced synchronization options in gpu's control panel?). The fact that switching to gdi fixed that supports this theory.


Anyway, the reason the lowlatency feature in baseline MAME, is that by using it on a VRR LCD screen, latency is as low as it gets. It's like having -frame_delay 9 for free.

G-sync/Free-sync features are buggy in my experience and far from perfect. But the technology is already there to address one of the critical issues of the polyhedral problem of video emulation.

« Last Edit: July 13, 2022, 09:09:44 am by Calamity »
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 of pasting it.

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

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7414
  • Last login:April 10, 2024, 02:02:31 pm
  • Quote me with care
Re: GroovyMAME input lag is still faster than MAME
« Reply #24 on: July 13, 2022, 10:27:47 am »
We're in an era in history where idiots and villains win period.

 :laugh2:

They call it democracy. Or the market, its economical version.

I agree I should have provided better documentation, but I don't think that would have made GM any more popular. GM tries to solve problems most people don't know they have. The ones that are aware of these problems, are already capable of understanding GM without much trouble. At least that's the way I see it, I can be wrong of course.

Then you have to understand that not everyone is good at producing writings. I'm specially terrible on that regard. It's super time consuming for me. I want to die each time I have to do it in my dayjob.

For years I gave support on this forum, on a daily basis. I figured that answering specific user's questions was the best form of documentation. For a person that has learnt almost everything on internet forums, that was a logical point.

I expected that, after years of discussing about modelines, crt_ranges, etc., a critical population of power users would appear that managed to produce the lacking documentation. Recap was there from the beginning, doing a great effort. Others here, like buttersoft, also did their own. Currently there's ongoing wiki effort by Oscilated and others here: https://gitlab.com/groovyarcade/support/-/wikis/home

But long ago I realized that, with the exception of a few users, no one was actually understanding the logic of crt timings and the power that GM's configuration provided. This is in my opinion my biggest failure with regards to this project, since I had expected that making timing options accesible would popularize the (actually easy) understanding of crt timings. In other words: my failure to push the "crt_range" as the standard configuration for people involved in CRTs.

Then you have the volatile nature of today's internet. When I write about something, I think my job is done. However, now you're supposed to keep permanent updates on everything, otherwise the truth gets rotten. E.g. I demonstrated next frame response in 2012, in a thread here. As far as I'm concerned, that was stablished that day. However, every few months you had posts questioning or just ignoring this fact, curiously enough until someone achieved the same with RA several years later.

I mean to me, this is all an amusing show I watch with a smile. This is just a hobby that's gone too far. I'm a product of the 20th century. I don't have social networks. Only discord and I'm already mocked for that.

I have a couple of Misters and they're awesome things. If GM is replaced by something better, then we should be happy. The problem is when things are replaced by worse alternatives, as we've experienced in almost everything in the last decades, thanks to God Market.
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 of pasting it.

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

flybynight

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 73
  • Last login:Today at 08:05:44 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #25 on: July 13, 2022, 01:28:53 pm »
@flybynight

I redid the tests here:

* MAME vs GM: both with lowlatency, no vsync: SAME measured latency (that's what I expected).

Using an AMD card here, Windows 10. The reason you get an extra frame for baseline in this situation, could be due to the drivers/gpu in use, that for some reason buffer one frame even with vsync off (forced synchronization options in gpu's control panel?). The fact that switching to gdi fixed that supports this theory.


Anyway, the reason the lowlatency feature in baseline MAME, is that by using it on a VRR LCD screen, latency is as low as it gets. It's like having -frame_delay 9 for free.

G-sync/Free-sync features are buggy in my experience and far from perfect. But the technology is already there to address one of the critical issues of the polyhedral problem of video emulation.

Hi Calamity, I'm using the latest emudriver package on an R9 380x card. All is running through the CRT.

I will take your advice and reinstall the graphics drivers and look for "forced synchronization options in gpu's control panel" as I'm still curious why groovymame (without framedelay) is faster than baseline mame on CRT unless I set "video GDI" on baseline.

Could it be the "no vsync" setting that is required? I don't see "vsync" as an option in the baseline mame.ini. I only see two parameters in baseline with the word "sync" in the name and they are set by default as:
waitvsync                 0
syncrefresh               0

Are these set correctly? Am I missing a parameter in baseline?

Thank you!



A Sticky FAQ Topic at the top of the forum would be great. And maybe someone with a big following to do a video with lag testing comparisons for PCB, Groovymame, Mister, Pi to show Groovymame is indeed the same as PCB.

A potential FAQ is below thanks to schmerzkaufen. Keep in mind most people today are PC illiterate and can barely extract a zip file or use file explorer. It has to be as simple as Mister's idiot proof update_all script.


GroovyMAME PCB matching input lag settings:

on CRT:
-Install Emudriver and set the CRT modes with VMmaker
-Use the default mame.ini that comes with the GroovyMAME zip package.
-Then in-game, press TAB and in the SLIDERS menu adjust frame_delay. Select the highest number you computer allows without slow down.


on standard LCD:
-Starting with the default mame.ini that comes with the GroovyMAME zip package.
-Edit this file in notepad and change the following parameter and click File then Save:
monitor                   lcd

-Then in-game, press TAB and in the SLIDERS menu adjust frame_delay. Select the highest number you computer allows without slow down.
If there is screen tearing due to differences between the game's native refresh and the fixed 60hz LCD panel refresh rate, also adjust the vsync_offset in the SLIDERS menu. (the vsync_offset option is too confusing for most people I would say!)


on VRR LCD:
-Starting with the default mame.ini that comes with the GroovyMAME zip package.
-Edit this file in notepad and change the following two parameters and click File then Save:
monitor                   lcd
autosync                  0








« Last Edit: July 13, 2022, 02:07:44 pm by flybynight »

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 262
  • Last login:Today at 05:47:49 am
  • I want to build my own arcade controls!
Re: GroovyMAME input lag is still faster than MAME
« Reply #26 on: July 14, 2022, 09:07:17 am »
We're in an era in history where idiots and villains win period.

They call it democracy.

This almost topped the quote I have in my signature.
So much truth, it hurts.

Quote
I agree I should have provided better documentation, [snip]

My 2 cents, which kind of echo your thoughts: I've been facing this same situation all my life, I write lots of documentation and make simple how-tos and give guidelines and 99% of the people just ignore it. They see a wall of text and no matter how much well structured and easily readable it is, they skip it.

We live in a time where forums are dying because people can't bear to wait for a reply on a forum, they MUST have instant response, hence they use Discord (which, ironically, leverages on technology which is 30 years old, namely IRC) and I see the exact same questions getting asked a billion times and, as long as the Discord server is active, patient people repeating the same things over and over again.

In the end, what matters, and what I've learned, is this: people who are really interested are going to read the documentation, will report bugs and problems and will actively contribute.
All the others will straight out ignore every single thing you've said, posted or documented in a wiki and ask the dumbest questions because they just want the instant gratification, they want whatever thing they are onto in that moment to "just work".
And then they eventually get bored of it and will move on and you find out you'll have wasted your time helping out those kind of people.

Some say gatekeeping is bad, but I just want to say that "RTFM" is not gatekeeping, is just a matter of respect to the author of whatever you're using because he's put effort and time into it and ignoring it would be incredibly disrespectful.

As for GM not having "proper" documentation (which, to be fair, it has although it's a bit scattered and not easy to find): you said it best, people who are really interested will find out or learn.
All the others... I don't know what to say.

Everytime I find a new thread about 224p vs 240p I die a bit inside.
On a scale of fakeness, from more genuine to more fake, we'd have:

1.- Plastic plants (cf. Fake Plastic Trees)
2.- Inflatable dolls
3.- Arcade cabinets with LCD monitors