Software Support > GroovyMAME
The input lag issue in the context of emulation [about new -frame_delay option]
Dr.Venom:
Hi Calamity,
I've stumbled upon an issue with GroovyUME. I'm currently (only) using tweaked Soft15Khz modelines in my system and I'm (only) making use of the 'switchres' functionality of GroovyUME 0146u4 (modelines=0). The settings that I use are :
- waitvsync=1
- throttle=1
- multithreading=1
- changeres=1
- switchres=1
- Display on my secondary (15Khz) monitor
This works very nice (smooth scrolling and ingame screen switching for genesis, snes etc..) with all mame/mess machines.
Now, recently I thought I'd try the "Syncrefresh=1" option. But if I use this option in combination with the above settings then GroovyUME runs very much too fast! :-/ I also tested the exact same settings on latest 0147u2 official UME (ofcourse without the 'changeres=1' functionality), but then it runs at correct (smooth) speed.
The testcase was with Genesis emulation, but it also seems the case for other systems. Some information on my setup: I have setup a PC with two graphic cards (first slot AMD HD 7870 and second slot HD4850) and two monitors. First monitor is a LED and the second is a 15Khz monitor.
Any idea why adding the syncrefresh=1 setting to the existing config, is causing GroovyUME to run way too fast? Hopefully it's something that can be resolved.
Calamity:
When using -syncrefresh, GroovyMAME/GroovyUME relies exclusively on the vertical retrace signal in order to throttle the game. So a crazy speed when using -syncrefresh usually means no proper vsync is reported by the hardware. This is often caused by DirectDraw's hardware acceleration being disabled (see dxdiag, screen tab), which in turn can be due to a badly installed video driver, or a mirror driver installed by some remote control app like RealVnc (http://forum.arcadecontrols.com/index.php/topic,113382.msg1310183.html#msg1310183), even cloning the desktop over two monitors with different specs might be the issue. You can try using -video d3d too.
The odd thing here is that you stated you were getting smooth scrolling with the above settings. I'm almost sure that what you've seen was only almost-smooth scrolling. The only way to get truly smooth scrolling with GroovyMAME is by means of the -syncrefresh option.
Dr.Venom:
I don't think it's related to a driver installation issue, as I don't have problems with other emulators like WinUAE (low latency vsync), bSNES, and others. But nonetheless, I've been digging deeper into the matter, taking your suggestions into account, and have some interesting findings. I created a clean ume.ini (GroovyUME -cc) and only changed modeline=0 and put my rom paths in.
All testcases are done by starting the genesis emulation with the game Mega Turrican (US), as it nicely switches a few times at start between manufacturer logo, title screen and game.
The first thing I did was remove the HD7870 from my PC, to test *only* with the HD4850 installed. This gave the identical results (GroovyMAME running too fast when using syncrefresh). This rules out the possibility that it has something to do with multi-gfx-card setup or cloning/spanning of desktops over multiple monitors.
The second thing I did was testing with different ATI Catalyst driver versions. I've been testing a number of different drivers from the latest AMD 12.6 driver, back to the ATI versions from a few years ago (10.3) and a few versions in between. They all resulted in GroovyMAME running too fast with syncrefresh. Just being safe, I checked dxdiag with all all the drivers, and they were all properly installed with 2d hardware acceleration enabled. These driver tests pretty much rule out its a (specific) driver issue. (Which was a bit to be expected since I have no issues with other emulators).
Then I got the idea to disable switchres in ume.ini, keeping everything else the same, so that it would open its screen on my desktop setting 740x240@60hz, and guess what? It ran smoothly! Hmm... so that got me thinking, it seems to have something to do with the particular resolution used. So then I started setting my desktop to various resolutions, and found out that the ones that had a vertical resolution of 224 resulted in GroovyUME running too fast with syncrefresh, but the resolutions of vertical 240 or above didn't show the problem.
To try to pinpoint the problem even more I set the switchres option back to 1 in UME.ini, but now doing testcases with *only* four modelines installed on my system. The only difference between them being that they alternately have a 224 or 240 *visible* vertical resolution (but note: refresh rates are exactly the same!)
[1] modeline "320x224x60.00 (Genesis)" 6.72 320 341 372 426 224 236 239 263 -hsync -vsync
[2] modeline "320x240x60.00 (Genesis)" 6.72 320 341 372 426 240 243 246 263 -hsync -vsync
[3] modeline "640x224x60.00 (Genesis)" 13.44 640 682 744 852 224 236 239 263 -hsync -vsync
[4] modeline "640x240x60.00 (Genesis)" 13.44 640 682 744 852 240 243 246 263 -hsync -vsync
I've logged four testcases; testcase one starts out with the above four modelines (groovymame prefers them from top to bottom), and then removing one modeline at a time from the system (reboot, test, etc...). So that in each testcase it will pick the next modeline.
I've attached the full logs in the zip. The summary is as follows:
[1] 320x 224@ 60Hz : GroovyUME runs into the problem of running too fast with syncrefresh (Average speed: 177.24%)
--- Code: ---blit_lock = TRUE
DirectDraw: Configuring device ATI Radeon HD 4800 Series
Target refresh = 60.000000
DirectDraw: Selecting video mode...
320x 224@ 60Hz -> 3000.000000
320x 240@ 60Hz -> 1058.823530
640x 224@ 60Hz -> 1003.115265
640x 240@ 60Hz -> 1002.967359
DirectDraw: Mode selected = 320x 224@ 60Hz
DirectDraw: primary surface created: 320x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 320x224
DirectDraw: blit surface created: 320x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
blit_unlock = TRUE
window_proc: WM_PAINT
blit_lock = FALSE
window_proc: WM_PAINT:END
Average speed: 177.24% (19 seconds)
--- End code ---
[2] 320x 240@ 60Hz : It works correctly with syncrefresh!
--- Code: ---blit_lock = TRUE
DirectDraw: Configuring device ATI Radeon HD 4800 Series
Target refresh = 60.000000
DirectDraw: Selecting video mode...
320x 240@ 60Hz -> 1058.823530
640x 224@ 60Hz -> 1003.115265
640x 240@ 60Hz -> 1002.967359
DirectDraw: Mode selected = 320x 240@ 60Hz
DirectDraw: primary surface created: 320x240x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 320x224
DirectDraw: blit surface created: 320x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
blit_unlock = TRUE
window_proc: WM_PAINT
blit_lock = FALSE
window_proc: WM_PAINT:END
Average speed: 97.19% (29 seconds)
--- End code ---
Note that it does not report 100% on average speed because of the screen switching it is doing, but I can assure you that it is running correct/smooth in between the switches.
[3] 640x 224@ 60Hz : Again (just like testcase 1) with the 224 pixels vertical resolution, GroovyUME runs too fast with syncrefresh on (Average speed: 180.73%)
--- Code: ---blit_lock = TRUE
DirectDraw: Configuring device ATI Radeon HD 4800 Series
Target refresh = 60.000000
DirectDraw: Selecting video mode...
640x 224@ 60Hz -> 1003.115265
640x 240@ 60Hz -> 1002.967359
DirectDraw: Mode selected = 640x 224@ 60Hz
DirectDraw: primary surface created: 640x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224
DirectDraw: blit surface created: 640x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
blit_unlock = TRUE
window_proc: WM_PAINT
blit_lock = FALSE
window_proc: WM_PAINT:END
Average speed: 180.73% (22 seconds)
--- End code ---
[4] 640x 240@ 60Hz: It works correctly with syncrefresh!
--- Code: ---blit_lock = TRUE
DirectDraw: Configuring device ATI Radeon HD 4800 Series
Target refresh = 60.000000
DirectDraw: Selecting video mode...
640x 240@ 60Hz -> 1002.967359
DirectDraw: Mode selected = 640x 240@ 60Hz
DirectDraw: primary surface created: 640x240x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 640x224
DirectDraw: blit surface created: 640x224x32 (R=00FF0000 G=0000FF00 B=000000FF)
blit_unlock = TRUE
window_proc: WM_PAINT
blit_lock = FALSE
window_proc: WM_PAINT:END
Average speed: 96.04% (20 seconds)
--- End code ---
To me these results suggest that there's possibly an issue with the way GroovyUME handles/calculates the really low vertical resolution (< 240?) cases. What do you think?
At least hopefully this will bring us closer to pinpointing the problem and finding a solution.
Calamity:
Thanks for doing this detailed test. It's very strange that two almost identical modelines behave so different. Your setup happens to be one that I hardly ever test myself: the one with the -modeline option disabled.
I'd perform the following tests before going on:
- Try switching to video d3d just in case
- Try disabling the -changeres option
- Try disabling -multithreading
The problem could be that because of the resolution switch, the display didn't complete its setup the second time for some reason so the vysnc signal is not available. But it''s strange that it doesn't happen always.
We also need to make sure that those modes are actually properly formed by the system. Please launch Arcade_OSD (it's in the CRT_Emudriver download), so you can test each of those modes full screen and perform a speed measurement in order to find if the vsync signal is actually supported. Once you make sure everything is fine we can focus on the possible issue in GM.
Dr.Venom:
--- Quote from: Calamity on November 07, 2012, 11:57:35 am ---Thanks for doing this detailed test. It's very strange that two almost identical modelines behave so different. Your setup happens to be one that I hardly ever test myself: the one with the -modeline option disabled.
--- End quote ---
Yes I also would rather use -modelines, but unfortunately I'm on Windows 7 64-bit and haven't been able to get that option running. Since I gathered that it also isn't supposed to work without the CRT_Emudriver, I've focused myself on getting GroovyMAME to run with the Soft15Khz modelines. Which is great btw, apart from the mentioned issue with the syncrefresh.
--- Quote ---I'd perform the following tests before going on:
- Try switching to video d3d just in case
--- End quote ---
This works (correct speed), but unfortunately it has a short sound glitch (pitch shift) upon screen switches, plus very small graphic glitches. (These don't happen in ddraw).
--- Quote ---- Try disabling the -changeres option
- Try disabling -multithreading
--- End quote ---
Both make no difference.
--- Quote ---The problem could be that because of the resolution switch, the display didn't complete its setup the second time for some reason so the vysnc signal is not available. But it''s strange that it doesn't happen always.
--- End quote ---
Yes indeed.. Are there any recalculations done in the code based on screen dimensions to track the refresh rate? Or does it (try to) poll the screen rate shortly? (Or both?)
--- Quote ---We also need to make sure that those modes are actually properly formed by the system. Please launch Arcade_OSD (it's in the CRT_Emudriver download), so you can test each of those modes full screen and perform a speed measurement in order to find if the vsync signal is actually supported. Once you make sure everything is fine we can focus on the possible issue in GM.
--- End quote ---
I've run Arcade_OSD and done the speed measurements per screenmode (5/coin). The results are:
320x224 -> 60.002 hz
320x240 -> 60.001 hz
640x224 -> 60.005 hz
640x240 -> 60.006 hz
Also with every screen when doing the speed test, the rastered background is scrolling very smoothly (nice feature btw :) ). I guess this confirms that the screenmodes are ok?
Navigation
[0] Message Index
[#] Next page
Go to full version