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

0 Members and 1 Guest are viewing this topic.

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 tests 2019 (new method)
« Reply #240 on: August 27, 2020, 06:38:45 am »
4. Press the space bar
5. Press 0 on the numerical keyboard, Is the green rectangle visible?
6. Press 1 on the numerical keyboard, The green rectangle should disappear
I wasn't aware of these key commands! ;D there are no such instructions on the leaflet nor the readme.

Quote
7. Press the GILT button. Is the green rectangle visible?
8. Disconnect Gilt and use a long cable.
9. Press 1 on the numerical keyboard, The green rectangle should disappear
10. Go back to point nr 7.
Okay that worked.

But then I've proceeded on doing the input lag test, and after it finds that it is a 60Hz LCD, I press to resume for the next step which I guess is the lag test proper, but after like 1 second I get error #3
I did it a few times, still #3 and once I got a #6
The display lag, and perceived lag tests give me mainly #6

My monitor is DC (not PWM) if that matters. Level around 255, noise 2~3.
W7 on desktop 60H, nothing special.
« Last Edit: August 27, 2020, 06:50:07 am by schmerzkaufen »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #241 on: August 27, 2020, 06:59:23 am »
The numpad buttons are not doccumented since it's how GILT is communicating with the software. It will be later replaced with the Raw HID commands.
The requirement of pressing a SPACE bar is displayed on the screen. Maybe I will scrap that and listen to GILT straight away if it's confusing.

Would you please provide a screenshots of the errors, do you see any numbers on the GILT's screen?
It will help me to narrow down the cause of the errors.

You can launch `GILT.exe -debug`to see a moving bar, when you press space and hold 6 on the numpad it should animate smoothly a green bar without stuttering.
When you press 7 and then hold 6 again you should see the same bar drawn very fast with tearing.




oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #242 on: August 27, 2020, 07:12:36 am »
Thanks for your tests btw, we're still in the beta phase and if you've hit some corner case your input will help to narrow it down.
« Last Edit: August 27, 2020, 09:10:02 am by oomek »

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 tests 2019 (new method)
« Reply #243 on: August 27, 2020, 10:05:46 am »
Doesn't seem to work any better if I try more times anyway.

Well you can thank me but of nothing because honestly, I wasn't aware I was signing for beta testing when I ordered. I ordered one even though I'm broke at the moment because I wanted to know about just two measurements but you said you were busy, so I didn't want to disturb you, and anyway I've long been waiting to see more emulators lag tests results compared, since the GILT has been a thing in fact.
Because there have been so little measurement results published even by you or Calamity even though you both have the devices, several case scenarios (like triplebuffer is only one of them I asked here long ago but didn't get attention) are still unmeasured, I thought if I can have a unit now I'll do the long awaited missing tests emulators lag myself, also update the current old, and finally share as much results as possible with the general public.

Anyway, I'll do what you ask but taking photos would be a chore right now so I'll write what I see:

input lag
ERROR #3
scur: 172
lmin: 167   lmax: 168
st: 172   sto: 170

display lag
ERROR #3
scur: 174
lmin: 167   lmax: 170
st: 174   sto: 172

perceived lag
ERROR #6
uneven framerate
frame time 25.84ms

The values fluctuate slightly with every try.

Quote
You can launch `GILT.exe -debug`
How exactly? if you expect me to use command line you'll have to explain step by step what need to do, since I am extremely uncomfortable with that.
EDIT: guess I plug the GILT, then bring up a console, then what to I enter (full input) ?
my console on w7 starts this way:
C:\Windows\System32>
do I have to enter the path of the gilt.exe location ? (guess it's yes)

Quote
The requirement of pressing a SPACE bar is displayed on the screen
I think I didn't notice it because I had to put put my monitor on the floor since my 'long' mini-usb cable is still rather short, and I'm working in an uncomfortable position.
Suggestion: if possible give up on Mini-USB, it is obsolete, the rare cables left around people are old (mine is), having to get one when you receive delivery of the GILT is an unpleasing surprise.
If I wanted a newer and longer Mini-USB cable now, or if I hadn't found one to borrow, I'd need to spend like 10€ on amazon and wait like a week or two if not more (many ship from HK !).
If you can't do without Mini-USB bc of the pcb design, then I'd suggest provide a long one in the box in place of the (very) short. You could maybe have them in bulk and that'd increase the individual GILT package sell price by only like 2~3 bucks and save the customer both money and trouble. Anyway it's only a suggestion.

Is there anything else I should try ? the GM/MAME ingame lag test is what I am interested in, but I get only crashes there so I guess it's a no-no ? Or ?...
« Last Edit: August 27, 2020, 11:30:32 am by schmerzkaufen »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #244 on: August 27, 2020, 10:12:47 am »
What is your GPU?
« Last Edit: August 27, 2020, 10:15:13 am by oomek »

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 tests 2019 (new method)
« Reply #245 on: August 27, 2020, 10:14:13 am »
Currently RX Vega 56 (rest is in my sig, only the GPU changed, and CPU is not OC'd at the moment)

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #246 on: August 27, 2020, 10:14:50 am »
To open GILT in the debug mode just right click on the blank space in the folder where you have gilt.exe and choose Command Prompt.
then just type `gilt -debug` and press enter

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 tests 2019 (new method)
« Reply #247 on: August 27, 2020, 10:20:57 am »
To open GILT in the debug mode just right click on the blank space in the folder where you have gilt.exe and choose Command Prompt.
then just type `gilt -debug` and press enter
Sorry my OS doesn't have that option on right click menu...

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #248 on: August 27, 2020, 10:24:57 am »
Then copy the full path and type `cd ` in the cmd prompt and paste the path and then press enter, alternatively you can create a shortcut to gilt.exe and then in the properties in the shortcut tab add ` -debug` in target field, don't forget about the space. If you see quotemarks add it after.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #249 on: August 27, 2020, 10:40:42 am »
I suspect that the pixel response time of your monitor is the cause here, more precisely the fall time when it goes from white to black. All monitors I've tested so far were ok with those values, but let's see if it works for you. I've adjusted the timeout and testing it now.  I'll let you know when it's ready to download.

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 tests 2019 (new method)
« Reply #250 on: August 27, 2020, 10:49:40 am »
For now I still couldn't get the debug thing to work, neither method works.
I don't know how to input command lines properly, I do it once a year or two at worst when I have no other choice and every time it is hell.
I hate this to death and will never get used to it, sorry.

For Groovy logs I have .bat that someone here gave me, I always use that without any issues, maybe if you write down one for me that would do.


The monitor; well it's not a high-end panel in a gaming monitor, but its is faster than than the average TV's IPS or VA for sure, and responses are certainly more homogenous than the latter's. Overdrive is always on the lowest setting if that matters.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #251 on: August 27, 2020, 10:50:03 am »
Regarding the cable, I'm still behind financially, all the tooling and parts costed me quite a bit, so I'm shaving the costs. Besides everyone has a different need of the lenght, so it was safer to leave the decission to the user. I could send you an usb extension cable, but it would cost x2 more for shipping. The extension cables on ebay cost £1.5 - £2.5 depending on the length.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #252 on: August 27, 2020, 10:51:40 am »
Overdrive needs to be off for GILT to work properly. It's a software trick that is definitely gonna confuse the sensor.

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 tests 2019 (new method)
« Reply #253 on: August 27, 2020, 11:14:12 am »
No, no don't send me a cable lol!  ;D  It was just as a general recommendation.
lenght uder 1m shoul'nt be significantly diffent in price, actually sometimes the smaller ones are priced higher since they're more rare.
Anyway.


Overdrive: with overdrive OFF the GILT seems to get a few more seconds being able to do its measuring job on every test, but with all three tests I end up getting an ERROR #6 now.

It's a problem if you can't measure with overdrive ON, since most monitors these days are in use with constant overdrive, everyone has it on all the time, it's considered the norm since manufacturers balance the best performance with it on. Some TVs also force a bit of RTC and you can't turn that off, unlike monitors.
« Last Edit: August 27, 2020, 11:28:20 am by schmerzkaufen »

sofakng

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 646
  • Last login:February 18, 2021, 04:19:21 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #254 on: August 30, 2020, 10:53:42 pm »
This device looks absolutely incredible!  I've just sent an e-mail to see if I can purchase one (oomek?) since I'd love to see how much latency is in my setup.

I'm also a bit of a latency guy since I own a Leo Bodnar and also just assembled a Time Sleuth which works great.  However, I've also wondered the actual button-to-screen latency on my MAME setup (GroovyMAME + CRT Emudriver).

I've even started converting my MAME cabinet to MiSTer (FPGA console) but even though it's extremely impressive, it obviously doesn't support that many systems. (compared to MAME)

Anyways, I'd definitely be interesting in buying/assembling/testing one of these devices if they are available!

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 tests 2019 (new method)
« Reply #255 on: August 31, 2020, 01:32:43 am »
Well, it's not controller button, you know some lag can still creep in there on the way before the input registers in the emu.

And regarding the 'perceived' test counting pixel response time is subjective for LCDs since it's really uneven territory, tftcentral cut the pixel response part in half because they say it's unfair to count it whole using the slowest black/white time (plus if we really have to shut overdrive off then we're definitely not seeing measurment for the display at its best)

You can't isolate and measure the emulated game's internal lag either, the GILT tests your display and everything besides the core emulation, if you want everything, the entire chain from controller to the moving sprite onscreen, you still need to perform a camera-type test.
(then, combined with the GILT you can finally deduce the core's)

Still, this is the deepest one of these handy lag testers has ever gone, the 3 different tests are the most relevant to us, and it aims at higher accuracy overall.
Price is also the best. So there's no contest.

Note though that it's still in beta, I wasn't aware of that and mine actually doesn't work with my setup. Oomek is looking into it and I'm waiting for his green light to try something new.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #256 on: August 31, 2020, 03:52:40 am »
I think you should take a look at the graph again. If you want to measure a pure software lag you just subtract your measured Display Lag from Input Lag.
http://www.gameinputlagtester.com/wp-content/uploads/2019/11/chart.png

The new firmware should be ready today.

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 tests 2019 (new method)
« Reply #257 on: August 31, 2020, 04:21:57 am »
Ah? I stuck to what you were saying, that your device can only measure the API for output and input polling performances.
http://forum.arcadecontrols.com/index.php/topic,160722.msg1692248.html#msg1692248

If 'driver overhead' is the same thing I'm talking about (purely the game itself as emulated by the driver, without the input and video API on top) then it doesn't appear to me that it is measured entirely separately there.
I mean what I'm seeing in the graph even if we substract the display lag part is: draw + input polling + frame queue + driver overhead, so it's still a sum.

I guess on a VRR display we can eliminate the queue+polling portions as potential lag generators, and therefore get extremely close to the driver-level truth, or maybe exactly (?), and if not on VRR setup using frame_delay instead; somewhat close assuming ideal performance/setting, but the gap between the two situations is very small anyway.

The new firmware should be ready today.
Nice
« Last Edit: August 31, 2020, 04:23:58 am by schmerzkaufen »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #258 on: August 31, 2020, 05:02:40 am »
The driver overhead is the time spent waiting in SwapBuffers() function with vsync off. Gilt app sends that time back the device and compensates when Display Lag is measured. This is a very small value < 0.2- 0.5ms
Input polling is the time between the input sampling by the game and actually updating the next frame. Gilt does not measure any additionalinternal game's lag that is added by the rom. It measures the capabilities of the emulator and api used, bgfx, opengl, directx.

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 tests 2019 (new method)
« Reply #259 on: August 31, 2020, 05:43:40 am »
Gilt does not measure any additionalinternal game's lag that is added by the rom. It measures the capabilities of the emulator and api used, bgfx, opengl, directx.
So yes that's what I thought and what I mean, GILT can't measure the game's internal 'natural' lag from the emulator (which is the same as the pcb's, a.k.a pcb-level lag, assuming mamedev's code is accurate enough)
For that we do need a camera test, the only way to measure the full chain, then compare with GILT.

PS: with a camera test (done right) and comparison vs. GILT results, the only possible things remaining in the way that could add lag would be a laggy controller pcb or something from the OS then, I assume.
« Last Edit: August 31, 2020, 05:57:31 am by schmerzkaufen »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #260 on: August 31, 2020, 05:50:17 am »
You do not need a camera to measure the lag added by the ROM itself. It's counted in full frames and can be measured by pressing P, holding some game related button and continue pressing shift+P until you see a change on the screen. Why would you want to test it anyway? Original hardware has it as well, and it's game specific, some has it some don't. I do not know the ratio.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #261 on: August 31, 2020, 06:49:19 am »
My mailserver is down again.

Would you please update the firmware to v1.1.1 and test with GILT.exe
If that works we will focus on the issue you're having with the LUA script.

https://github.com/oomek/GILT/releases/tag/v1.1.1

Could you please open an issue on Github for further discussion so we do not clutter this thread anymore?
Now everything is mixed here and it's difficult to keep track of separate issues.
« Last Edit: August 31, 2020, 07:09:22 am by oomek »

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 tests 2019 (new method)
« Reply #262 on: August 31, 2020, 08:25:30 am »
I'd rather use PM here. Anyway testing the new firmware will have to wait tonight or tomorrow, no time right now gotta go.

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #263 on: August 31, 2020, 08:34:29 am »
The notification system on this forum is broken beyond repair. I often get a notification of the PM after a week. Why you're hesitant from using Github Issue tracker?

sofakng

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 646
  • Last login:February 18, 2021, 04:19:21 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #264 on: August 31, 2020, 02:16:57 pm »
oomek, I received your response to my e-mail this morning about purchasing a GILT, but when I try to send you another e-mail I'm seeing an error:

Code: [Select]
550 Verification failed for <redacted@gmail.com> Sender verify failed  (redacted to hide my e-mail address)

Is your e-mail server OK or is Gmail acting funny?

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #265 on: August 31, 2020, 02:24:03 pm »
My email server is broken, need to change it. I'm sending you an email from my private account.

sofakng

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 646
  • Last login:February 18, 2021, 04:19:21 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #266 on: August 31, 2020, 02:29:36 pm »
No problem.  I received the e-mail from your private address and responded.

Thanks again!

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 tests 2019 (new method)
« Reply #267 on: September 01, 2020, 12:44:41 am »
The notification system on this forum is broken beyond repair. I often get a notification of the PM after a week. Why you're hesitant from using Github Issue tracker?
It always worked fine for me. Still does.

I have successfully updated the firmware and tried it on my setup, and now laptop too. I got varied results, which I should write down and share, but...

Listen, I'd like to keep on cooperating, but before I do everything you want your way, remember I first came asking ONE question, the same like 3~4 times including email, that you have deliberately (no doubt now) all ignored like I never wrote a word of it.

So I repeat; can you please test the lag in triplebuffer mode in Groovy vs. baseline's and report ?
I have been very curious about it for long and was asked several times by other users I was helping actually, it matters to more of them than you might think.
If the GILT is working on your setup it should take you only a few minutes.

I told you I don't understand why you and Calamity have apparently both a GILT working with your setups, yet haven't updated the results nor shared any further measurements after the initial ones.
Why make such great things, lit a enthusiasm fire with a number of users...then go silent for months to years on?

So I am not happy that you refuse to talk about it, not a single word, when at the same time I have this uncomfortable feeling that you have deliberately omitted to show more to people and in place lured them to purchase a GILT and work as beta testers.

Quote
the issue you're having
The issue I am having ? the LUA plugin crahes on my laptop too just FYI, don't turn the meaning like the issue is only on my side with my sole setup and you'd be gracing me with support.
I think you have a problem, which is the GILT being far from ready to work globally on a safe-enough majority of displays, and your plan is to get people to pay for the device and then work for you testing and reporting.
That could be acceptable within certain limits, like if you tell them that clearly before they buy (wasn't my case), but don't you find a bit too convenient in my situation to, on top of it all, cherry pick what questions you answer or ignore, and tell me how and where to exchange ?

I can be really nice and go to great lenghts to help people that are frank, direct and honest, with me.
But some developers think we owe them everything unconditionally -with zero criticism nor requests- till the day we die, it's a rather widespread mentality in particular in the FOSS world, where people on the dev side think they got a sacred right to constantly rewrite ethics to their exclusive advantage.
Calamity took the wrong turn in attitude with me some day deciding to basically 'dump' me and very unfairly misjudge why I was even here, not actually joking he suggested I was using him - he evidently forgot about reality - the reality that I also spent insane amounts of time and money on his project, despite being a simple end-user trying my best because I have (had?) so much like and faith in his project. Of course contributing at my level isn't in the same league as what weighs on the shoulders of a developer, but still it's not just hours nor just a few bucks, it's much, MUCH more. And then from there, because I voiced my criticism and discontent, I was basically treated like crap by the rest of the BYOAC regulars.

SO here's the deal man, answer my questions, you'll make me happy, and I'll keep testing the GILT I paid, test as much as you require, on various setups and displays if you require, so you can keep on developing it and reduce the risk of it clashing with other potential 'unexpected behaviour displays'.
And ok I'll move to github too.

Seriously, MAMEdevs & Co. from the FOSS-values-clad crowd ever wonder why their relationship with end-users is deader than rotten fish and why everyone goes to RetroArch/Pie, mini consoles, FPGA etc ? or why crowdfunded projects get all the attention ?
I've seen cops and taxes workers have warmer and fairer attitude towards people, than emu devs and the other fosslike towards end-users.
Just comparing the communities activity tells it all period.
« Last Edit: September 01, 2020, 01:25:50 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #268 on: September 01, 2020, 06:11:37 am »
Hey schmerzkaufen,

Testing triplebuffer on GÏLT is tricky because GILT measurements require perfect vsync while triplebuffer is asynchronous by design (it drops frames when required due to screen's vs game's refresh mismatch). GILT will notice this and fail with "uneven frame rate" error. The fact that GILT won't complete its measurement doesn't mean you can't get some valid lag figures from the time it keeps running, that will provide a valid estimate. For best results, I'd suggest using a game that runs at exact 60 Hz, such as 1942, and force -triplebuffer on it, either from command line or via mame.ini, by disabling -autosync and forcing -triplebuffer instead. The reason to use a 60 Hz game is it'll hopefully give you more time before a frame is dropped and GILT stops.


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

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 tests 2019 (new method)
« Reply #269 on: September 01, 2020, 09:54:21 am »
The GILT instantly crashes Groovy when I try the LUA plugin (in normal autosync conditions, no matter if it's a 60.00 game or not) so I can't try what you say yet.

If you guys could try the method you describe on your own systems and tell what measurements you find, it would be the end of mystery of the triplebuffer lag time that was never confirmed. I've asked both you and oomek over a long time, I couldn't ask anyone else and it's the first time I get a word of reply in place of being totally ignored, so thank you, but I'm stuck...

EDIT: Ok, that's enough of this madness.
@oomek, I'm sending back the device.

EDIT: @oomek. Justsent the return tracking info in PM since your email doesn't work.
« Last Edit: September 02, 2020, 05:50:40 am by schmerzkaufen »

R-Typer

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 143
  • Last login:Yesterday at 08:10:27 pm
  • C64 Rulez!!!!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #270 on: September 02, 2020, 09:24:11 am »
this is sad. we will never know the lag measurements now. they seem as if they are top secret stuff  :(

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #271 on: September 06, 2020, 08:08:06 pm »
As maybe you're unaware I suffer from a chronic condition that leaves me with very limited time in between my symptoms, so I have to spend my time on my TODO list very wisely. I'm sorry that doing tests for you is not on top of my list. Regarding the tests, I'm not sure why you need the triplebuffer, if your display supports VRR just use it. The only time GM may start tearing in VRR is when your desktop's refresh rate is lower than the game's resolution. Just make sure your monitor's RR is above 60 and that's it. You say you need tests just with triplebuffer, but that's not enough, there are more switches that can affect the lag, so you need as many combinations of commandline switches as possible to get a full picture (Yes I know you are illiterate in that matter, but GM overrides some ini settings, so you need to learn how to use commandline args whether you like it, or not)

As Calamity said GILT requires that game runs with syncrefresh, VRR, or in native RR of the monitor, otherwise the lag spread will become longer then the frametime, which in turn makes the tests meaningless with any device, or camera. You just need to make sure GM is not dropping/doubling frames (the integrated moving bar toggle in the LUA script serves that purpose)

@calamity The new firmware does not stop the test when frame drops are detected, it displays the information on the screen and continues the test. When you update the firmware make sure you also up to date with the software/script included in the zip file.
« Last Edit: September 06, 2020, 08:13:29 pm by oomek »

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 tests 2019 (new method)
« Reply #272 on: September 07, 2020, 01:08:18 am »
Ok this is not right so I have no choice but to respond.
@Calamity: I'm not taking defamation without defending myself.

As maybe you're unaware I suffer from a chronic condition that leaves me with very limited time in between my symptoms, so I have to spend my time on my TODO list very wisely.
You know I'm aware, you sent me a pic from the hospital after all, I told you to take all your time resting instead of taking care of the GILT issue. It would be petty of you to pretend I don't know or didn't care to make me look bad. You wouldn't do that, right ?

I'm sorry that doing tests for you is not on top of my list.
I've never asked for tons of measurements, just asked only for one, or two measurements exactly, since I'm curious how it compares to baseline. It should have take about 5~10 minutes in total.
I couldn't have guessed there were issues with what I asked since you kept being silent about it.
And anyway I accepted to purchase a GILT so you wouldn't have to be disturbed.
Remember that part ?
Or do you really want to make me look like I wanted to exploit your time without a care like an egoist ? and forget like I've paid for your device specically so I would measure myself ? (but you omitted to tell me I couldn't) did I protest or complain ? no I just paid and gladly.

The amount of lag in triplebuffer mode should be a more or less fixed amount of frames, supposedly inferior in GM vs. baseline, that's what Calamity said, but it was never confirmed.
Your test confirmed how a previous statement about the default lag with d3d9ex was wrong (frame_delay off), I was of course curious to know about the other statement about when it's switched to triplebuffer and finally learn the end of it.

Regarding the tests, I'm not sure why you need the triplebuffer, if your display supports VRR just use it.
- I don't use GM only on my primary setup, I also use it on other computers/displays that don't support VRR or Emudriver.
- Knowing how much triplebuffer lags matters in cases we don't/can't use syncrefresh and frame_delay.
- I was asked that question several times by other users, I'm not the only one curious, and many users don't have a setup fit for Emudriver/VRR anyway.
- I've told you all that already including in private, why pretend I didn't?
Anyway this is a 100% legitimate question coming from GM users, it's a whole part of it after all.
Pretending it doesn't matter is like when ppl here were pretending flat panels use doesn't matter so why bother? but this is what most people use, like it or not the world goes beyond the scarcely populated walls of BYAOC, and Calamity made Groovy competent for these displays, the best at it in fact, so it's useless after all he worked on to act like one aspect somehow doesn't exist/matter. It unfortunately still does until everyone on Earth is equipped with a gsync/freesync display (or finds a somewhat rare monitor like mine), which is still far away in the future.

The only time GM may start tearing in VRR is when your desktop's refresh rate is lower than the game's resolution. Just make sure your monitor's RR is above 60 and that's it. You say you need tests just with triplebuffer, but that's not enough, there are more switches that can affect the lag, so you need as many combinations of commandline switches as possible to get a full picture (Yes I know you are illiterate in that matter, but GM overrides some ini settings, so you need to learn how to use commandline args whether you like it, or not)

As Calamity said GILT requires that game runs with syncrefresh, VRR, or in native RR of the monitor, otherwise the lag spread will become longer then the frametime, which in turn makes the tests meaningless with any device, or camera. You just need to make sure GM is not dropping/doubling frames (the integrated moving bar toggle in the LUA script serves that purpose)
There was no tearing at all when I tried, even with frame_delay off and syncrefresh, the LUA plugin would crash immediately in all cases even with exactly 60.00Hz games, if it was still seeing uneven refresh under these conditions then the problem was elsewhere.
I bet this is related to this monitor being driven by Emudriver, which is a rather unique thing since AFAIK I'm the only one doing this (more people could but compatible monitor's aren't too common and ppl don't even imagine something like that is possible.
Maybe you could have found out if I'd kept reporting the errors to you, Id'have battled command line despite my illiteracy until it'd worked, but you weren't cool with me at all, so I've quit and anyway can't do anything anymore since I've sent back the device already, I gave you a tracking number.

It was simple, before telling me to buy a GILT you could simply have not ignored my question -repeatedly- and simply said this couldn't be measured by it or not without roundabout ways, and that it was still in beta and you needed testers anyway.
ONE sentence.
I would have accepted these conditions, in fact I accepted them afterwards anyway, and I would have done a ton of testing for you, but you still refused to talk about what I asked and started to have demands, which is why I stopped being friendly.

What I can't gut is that on top of having been dishonest, and seeing your post is a narrative to cover that and put all the blame on me, you had the nerve to complain to Calamity who threatened me of a ban.
I'm a honest person, straightforward, you guys aren't, yet I'm the one being blamed.

@Calamity; before you attempt to censor this post, someone made a narrative that's very unfair, even defaming to me so I'm responding on the same ground with nothing but the truth.
If you want to censor that and kick me out now, well that's between you and your conscience. I'd advise you wait until I got the refund at the very least, so I can confirm we're through.

You guys should know there is a simpler other way to get out of this cleanly, it's just a few words, but I'm betting it's more comfortable to nuke me, right?

Asking people to show honesty these days is too much, people systematically complain about people like me who refuse to act like a phony. I don't care if I'm disliked, but still, I don't let anyone dirty my purpose, intentions, words and actions, oomek's been completely unfair here, and that's wording it kindly, so it's my right to respond.
Come clean and I'll even edit/erase my posts in this thread if you want, and if you edit yours too, end of drama.

@calamity The new firmware does not stop the test when frame drops are detected, it displays the information on the screen and continues the test. When you update the firmware make sure you also up to date with the software/script included in the zip file.
In regards to the triplebuffer lag, whatever, if you guys don't ever share your finds I guess I can just hope someone with a GILT some day will let the cat out of the bag, or I'll finally get a good-enough camera and find out. *shrug*

It's just extremely sad that developers are SO BAD at dealing and communicating normally with average user people, that they give people no choice but to either give up, or wrestle them in the mud to the bitter end...when a simple few words sentence of honest reply at the beginning would have done it and avoided all the drama.
« Last Edit: September 07, 2020, 02:27:14 am by schmerzkaufen »

Calamity

  • Moderator
  • Trade Count: (0)
  • Full Member
  • *****
  • Offline Offline
  • Posts: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #273 on: September 07, 2020, 07:46:45 am »
I'm a honest person, straightforward, you guys aren't, yet I'm the one being blamed.

Indeed, I'm a poor sinner, whatever you blame me is probably well deserved.

Anyway, it wasn't Oomek who reported you.

On the other hand, I am to blame for not warning Oomek about the risks of interacting with you, but it all happened while I was on vacation.

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

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #274 on: September 07, 2020, 09:14:11 am »
I think I'm gonna take my website down and continue building Gilts just for friends, I'm not planning to put up a big scale production. I've designed it for myself then I started to see an interest, so I wanted to share it with others. It's clearly unfinished for the general public as I am able to only test it on the devices I own. Besides I don't have the energy to deal with random people's demands, especially when someone starts blaming me for something I did not do.

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 332
  • Last login:December 01, 2023, 07:39:55 pm
    • Eiusdemmodi
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #275 on: September 07, 2020, 09:55:21 am »
Has Calimity ever censored any post or banned any member? 'Cause if he hasn't, I can see some very unfair, defaming narrative being developed here.

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 tests 2019 (new method)
« Reply #276 on: September 07, 2020, 10:20:53 am »
I'm a honest person, straightforward, you guys aren't, yet I'm the one being blamed.
I am to blame for not warning Oomek about the risks of interacting with you, but it all happened while I was on vacation.
Who warns about the near-impossibility for petty users of interacting normally with you guys? *shrug*
Would you interact better with people who are too low level if you had logs of them?
People who complain about me here have no idea anyway, surely none of them really read through anything, they're just discontent bc they see negativity so they assume: bad guy, wrong, does not fit, we want him out.
This makes a fine warning for whoever as a simple end-user like me, gets too enthusiast for a developer's projects and ends up involving himself too much, not casually but with his time and money, just take care; as devs they only want to interact with you if your topic happens to have some interest for their current project at a given point, but neither personal opinions nor criticisms, or one too much question are welcome no matter how rationally or kindly you try to pass them at first, and definitely not if you end up losing your cool and shout them, goes without saying.
If you do that, be ready for ostracism, you're forever the bad ungrateful oddball and everyone wants you out. Unfair? nobody will hear you, you're not a dev, not even a respectable high profile member of the community, not a power-user bc your skills lacking; you talk to the hand.
Say, what are you waiting for Calamity, just ban me, problem solved, tell yourself it's debugging!
I don't use time doing fellow flat-panel user support anymore, and with your latest feature update hardly anyone using such displays will need any serious help (main problem was vsync_offset, you solved it), and I said I don't report my findings anymore (issues, performance-bench, remarks, oddities, whatever) I've stopped doing that some time in '19 so I'm not useful at all for anything anymore, it's practically full circle at this point.
Congrats on the achievement by the way, even if I've grabbed that you aim for even higher than that, and how incongruous the moment is to say bravo! lol.  ;D

@oomek; sorry I wasn't convenient. bad casting. like I said; warn people in advance the next time or at the very least pay attention what they're asking you about if you want to avoid misunderstandings, and meeting bad angry - legitimately in my particular case but who cares eh? - inflexible dudes like me. Good luck with your project, trust it is sincere words or don't; but I know it's really good.

@Recap: no indeed he hasn't, but this time he did warn me, although as I've detailed in lenghts I said I find that rich. So he could very well kick my butt out, maybe he will have his first kill as a mod.
Oh come one do it or not I don't care, it's not like anyone's taking me seriously, you're just annoyed. *shrug*
A fact that will please you is that I really don't have anything much more to exchange about on the topic, I mean the whole topic of GroovyMAME.
The few remaining minor questions and requests I had, (lag measurements, OC slider modification, some tutorials addendums maybe) I've already wrote them here and there. Anything else beyond that is really too much out of Groovy's territory, I think, so I will annoy other people elsewhere. ELSEWHERE! Celebrate!  8)
« Last Edit: September 07, 2020, 10:30:38 am by schmerzkaufen »

donluca

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 261
  • Last login:Today at 08:49:51 am
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #277 on: September 07, 2020, 03:11:15 pm »
Has Calimity ever censored any post or banned any member? 'Cause if he hasn't, I can see some very unfair, defaming narrative being developed here.

He never has, afaik.

Although some matters should not be taken into public places and should remain in their own private conversations.

@oomek: just a little word of advice.
When you put out a product people will think you're a big company like Amazon and start pretending the same service.
If you really want to make the GILT a commercial product, "hire" someone to deal with your customers and stay the hell away from them or they're going to drive you insane.
I'm not referring to schmerzkaufen, just a word of wisdom from someone who's seen it happen over and over again.

The "build on request" and only to friends and/or people you know well about is a very wise choice.
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

Recapnation

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 332
  • Last login:December 01, 2023, 07:39:55 pm
    • Eiusdemmodi
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #278 on: September 07, 2020, 04:43:38 pm »
I'm aware. Just tried to make him understand that seeing this:

As maybe you're unaware I suffer from a chronic condition that leaves me with very limited time in between my symptoms, so I have to spend my time on my TODO list very wisely. I'm sorry that doing tests for you is not on top of my list.

...as "defamation" or a "very unfair narrative" is beyond any possible rationale, especially when you can then see that he's doing exactly that with Calamity, which wouldn't place him too well in this silly dramma. It's not material for this thread anyway, I agree (and I'm sure he agrees as well).


« Last Edit: September 07, 2020, 04:45:11 pm by Recapnation »

oomek

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 268
  • Last login:December 08, 2023, 02:31:38 pm
  • Mame forever.
    • https://github.com/oomek
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #279 on: September 07, 2020, 09:44:37 pm »
I was able to pinpoint the situation when the LUA script could cause an exception. This was only happening when the game was launched with an internal game selector. I was unaware that some people still use it. Anyway, it was just a matter of rearranging a few lines in the start_init() function. Fix pushed to github.
« Last Edit: September 07, 2020, 09:50:59 pm by oomek »