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 64101 times)

0 Members and 4 Guests are viewing this topic.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
  • Last login:March 23, 2024, 02:35:43 pm
  • Forking GroovyArcade
    • forum.arcadecontrols.com/index.php/topic,160023.0.html
    • GroovyArcade active fork
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #40 on: July 23, 2019, 10:55:49 am »
Got 2 vga2scart : one I made myself with schematics close to yours but partially adapted to a Pi for testing under Recalbox

For groovyarcade, I bought a vga2scart from retrocables.es which worked fine for me

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 #41 on: July 23, 2019, 11:06:16 am »
It's the same schematic. When it comes to vga2scart hdmi2scart be careful. Some adapters output composite only through scart and some have a scaler. You need pure DAC without any buffering.
« Last Edit: July 23, 2019, 12:20:21 pm by oomek »

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 #42 on: July 23, 2019, 11:36:25 am »
Radeon RX 460 -> hdmi2vga converter -> vga2scart cable
Defined resolution 2560x240@60 in CRU (no CRTemu driver installed)
Freesync ranges added 28-60
GM launched with everything off: triplebuffer, vsync, syncrefresh keepaspect
Tested 2 games shdancer 54.7Hz and thunderx 59.17Hz
All smooth, no stutter, or tearing, 100% emulation speed.

The photo of the adapter and the schematic of the cable is in my previous post.
Warning: scart2vga cable has different wiring. You have to make it yourself. I could not find any vga2scart on ebay only scart2vga

That's awesome!

Do you have any issues with vertical centering? Freesync keeps adding extra blanking lines until the retrace is requested, this in theory might cause the picture to be shifted up on a CRT since these are not designed to ignore those extra blanking lines.

Also, how do you force Freesync enabled on a CRT? CRU?
« Last Edit: July 23, 2019, 11:42:17 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

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 #43 on: July 23, 2019, 11:42:38 am »
So far vertical pos seems ok, but I need to test more games to be sure. I just got one issue very occasional frame jumps, like it's loosing vsync pulse, maybe my cable is not properly shielded? And constant vertical desync when I pause the game, this one is weird, any ideas?

Update: when pause is pressed the screen goes out of syync vertically, but when I release pause it turns stable for 1/2 second, but in ntsc mode, then it goes back to full screen.
« Last Edit: July 23, 2019, 12:01:10 pm by oomek »

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
  • Last login:March 23, 2024, 02:35:43 pm
  • Forking GroovyArcade
    • forum.arcadecontrols.com/index.php/topic,160023.0.html
    • GroovyArcade active fork
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #44 on: July 23, 2019, 12:02:06 pm »
It's the same schematic. When it comes to vga2scart be careful. Some adapters output composite only through scart and some have a scaler. You need pure DAC without any buffering.
The cabke from retrocables.es is not much different from the schemalics we have, takes power from USB and has a male jack for sound, no fancy electronics for scaling, synchro or whatever else.

VGA already outputs analog RGB, why need a DAC ?

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 #45 on: July 23, 2019, 12:03:59 pm »
Hdmi2vga = DAC

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 #46 on: July 23, 2019, 12:07:13 pm »
So far vertical pos seems ok, but I need to test more games to be sure. I just got one issue very occasional frame jumps, like it's loosing vsync pulse, maybe my cable is not properly shielded? And constant vertical desync when I pause the game, this one is weird, any ideas?

That's normal since the screen is not updated while in pause. Also occasional desync is not surprising since you're basing all video timing on the CPU timer which is not fully reliable. To make this absolutely perfect we could use freesync in combination with direct raster polling, for lagless vsync (not sure if this makes sense, I need to think about it).
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 #47 on: July 23, 2019, 12:11:02 pm »
Thanks, that all make sense, you're aware that this is the holy grail when it comes to running mame on a CRT :) Still can't believe it actually worked, playing various games now with a big smile on my face :D

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 #48 on: July 23, 2019, 12:15:52 pm »
You think HPET would work for that? Tweaking now vertical timings now to see if it makes any difference.

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 #49 on: July 23, 2019, 12:23:18 pm »
One more thing I've noticed. When I set frame delay > 0 the screen goes black

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 #50 on: July 23, 2019, 12:29:47 pm »
Restoring the use of QueryPerformanceCounter for the timer rather than crappy standard library might improve things a bit but CPU clocks are not good enough for this, you need to poll the raster position.

Please tell me how you forced Freesync, I want to test it here.
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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #51 on: July 23, 2019, 12:31:02 pm »
One more thing I've noticed. When I set frame delay > 0 the screen goes black

Frame delay can't work without syncrefresh the way it is now.
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 #52 on: July 23, 2019, 12:41:52 pm »


gm211 -aspect 4:3 -nowaitvsync -notb -noka -unevenstretchx -intscaley 1 shdancer

Freesync does not work in extended desktop mode (at least with a CRT), so prepare to switch a lot with Windows+P. I also failed to force GM to switch to my resolution switchres doesn't see it for some reason, So I've set the res with this tool to 2560x240@60
http://tools.taubenkorb.at/change-screen-resolution/


UPDATE 1: Don't forget to enable Freesync in Radeon Settings for your hdmi2vga dongle display device.

UPDATE 2: Set the refresh rates in all 3 places to 63Hz instead of 60Hz, otherwise 60Hz games will have tearing.
« Last Edit: July 24, 2019, 07:45:10 am by oomek »

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 #53 on: July 23, 2019, 04:36:47 pm »
What is the best desktop-like resolution I can get on RX 460 and a CRT without CRTEmu driver? Tried 576x480i but I think the pixel clock is too low. I don't actually understand what is the limiting factor, could you explain please?
« Last Edit: July 23, 2019, 04:42:03 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 #54 on: July 23, 2019, 05:29:28 pm »
(ordered a couple hdmi>vga dongles, I'm too curious about this, and it was time to put my 470 to test on CRT anyway)

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:March 21, 2021, 04:41:43 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #55 on: July 23, 2019, 08:31:05 pm »
Wow thats again truly amazing, next milestone happening here. Much respect!

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 #56 on: July 24, 2019, 05:21:12 am »
Please tell me how you forced Freesync, I want to test it here.

How is it going mate?

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 #57 on: July 24, 2019, 07:23:01 am »
Here's an update of my observations. Games like shinobi (60Hz) have tearing. Bumping the superresolution and both Freesync ranges in CRU to 63Hz fixes it.

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 #58 on: July 24, 2019, 07:28:36 am »
Here's an update of my observations. Games like shinobi (60Hz) have tearing. Bumping the superresolution and both Freesync ranges in CRU to 63Hz fixes it.

Yeah, I was about to post about this, I'll update in a while...
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: 7411
  • Last login:March 14, 2024, 05:26:05 am
  • Quote me with care
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #59 on: July 24, 2019, 02:06:01 pm »
Following Oomek's advice I've been successfully testing Freesync on a CRT using my new Ryzen 5 2400G, both by VGA and HDMI->VGA. My results so far show this can actually work with some effort. However once Freesync is enabled and MAME starts sending frames the screen starts to bounce up and down due to the random padding being applied. I haven't managed to get it stable. I'm testing this on a BVM. When tested on my regular PC CRT it just goes blank after a short period. I still need to compile a custom GM version that uses raster polling instead of the CPU clock to see if this makes it stable, hopefully in the next days.
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 #60 on: July 24, 2019, 03:34:00 pm »
Fingers crossed.
This thread took an unexpected turn, and I'll be glad if this goes well to have limited my used AMD cards acquisitions exclusively to models featuring FreeSync thinking 'you never know'.
Can all of them manage FreeSync via HDMI though ?

Arroyo

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1558
  • Last login:Today at 02:59:27 am
  • Budgets are boring
    • newforum.arcadecontrols.com/index.php/topic,156267.0.html
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #61 on: July 24, 2019, 08:25:25 pm »
Oomek, did you mention what CRT display you are using?

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 #62 on: July 24, 2019, 10:54:36 pm »
It's Bang&Olufsen Beovision1

Torkyo

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 34
  • Last login:November 29, 2023, 07:12:04 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #63 on: July 25, 2019, 11:53:00 am »
I'm wondering if G-Sync card/ monitor may have some benefit in this potential custom GM version

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 #64 on: July 25, 2019, 09:10:16 pm »
I've added a link in the first post to the spreadsheet that I'll be constantly updating with new measurements.


Arroyo

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1558
  • Last login:Today at 02:59:27 am
  • Budgets are boring
    • newforum.arcadecontrols.com/index.php/topic,156267.0.html
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #65 on: July 25, 2019, 11:38:36 pm »
URL no good in Tapatalk....

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #66 on: July 26, 2019, 04:46:11 am »
Are you planning to do a test for retroarch on windows too? Would be interesting.

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 #67 on: July 26, 2019, 04:47:51 am »
Sure, why not

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 #68 on: July 26, 2019, 05:10:05 am »
I've added a link in the first post to the spreadsheet that I'll be constantly updating with new measurements.
Oops, it's private, requires an account...

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 #69 on: July 26, 2019, 05:21:28 am »
Is the link working now?

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #70 on: July 26, 2019, 05:27:49 am »
Sure, why not
Looking forward for the results.
Would love to see the delay with snes cores. They always were laggier than most cores.
With groovymame set to frame delay of 7 i get input lag on super mario world that is as close to the real thing.
With retroarch i have to "cheat" and use run-ahead to get input lag as close as that.

Substring

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 816
  • Last login:March 23, 2024, 02:35:43 pm
  • Forking GroovyArcade
    • forum.arcadecontrols.com/index.php/topic,160023.0.html
    • GroovyArcade active fork
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #71 on: July 26, 2019, 05:30:18 am »
No idea how frame delay works, but run ahead was made toncompensate any input lag that naturally comes with emulators. The main problem is that its setup is complicated and requires frame by frame analysis for each core

Foxhole

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 287
  • Last login:March 04, 2024, 04:36:28 pm
  • I want to build my own arcade controls!
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #72 on: July 26, 2019, 05:37:45 am »
No idea how frame delay works, but run ahead was made toncompensate any input lag that naturally comes with emulators. The main problem is that its setup is complicated and requires frame by frame analysis for each core
I was under the impression that runahead compensates for input lag that is naturally occuring in the game itself, not the emulator.

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 #73 on: July 26, 2019, 05:54:12 am »
Is the link working now?
Yup!  ;)

No idea how frame delay works, but run ahead was made toncompensate any input lag that naturally comes with emulators. The main problem is that its setup is complicated and requires frame by frame analysis for each core
There is no 'natural delay that comes with emulators', each and every case is a delay chain that can be explained taking into account the hardware/game that's emulated, then what's used for generating video and the options for sync. The issue with run-ahead isn't that it's not capable but rather that it doesn't mind any of that and is therefore often misused.
It gets much more complicated with arcades emulation where the many game's inherent lag figures aren't known (you won't find a reliable database with measurements, just random statements) and even more so when RetroArch is involved because of its several features other than run-ahead that can each play a part. Compared to Groovy that means many added variables, some people combine run-ahead (or try to) with other features like hard gpu sync, RA's own frame_delay, some even disable all vsync, some use Vulkan, etc etc.
Add to that the general confusion of it's massive pool of users and you know lag reduction with RetroArch works but is a complete black hole of a mess in terms of accuracy, if oomek starts measuring lag in RA then good luck to him taking all that into account.
Features like frame_delay however (at least as its implemented in Groovy) or FreeSync, are better known quantities - and even more so now thanks to oomek's work - that guarantee to not hamper accuracy at the very least (they eliminate lag that's on top of the emulated games, working on things like video sync buffer frames or inputs polling, not the game's inherent/natural delay which remains untouched)

I was under the impression that runahead compensates for input lag that is naturally occuring in the game itself, not the emulator.
As I've worded just up there, it completely depends on the (too-many in RA) settings that have an influence on the matter, run-ahead can either eliminate only the superfluous/eyesore delay, or be pushed further to eliminate the game's legit delay too.
If RA had a 'delay accuracy safeguard' optional program that takes everything into account, its choices for lag reduction wouldn't be so controversial.
Problem is a portion of the RA demographics argues that it's okay to eliminate even the legit delay (some go as far as deny it even exists), I guess that somehow supports the libretro devs into leaving things as they are...
« Last Edit: July 26, 2019, 06:24:52 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 #74 on: July 26, 2019, 06:42:38 am »
Run-Ahead is a hack and per core/game optimization. The aim of my tests is to measure the latency that only the graphics API introduces. If I start comparing Groovy to Libretro I'm not gonna be touching run-ahead, but only driver related settings.

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:March 21, 2021, 04:41:43 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #75 on: July 26, 2019, 06:48:37 am »
Run ahead for itself is just the removeval of full legit delayed frames, done with savestates.
For me it feels wrong (not laggy just somehow wrong and not like it should feel) like with the lag compared with original hardware.
Only gm gives perfect feeling and its too bad if one can sense the smallest differences with input behavior.
Hell from my point of view (correct me anyone), the main thing for a good feel is that d3d9ex thing which is only used in gm so far right? The next thing would be freesync and theres no newd for more right?


Can one set the freesync range for each modeline? Like for 60hz modelines having a range 58-61hz, so when the timing goes off like a spike to 57hz or when you pause the emulation etc, the frames would be duplicated to keep 58hz and the picture would not shake or go crazy/blank?
« Last Edit: July 26, 2019, 06:54:40 am by MrMikeZH »

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 #76 on: July 26, 2019, 06:59:13 am »
I agree. The delay that is a part of a game core is not my concern. To be honest I still don't fully understand the exact mechanism of run-ahead, but I have a feeling that you miss some frames when an input is triggered.

According to my tests the advantage of D3D9ex version only manifests with -fd 0 and Freesync OFF. Both versions are faster than baseline with Freesync ON and with with Freesync OFF when -fd > 0 This is a bit unexpected surprise to me.

To use freesync you only make one resolution with a refresh rate that is bigger than the maximum games refresh rate. I have defined a resolution @75 hz and it covers all games that have lower refresh. When it's higher you get tearing as freesync is disabled in that case.
« Last Edit: July 26, 2019, 07:53:51 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 #77 on: July 26, 2019, 07:00:54 am »
Run ahead for itself is just the removeval of full legit delayed frames, done with savestates.
Nope, again it can eliminate both the extra we of course don't want, and the game's legit along if you set run-ahead too high. Both, that's the issue with it.

Hell from my point of view (correct me anyone), the main thing for a good feel is that d3d9ex thing which is only used in gm so far right?
With d3d9ex there's supposedly only one frame left on top of the game's, but by oomek's first posted test it looks like this is true in this case only if frame_delay is on (at minimum 1).
But maybe I've read that wrong.
Then if you can push frame_delay high-enough even that frame gets shrinked bit-by-bit until there's like only 2ms left between you and the game.
Personally I'm already super happy with frame_delay at 5 and up (only about half-a-frame of delay left)

The next thing would be freesync and theres no newd for more right?
Holy Grail as oomek rightly said.
« Last Edit: July 26, 2019, 07:26:32 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 tests 2019 (new method)
« Reply #78 on: July 26, 2019, 07:23:15 am »
Would love to see the delay with snes cores. They always were laggier than most cores.
With groovymame set to frame delay of 7 i get input lag on super mario world that is as close to the real thing.
With retroarch i have to "cheat" and use run-ahead to get input lag as close as that.

What's your RA configuration without run-ahead (video driver, hard GPU sync, video hard sync frames, video frame delay, video max swapchain images...)? Which SFC/SNES cores have you tried?

« Last Edit: July 26, 2019, 07:25:29 am by Recapnation »

MrMikeZH

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 48
  • Last login:March 21, 2021, 04:41:43 pm
Re: GroovyMAME - Input Lag tests 2019 (new method)
« Reply #79 on: July 26, 2019, 07:26:11 am »
I agree. The delay that is a part of a game core is not my concern. To be honest I still don't fully understand the exact mechanism of run-ahead, but I have a feeling that you miss some frames when an input is triggered.

According to my tests the advantage of D3D9ex version only manifests with -fd 0. Both versions are faster than baseline for freesync and with fd > 0 This is a bit unexpected surprise to me.

To use freesync you only make one resolution with a refresh rate that is bigger than the maximum games refresh rate. I have defined a resolution @75 hz and it covers all games that have lower refresh. When it's higher you get tearing as freesync is disabled in that case.


Interesting, so the odd feeling i got with run ahead could be the missing frames (the movement on the screen apart from your controlled sprite which dont move if legit delayed frames are missing).

So how can we get freesync to not stress our monitors to death when going out of sync?