Groovymame 0.228 - Switchres 2.001b

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