Software Support > GroovyMAME
LCD Tearing with Variable Refresh
schmerzkaufen:
I'll be damned; another flat panel Groovy user posting here. Thought it would never happen. :o :lol
And so yes, confirming when using allow_hw_refresh you need frame_delay to be ON even if just at level 1, for vsync to work...
Which means depending on your system and X or Y game you're often gonna need to use a bit of vsync_offset too to get rid of tearing.
Lately I've had no speed nor sync issues with the 50~75Hz non-VRR monitor I typically use all the Groovy features with, using the latest 0.256 testing 'down' to Xexex or R-Type.
Also tested my compatible display extensively for Groovy using several AMD cards over the years so now I can tell rather quickly if something's actually not working right with a release.
But I can double-check again tomorrow to be sure.
It's indeed rather bad to lower the resolution, to improve performance I rather use simpler HLSL settings without fancy extra features like Bloom which is quite demanding.
Pushing high scanline brightness offset instead and building around, it looks less realistic and makes finding working values without uneven lines artifacts trickier, but I got used to it.
That said I've got a powerful system with modern components for playing current PC games to begin, wich is fitting because Groovy for flat panels (non-VRR but compatible like we're using) requires MUCH more CPU+GPU muscle than for CRTs.
I'm a sucker for efficiency so I don't max-out all the things I could, but if you are in a situation at the other end of the PC performance spectrum forcing you to sacrifice too much on quality and lag reduction to keep the framerates, it'd be a good idea to upgrade your dedicated PC components, indeed.
You don't need a 13900K nor a 7900XTX, no worries, but the kind of ancient PC hardware some ppl use in CRT mamecabs like HD 5000 cards and and Athlon or something just won't do here in this situation.
And yeah both the CPU and GPU count for our particular use case, so if you can; upgrade the former too.
Just going to bed now. G'night. * yawn *
PS: btw what is the current most powerful LP AMD ? Sapphire Radeon RX 6400 ?
DJO_Maverick:
--- Quote from: schmerzkaufen on July 19, 2023, 09:03:49 pm ---I'll be damned; another flat panel Groovy user posting here. Thought it would never happen. :o :lol
--- End quote ---
Yep; I studied quite a few old threads between you and Calamity about it before I poked my head out. Have to be honest, it wasn't a first choice; tried all I could to get the 'ole 27" CRT working again, but when it was clear it was dead and gone, it was just cost-prohibitive to gamble with getting a similar size TV/monitor brought cross-country... and this Phoenix monitor was coming out later the same week.
So re: the resolution... I agree conceptually/philosophically about not changing from the native resolution. The interesting glitch with that idea right now is that nobody knows what the native panel resolution on these ULM26 monitors actually is! While it seems to be a 'good' display for the niche, the manufacturer doesn't list it, and their community guy hasn't been able to dig it up yet. The control board they picked seems to be some Chinese off-the-shelf part that doesn't actually match the panel, per se, though it performs well. With best efforts, I haven't been able to determine what the panel resolution is with any confidence either. So... in the meantime... I don't feel very guilty about playing with the resolution!
At 1280x960, I've since dialed it in to work with all my glorious bloom, I believe with a V Offset of 215 (not looking at it) and a default frame delay of 3. While that gets rid of the consistent tear line, there's still a periodic, momentary tear/glitch here or there... MOSTLY ignorable (except to me). I'm guessing and assuming that's just going to be GPU-related and not much I can do about it until I swap the card.
As far as I can tell, yeah, the RX 6400 looks like the best option available. It's not THAT pricey, and appears to be a very significant upgrade. I may try to pick one up sometime soon.
And if you have any other good sources/recommendations about ideal (bloom-and-all) HLSL CRT sim settings for Groovy, would love to see them. I'm currently using a lightly modified version of this guy's settings: https://hyperspin-fe.com/forums/topic/25154-my-mame-0172-hlsl-settings/
DJO_Maverick:
PS, one more GM-LCD Noob question... do higher resolutions alter the way unevenstretch works? Taking CPS games for example, at oddball 384x224 (and yeah, understanding the PAR isn't 3:4, but well accepted they're supposed to be displayed at 3:4)...
On this new 4:3 monitor, if I curtail the resolution down to 1024x768, unevenstretch works as anticipated and fills out the 4:3 screen. If I launch the same games with a higher 4:3 resolution (like 1280x960, or 1600x1200), it will NOT fill the screen... in both of those cases, it appears to be doing the closest integer scaling only. Same INI as already posted.
Am I missing something...? I was under the impression unevenstretch is supposed to fractionally scale it up to fit the available screen real-estate, as limited only by aspect ratio. Shouldn't a 4:3 source stretch up to fit any 4:3 resolution?
Calamity:
Check -autostretch option, it's specific to GM. It will handle stretching automatically, choosing integer scaling when possible. That's why higher resolutions increase the chances that a suitable integer scale factor is found. You want it disabled if you prefer to have unevenstretch always on.
DJO_Maverick:
--- Quote from: Calamity on July 21, 2023, 04:39:12 am ---Check -autostretch option, it's specific to GM. It will handle stretching automatically, choosing integer scaling when possible. That's why higher resolutions increase the chances that a suitable integer scale factor is found. You want it disabled if you prefer to have unevenstretch always on.
--- End quote ---
Tried following your guidance here, but disabling it seems to have no effect. With unevenstretch 1 and autostretch 0, it still is performing identically at higher res for CPS.
Navigation
[0] Message Index
[*] Previous page
Go to full version