Software Support > GroovyMAME
GroovyMAME 0.287 - Switchres 2.22b
R-Typer:
yaaay! thank you Calamity!
pakoman:
Thanks!
You got me hitting F5 for this one :D
beernut:
Calamity,
Thanks. That fixed Sinistar. Any reason to keep doublescan in my ini for other games or with my D9200 is it not necessary. So many video options.
Appreciate the help and GM in general.
schmerzkaufen:
Q: so is triplebuffer gone for good or do you have plans for either adding it back, or maybe not in SR2 Groovy but in future Legacy (SR1) builds ?
For now SR2 Groovy is pretty much a no-go for playing the way-off 60Hz games on a non-VRR/non-Emudriver compatible flat panel,
unless it's for ppl who don't mind either tearing or much accelerated gameplay for games like Raiden II or the MK series.
At present on anything but a dedicated compatible setup for playing that kind of games decently, one's stuck with Legacy (SR1) 0.227 which is the last to feature the Groovy-only faster triplebuffer.
Also on that topic I was wondering; if it's not coming back, what use is there for the sync_refresh_tolerance setting now ?
Calamity:
I still need to take a decision with regards to triplebuffer. To answer your question: the functionality of triplebuffer (i.e. tear-free asynchronous flipping) is supported natively by modern OpenGL and DirectX, but not by D3D9ex. So, for sure, GM will have its "triplebuffer" one way or another. I'd rather have it through modern api than custom ad-hoc implementation, but in case this proves to be impractical or takes too long, I'll readd it.
As I explained, as long as you have an AMD card, not necessarily with CRT Emudriver, just stock drivers and a normal LCD, you can benefit from the automatic lcd preset, which is waaaay better than triplebuffer since it allows the use of frame delay.
The purpose of sync_refresh_tolerance still holds, just changes -triplebuffer by -nosyncrefresh. Besides, this option also has a purpose in modeline scoring.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version