Software Support > GroovyMAME
LCD Tearing with Variable Refresh
DJO_Maverick:
So I recently migrated to an LCD after shorting out the tube in my cab, and am working out the kinks...
I got one of the new Unico Phoenix 26 monitors, and while it's not recognized as Freesync capable by the driver, it will properly sync to any frequency I've thrown at it so far. I've got Groovymame set up with lcd_range 54-61 and allow hw refresh on, and it certainly appears to be working as intended; monitor is reporting expected frequency for every odd game I've thrown at it. And yet...
Groovy is consistently giving an intermittent tear line, in any game I've tried, about 20% down from the top of the screen. I know there are some old threads beating this to death, but it's been a while, and some of the advice seemed a bit cryptic.
Fiddling with frame_delay does not appear to affect it. Likewise, if I fiddle with the Vsync_Offset slider, it appears to have no visible effect on the line. Mainline doesn't tear, but, that has other tradeoffs, of course.
I know it's a common issue; is there a consensus on the best way to troubleshoot it these days?
Thanks,
DJO_Maverick:
Adding current ini and a couple of token logs as well. INI was originally set up to use the dummy resolution/refresh rate before I switched to the LCD range method, so there's some legacy stuff in there... and I've got HLSL disabled until I can at least sort the tearing without it.
And PS: is there any advantage/disadvantage to using the new lcd_range and hw_refresh method versus the legacy 'dummy resolution' method with a CRT range for the LCD monitor? If not, wondering if maybe I should go back to the old ways just to avoid the notification sounds.
Calamity:
Hi DJO_Maverick,
Your configuration and logs look correct. Both methods, allow_hw_refresh and dummy resolution are equivalent.
I'm trying it here right now, and I get like 1.5 cm of tearing on top of a 32" lcd, which can be removed with fd + vsync_offset. But I'm using an R9 270 here. So it could be your R7 isn't fast enough for tearfree rendering at 1600x1200. Just an idea.
DJO_Maverick:
Thanks for the response. I've actually kept at it with troubleshooting and I'm sure you're right on the resolution-
Dropped overall resolution to 1280x960, which had a similar tear factor to what you describe. Then with bumping from Framedelay 0 to 1 and a VSync Offset of 85, managed to eliminate tearing without HLSL. Now proceeding to tweak further to get it working without tearing. Led to a couple of additional questions that I'm fuzzy on:
- Is having some degree of Framedelay a prerequisite to VSync Offset having any effect? Seems to not do anything with it off-
- It seems like with some games (taking RType for example), which is properly running at 55hz... going from Framedelay 0 to 1 ratchets it up to turbo mode. I have to push Framedelay up to 3 or 4 to push it back down to normal running speed. Is that expected behavior?
Sounding like maybe I should just bump up the card a bit, but limited by a low profile slot.
Calamity:
--- Quote from: DJO_Maverick on July 19, 2023, 01:11:18 pm ---- Is having some degree of Framedelay a prerequisite to VSync Offset having any effect? Seems to not do anything with it off-
--- End quote ---
Correct. Frame delay is required for vsync offset to be considered. This isn't obvious and I had to check the code now to answer, because it's been a long time since I touched that.
--- Quote ---- It seems like with some games (taking RType for example), which is properly running at 55hz... going from Framedelay 0 to 1 ratchets it up to turbo mode. I have to push Framedelay up to 3 or 4 to push it back down to normal running speed. Is that expected behavior?
--- End quote ---
This is an issue I thought that was already fixed, but maybe it's gpu speed dependent, so I only fixed it here. It's just a matter of increasing fd as you say, but not desired behaviour.
I didn't mean that you lowered the resolution, because on an LCD you should always use the native panel's resolution. But the fact that it helped solving the issue points to the gpu speed as the culprit here.
Navigation
[0] Message Index
[#] Next page
Go to full version