GroovyMAME 0.264 - Switchres 2.220b

[xbrunox]

Hi Calamity

pls can u explain which options we can use in display1.ini or in display0.ini and don't be better remove that options from mame.ini

[Calamity]

Hi Pakoman,

This is a good one, how comes 8-pixels blocks are not required anymore? (if it is long to explain, just don't bother, I don't want to waste your time here)

My tests back in 2007 with the old radeons showed that 8-pixel blocks were needed. This was probably a legacy feature from old VGA registers. Then some time ago, the user MrMikeZH pointed that pixel granularity worked for him, so I tried here and it seems to work on my current cards too both in Windows and Linux. Probably older cards don't support this feature, that's why -pixel_precision is optional. Setting it to 0 brings old 8-pixel granularity back.

So after all we might have used this much before, I just assumed it wasn't possible.

I'm a bit (very) disconnected but Toasty's patcher (cru and so) easily removes those limitations on stock drivers (or at least it did a couple of years ago!). It doesn't add the ability to accept custom resolutions on the fly, though.

I tried a few months ago, and the patches we're concerned with weren't found unfortunately. Now that CRU's source code is available, it'd be possible to adapt it to our needs, with Toasty's permission. This is something I'm planning to do at some point but I have too many fronts open.

[Calamity]

ATI/AMD ADL init
ERROR: ADL Initialization error!

Hi reeone,

Yes, in fact your card is using ADL. But now GM uses ADL2, and 12.6 is only compatible with ADL(1). This means 12.6 will now just work for legacy (pre-HD5000) cards (non-ADL). HD 5000+ cards will be forced to use 16.2.1. So we'll need to modify 16.2.1 files so it recognizes your card. It should support it already, but for some stupid reason Mobility models have usually been removed from the generic driver package. I only realise when someone with a Mobility card complains.

Well, to be honest I didn't anticipate this incompatibility with 12.6, but at least now people will move forward to 16.2.1 which works definitely better in general.

[Calamity]

Hi Calamity

pls can u explain which options we can use in display1.ini or in display0.ini and don't be better remove that options from mame.ini

You can use all the options from switchres.ini, here: https://github.com/antonioginer/switchres/blob/master/switchres.ini

The options in mame.ini are the default ones that'll apply to all displays that don't have overrides for them in specific display#.ini files.

The reason we're still keeping some of them in mame.ini, that might seem a bit messy, I admit, is because otherwise we would not be able to apply command line options and switches for these very needed features.

[R-Typer]

I just tried new switchres 2.0 and immediately noticed perfect horizontal centering of neogeo machines. Metal slug games are no longer off centered. Awesome!!!

BTW, I use Sony Trinitron CRT that has a mind of his own and is so unpredictable when screen centering is in question.

[schmerzkaufen]

Noice! gotta give this 'new generation' Groovy a try on various setups asap.

[Trnzaddict]

Hi Calamity -

So I have another arcade machine running a vertically oriented non VRR LCD monitor. It is 1920x1200, but I have created custom Nvidia resolutions @1920x1200 54hz-61hz.

So with the new SR engine, from what I understand with the LCD preset, defining the range and allowing HW refresh, will Groovymame still need to see those custom resolutions or can I delete them? From what I understood from the original post was the new engine will automatically adjust timings based on what your monitor is capable of refreshing at and do a much better job at getting a closer timing rather than old Groovymame?

[Calamity]

Hi Trnzaddict,

Well, not really, for the lcd preset to work as described in the changelog, GM needs to be able to read and write the actual timings from and to your gpu, and this on Windows is currently possible with AMD cards only. On Linux it applies to Nvidia and Intel too, but these have other issues.

[italospain]

Hi

after updating from 227 to 228 with the new switchres version i am not able to use the frame delay option.


i use the LCD auto Preset for my plasma-tv with an NVIDIA card

thanks for groovymame btw

greetings

[Calamity]

@italospain, you have -switchres disabled in mame.ini, there's no way GM can work like that (although it shouldn't crash, that's true). Anyway as I explained above, the *new* LCD autopreset is for AMD (with Nvidia -monitor lcd will just default to desktop's refresh as usual).

[italospain]

thank you
 
now it works like before.

can you give me a hint howto configure groovymame the right way for a plasma tv (1080p) that only supports 50 and 60 hz with nvidia ?

[xbrunox]

Hi all. I'm the only one that cant'use FFB plugin with new groovymame 0.228?

Calamity for use FFB plugin I must set output=windows


Is something change in new switches?

[Calamity]

Hi xbrunox,

Whatever change affecting input in 0.228 must have happened upstream, not in Switchres.

I don't know how the FFB plug works, the code in github looks like a dll wrapper. If it was a lua plugin, I would have thought the problem was caused by recent lua interface overhaul, but it's not likely the case.

[SuperMagoAlex]

Hi Calamity,

I've a problem with my 2 monitors setup.

This is my config:
- Intel i3 9100
- 8Gb ram
- Radeon R7 240 2Gb (3 output: VGA, DVI-D, hdmi)
- Win10 Pro 64 bit
- CRT Emudrivers 18.5.1
- Groovymame 0.228, Switchres 2.001b
- 1 TV Sony 15" connected to GPU's DVI-D via Scart-VGA cable + VGA/DVI-D adaptor
- 1 monitor Commodore 1084S (vertically rotated for vertical games) connected to GPU's VGA

If I connect one monitor at a time everything works perfectly, horizontal games on TV and vertical games on monitor.

If I connect the two monitors simultaneously and start a vertical game, on the vertical monitor the game goes at an accelerated speed, while if I start an horizontal game, I see the game with waves in the background on the horizontal TV.

What could be the problem?

[Calamity]

@SuperMagoAlex,

You need specific configuration in mame.ini to correctly map each display, please share your mame.ini and a log and I'll be able to help.

[SuperMagoAlex]

@SuperMagoAlex,

You need specific configuration in mame.ini to correctly map each display, please share your mame.ini and a log and I'll be able to help.

Hi, here you are log and ini files.

Thanks for you help

[Calamity]

@SuperMagoAlex,

Your problem with vertical games at accelerated speed is clearly caused by the waitvsync 0 line in your vertical.ini file. This prevents autosync from working, because vertical.ini has higher priority than mame.ini. So I'd just remove the whole "# OSD VIDEO OPTIONS" block. Besides, I'd say you need to add either autoror 1 or autorol 1 to vertical.ini for correct orientation.

With regards to the waves in the background with horizontal games, I can't see anything wrong in your configuration or logs.

[SuperMagoAlex]

@Calamity

Thanks for the info, vertical games runs fine now.

I noticed that turning off one of the two monitors, the wave interference disappears, so when I play vertical games I have to turn off the horizontal monitor and vice versa.

[Robbbert]

If the monitors are close to each other, and they are CRTs, the magnetic field from one can interfere with an adjacent monitor.

[Torkyo]

Hi Calamity,
thanks for this huge update.

I've got a question: I got an Hantarex polo star 28", I'm used to play vertical games rotated. Often such games go 25 or 31KHz with perfect timing and resolution thanks to its three frequencies feature.
I realised that after the switcher update (GM 0.228), vertical games, seems less defined. it is like a sort vague "super scale".
I compared the GM old and new for a specific game and I realised that the super resolution used are precisely the same. resolution and timing are the same. so apparently I think I should have the same visual outcome.
If it can help I can provide my GM ini for 0.225 and the last 0.228. as soon as I can.
BtW i tried to switch off the new feature "granularity" as it seemed pertinent to the problem so I did a try but it didn't help.
Have you got any idea about this issue?
thanks

[Torkyo]

here you are ini and log files for both 225 and 228.

thanks again

[tonyt76]

I cant find the triplebuffer option in the groovymame 0.228 mame.ini file?       

[Zebidee]

I cant find the triplebuffer option in the groovymame 0.228 mame.ini file?       

Would think you don't need it

[Torkyo]

I tried again to find the reason of this difference in vertical games between 225 and 228  shown at 31Khz. It seems there is something with unevenstretch functions of the new switcher. I mean, if I disable "unevenstretch", the game screen is reduced (of course) but the scrolling and the picture are perfect like groovymame 225.
I tried to change some other options of the 228 like "intoverscan"  "intscalex"  "intscaley". also the new "pixel_precision". Sadly no success.
I also gave a try to the standard resolution to see if that could help but noway.
IMHO it seems that the new switcher have a different behaviour to stretch vertical games.
I tried to read any difference 225 and 228 logs I posted above but I don't have the knowledge to spot something helpful.
Hope this may help a bit.
thanks

[Calamity]

@Torkyo,

The missing "feature" in SR 2 is to force "-filter" when unevenstretch is enabled. I removed this temporarily since it's d3d specific, until I decide what's the correct way to re-add it. If it's you really miss it I may re-add it.

[Calamity]

I cant find the triplebuffer option in the groovymame 0.228 mame.ini file?       

I also removed the multithreaded triplebuffer implementation of old GM, because it's d3d/Windows specific, and the new bgfx backend already implements multithreaded rendering, so the idea was to move to that api eventually.

Besides, the new automatic lcd preset (AMD) makes triplebuffer less necessary on LCDs because in theory you can use syncrefresh in most situations as now the correct refresh will be used. This allows using frame delay too in situations where before wasn't possible due to the use triplebuffer.

Anyway, again, if it's a much needed feature, I may re-add it.

[Torkyo]

@Torkyo,

The missing "feature" in SR 2 is to force "-filter" when unevenstretch is enabled. I removed this temporarily since it's d3d specific, until I decide what's the correct way to re-add it. If it's you really miss it I may re-add it.

thank you very much, Calamity!
Well, I really miss it. If you could re-add it, that would be really appreciated.
For vertical games using CRT 31Khz capable to draw many lines without interlace, I do think that the filter is a very good compromise

[RobeeJ]

Calamity, I really appreciate the work you do, and the unpaid time and effort you put in to this project.

Thank you!

[saint]

No bickering, fighting, name calling, genital-measuring, or other poor behavior, please.

Pretty please?

Just, no. Take it somewhere else.

Thank you.

[tonyt76]

I cant find the triplebuffer option in the groovymame 0.228 mame.ini file?       

I also removed the multithreaded triplebuffer implementation of old GM, because it's d3d/Windows specific, and the new bgfx backend already implements multithreaded rendering, so the idea was to move to that api eventually.

Besides, the new automatic lcd preset (AMD) makes triplebuffer less necessary on LCDs because in theory you can use syncrefresh in most situations as now the correct refresh will be used. This allows using frame delay too in situations where before wasn't possible due to the use triplebuffer.

Anyway, again, if it's a much needed feature, I may re-add it.

I don't use this option, I was just following recap's guide and couldn't find it.

[mode11]

Hi @Calamity. I noticed on a YouTube video of yours that you had 3 displays set up, with the two monitors being driven by an AMD GPU and the TV being driven by an Intel HD4600 iGPU. I'm interested in setting up a USFF system with just an i5 and Intel graphics - would Switchres 2.0 work with just the Intel iGPU, with no AMD GPU being present? If so, would this require Linux? I'm not really familiar with Linux, but could Batocera be used for this? 

[Sledge]

Wow looks like a lot has changed since i came here last..
I'm still somewhere back on win 7 with GM .207 maybe?
Wondering if i should update to Win 10 with new GM as well?
Worth it?
Looks like i'll have to learn it all over again haha

[beernut]

Having issues since SR2 on some vertical games on my D9200 monitor (linux)

Here is the log from sinistar for example:

Working switchres v0.017s from GM 0.226

Code: [Select]

SwitchRes: v0.017s, Monitor: custom, Orientation: horizontal, Modeline generation: enabled                                                                                                                                                                                 SwitchRes: Monitor range 15250.00-18000.00,49.00-61.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,224,288,448,576                                                                                                                                                             SwitchRes: Monitor range 20000.00-21500.00,49.00-61.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,320,360,0,0                                                                                                                                                                 SwitchRes: Monitor range 23900.00-29000.00,49.00-61.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,384,400,0,0                                                                                                                                                                 SwitchRes: Monitor range 29001.00-32000.00,49.00-61.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,400,512,0,0                                                                                                                                                                 SwitchRes: Monitor range 32000.00-35000.00,49.00-61.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,512,600,0,0                                                                                                                                                                 SwitchRes: xrandr version 1.6                                                                                                                                                                                                                                              SwitchRes: Found output connector 'VGA-0'

SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.017s:[sinistar] Calculating best video mode for 240x292@60.096153 orientation: rotated

SwitchRes: (   1)x(   1)_(60=60.000000Hz)
   rng(0):  728 x 544_60.096153i 17.878606 [fract] scale(2, 1, 1) diff(17.22, 0.00, 0.0000) ratio(3.033, 1.863)
   rng(1):  432 x 320_60.096153p 21.394231 [fract] scale(1, 1, 1) diff(1.23, 0.00, 0.0000) ratio(1.800, 1.096)
   rng(2):  536 x 400_60.096153p 26.682692 [fract] scale(1, 1, 1) diff(20.40, 0.00, 0.0000) ratio(2.233, 1.370)
   rng(3):  640 x 480_60.096153p 31.550480 [fract] scale(1, 1, 1) diff(33.33, 0.00, 0.0000) ratio(2.667, 1.644)
   rng(4):  736 x 552_60.096153p 34.675480 [fract] scale(2, 1, 1) diff(15.94, 36.07, 0.0000) ratio(3.067, 1.890)

SwitchRes: [sinistar] (1) vertical (240x292@60.096153)->(736x552@60.096153)
   rng(4):  736 x 552_60.096153p 34.675480 [fract] scale(2, 1, 1) diff(15.94, 36.07, 0.0000) ratio(3.067, 1.890)
SwitchRes: Modeline "736x552_60 34.675480KHz 60.096153Hz" 32.733652 736 768 872 944 552 553 557 577   -hsync -vsync
Switchres: CRTC 0: mode 0x57, 648x480+0+0.
Switchres: xrandr change screen size.
Switchres: xrandr mode (GM-736x552_60.096153) (0x6fe) 32.733652MHz
SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -noautoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -unevenstretch
SwitchRes: Setting option -nounevenstretchx
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -syncrefresh
SwitchRes: Setting option -waitvsync
SwitchRes: Setting option -filter
Available videodrivers: x11 wayland KMSDRM dummy
Current Videodriver: x11
        Display #0
                Renderdrivers:
                            opengl (0x0)
                         opengles2 (0x0)
                          software (0x0)
....
Adding monitor screen0 (736 x 552)
....

And the broken for me SR2.0 from GM 0.227 (same results on 0.228)
the screen locks up mostly black with a few lines of graphics on the top and requires switching consoles to reset monitor.

Code: [Select]

Available videodrivers: x11 wayland KMSDRM dummy
Current Videodriver: x11
        Display #0
                Renderdrivers:
                            opengl (0x0)
                         opengles2 (0x0)
                          software (0x0)
...

Enter init_monitors
Adding monitor screen0 (648 x 480)
Leave init_monitors

...
Switchres(v2.00) display[0]: monitor[custom] generation[on]
Switchres: Monitor range 15250.00-18000.00,49.00-61.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,224,288,448,576
Switchres: Monitor range 20000.00-21500.00,49.00-61.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,320,360,0,0
Switchres: Monitor range 23900.00-29000.00,49.00-61.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,384,400,0,0
Switchres: Monitor range 29001.00-32000.00,49.00-61.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,400,512,0,0
Switchres: Monitor range 32000.00-35000.00,49.00-61.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,512,600,0,0
XRANDR: <1> (xrandr_timing) creation (screen0)
XRANDR: <1> (xrandr_timing) checking X availability (early stub)
XRANDR: <1> (init) loading Xrandr library
XRANDR: <1> (init) loading X11 library
XRANDR: <1> (init) version 1.6
XRANDR: <1> (init) check screen number 0
XRANDR: <1> (init) check output connector 'HDMI-0' active 0 crtc 0
XRANDR: <1> (init) check output connector 'DVI-0' active 0 crtc 0
XRANDR: <1> (init) check output connector 'VGA-0' active 1 crtc 1 [SELECTED]
XRANDR: <1> (get_timing) mode 0057 648x480 refresh 60.000000 added
Switchres: [  1]  648x 480 @ 60p* : XRANDR timing "648x480_60 31.500000KHz 60.000000Hz" 25.452000 648 664 760 808 480 490 492 525   -hsync -vsync
XRANDR: <1> (get_timing) mode 0058 640x480 refresh 60.000000 added
Switchres: [  2]  640x 480 @ 60i : XRANDR timing "640x480_60i 15.750000KHz 60.000000Hz" 13.104000 640 664 728 832 480 484 490 525 interlace  -hsync -vsync
Switchres: get_mode(0) 292 240 60.096154 1.333333
Switchres: Calculating best video mode for 292x240@60.096153 orientation: rotated


Switchres: [ 648]x[ 480]_[60=60.000000Hz]
   rng(0):  out of range
   rng(1):  out of range
   rng(2):  out of range
   rng(3):  648 x 480_60.000000p 31.500000 [fract] scale(2, 1, 1) diff(31.69, 38.33, -0.0962) ratio(2.700, 1.622)
   rng(4):  out of range

Switchres: [ 640]x[ 480]_[60=60.000000Hz]
   rng(0):  640 x 480_60.000000i 15.750000 [fract] scale(1, 1, 1) diff(33.33, 38.33, -0.0962) ratio(2.667, 1.622)
   rng(1):  out of range
   rng(2):  out of range
   rng(3):  out of range
   rng(4):  out of range

Switchres: (   0)x(   0)_(0=0.000000Hz)
   rng(0):  728 x 544_60.096153i 17.878606 [fract] scale(2, 1, 1) diff(17.22, 0.00, 0.0000) ratio(3.033, 1.838)
   rng(1):  432 x 320_60.096153p 21.394231 [fract] scale(1, 1, 1) diff(1.23, 0.00, 0.0000) ratio(1.800, 1.081)
   rng(2):  536 x 400_60.096153p 26.682692 [fract] scale(1, 1, 1) diff(20.40, 0.00, 0.0000) ratio(2.233, 1.351)
   rng(3):  640 x 480_60.096153p 31.550480 [fract] scale(1, 1, 1) diff(33.33, 0.00, 0.0000) ratio(2.667, 1.622)
   rng(4):  432 x 296_56.634304pd 35.000000 [integ] scale(1, 1, 1) diff(0.00, 0.00, -3.4618) ratio(1.800, 1.000)

Switchres: rotated (292x240@60.096153)->(432x296@56.634304)
   rng(4):  432 x 296_56.634304pd 35.000000 [integ] scale(1, 1, 1) diff(0.00, 0.00, -3.4618) ratio(1.800, 1.000)
Switchres: Modeline "432x296_56 35.000000KHz 56.634304Hz" 19.460000 432 451 513 556 296 297 299 309  doublescan -hsync -vsync
XRANDR: <1> (add_mode) create mode SR-1_432x296@56.63
XRANDR: <1> (add_mode) mode 0707 432x296 refresh 56.634304 added
Switchres: added XRANDR timing "432x296_56 35.000000KHz 56.634304Hz" 19.460000 432 451 513 556 296 297 299 309  doublescan -hsync -vsync
XRANDR: <1> (set_timing) DISABLE crtc relocation
XRANDR: <1> (set_timing) crtc 0* [0057] 648x480+0+0 --> [0707] 432x296+0+0 flags [11]
XRANDR: <1> (set_timing) setting screen size to 432 x 296
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -nounevenstretch
SwitchRes: Setting option -nounevenstretchx
SwitchRes: Setting option -nowaitvsync
SwitchRes: Setting option -nosyncrefresh
Enter sdl_info::create
/dev/dri/card0 successfully opened
OpenGL: X.Org
OpenGL: AMD CEDAR (DRM 2.50.0 / 5.9.2-arch1-1-15khz, LLVM 10.0.1)
OpenGL: 3.1 Mesa 20.2.1
OpenGL: texture rectangle supported
OpenGL: non-power-of-2 textures supported (new method)
OpenGL: vertex buffer supported
OpenGL: pixel buffers supported
OpenGL: framebuffer object supported
OpenGL: GLSL supported, but disabled
OpenGL: max texture size 16384 x 16384
Leave renderer_ogl::create

...

Starting Sinistar (revision 3)
GL texture: copy 0, shader 0, dynamic 0, 292x240 292x240 [RGB32, Equal: 1, Palette: 0,
            scale 1x1, border 0, pitch 512,292/16384], bytes/pix 4
GL texture: copy 0, shader 0, dynamic 0, 292x240 292x240 [RGB32, Equal: 1, Palette: 0,
            scale 1x1, border 0, pitch 512,292/16384], bytes/pix 4
Average speed: 100.00% (2 seconds)
sdl_kill: closing audio
Enter sdlwindow_exit
Leave sdlwindow_exit
Switchres: exit
XRANDR: <1> (set_timing) DISABLE crtc relocation
XRANDR: <1> (set_timing) [WARNING] unexpected active modeline detected (last:[0707] now:[0057] 648x480+0+0 want:[0057])
XRANDR: <1> (set_timing) crtc 0* [0057] 648x480+0+0 flags [01]
XRANDR: <1> (set_timing) setting screen size to 648 x 480
XRANDR: <1> (delete_mode) remove mode SR-1_432x296@56.63
Switchres: success deleting mode XRANDR timing "432x296_56 35.000000KHz 56.634304Hz" 19.460000 432 451 513 556 296 297 299 309  doublescan -hsync -vsync

I'm sure it's some wrong or new setting I am missing or perhaps my modelines need fixing for 2.0

Code: [Select]


#
# OSD FULL SCREEN OPTIONS
#
switchres                 1
switchres_backend         auto
modesetting               1
modeline_generation       1
monitor                   custom
interlace                 1
doublescan                1
super_width               2560
changeres                 1
lock_system_modes         1                                                                                                                                                                                                                                                lock_unsupported_modes    1
refresh_dont_care         0
dotclock_min              0
v_shift_correct           0
pixel_precision           1
sync_refresh_tolerance    2.0
autosync                  1
screen_compositing        0
screen_reordering         0
allow_hw_refresh          0
modeline                  auto
ps_timing                 auto
lcd_range                 auto
crt_range0                "15250-18000, 49-61, 2.187, 4.688, 6.719, 0.190, 0.191, 1.018, 0, 0, 224, 288, 448, 576"
crt_range1                "20000-21500, 49-61, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 320, 360, 0, 0"
crt_range2                "23900-29000, 49-61, 2.910, 3.000, 4.440, 0.451, 0.164, 1.048, 0, 0, 384, 400, 0, 0"
crt_range3                "29001-32000, 49-61, 0.636, 3.813, 1.906, 0.318, 0.064, 1.048, 0, 0, 400, 512, 0, 0"
crt_range4                "32000-35000, 49-61, 1.000, 3.200, 2.200, 0.020, 0.106, 0.607, 0, 0, 512, 600, 0, 0"
crt_range5                auto
crt_range6                auto
crt_range7                auto
crt_range8                auto
crt_range9                auto

If I add the following to sinistar.ini then it works again like it did in sr 0.017s

Code: [Select]

resolution 736x552

So clearly something is off on my rotation settings. But almost every other vertical game works fine.  I'm ok just making the manual change above but am curious if there is something causing this that I can fix to avoid that issue on any other games matching sinistar's resolution.

Thanks in advance for any help sorting this.

[Calamity]

@beernut, turn off doublescan in mame.ini, that will fix it.

[Calamity]

GroovyMAME 0.229 is out.

What's new in Switchres 2.002a (March 2021)

- Fixed crash on emulated systems with 2 or more screens.

- Correctly update game video information after machine initialization.

- Properly account for refresh scaling & black frame insertion with frame delay.

[R-Typer]

yaaay! thank you Calamity!

[pakoman]

Thanks!

You got me hitting F5 for this one   

[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.