Help needed to setup GM for use with LCD monitor

[big10p]

Hi

I don't have a CRT display but would like to use groovyMAME with my 1080p LCD monitor, mainly to take advantage of the reduced input lag I understand it offers.

Can someone please point me in the direction of where I can read up on how to do this, and what all the switchres options do in the mame.ini? I have no idea what a modeline is, for example.  Any other tips for using an LCD appreciated.

Thanks in advance.

[Calamity]

Hi big10p,

Basically, you only need to edit mame.ini and set "monitor lcd" and the "aspect" option with your actual monitor's aspect ratio, e.g. "aspect 16:9". This later step is crucial.

If you want the lowest input lag you need to enable set -frame_delay option with a factor higher than 1 (ranges from 1 to 10, the higher the better). However you will get static tearing with this option and LCD screens, there's no solution for this unfortunately.

[big10p]

Thanks for the help, Calamity.

I'm playing using my own 1920x1080 artwork, and for some reason, Galaxian runs with a black border at the top/bottom of the screen. All other games I've tested display fine. Not sure what's causing this, though Galaxian was the game I was first testing GM with. I deleted galaxian.cfg but to no avail. Any ideas?

As for frame_delay, does GM need this set higher than 1 to get any reduction in input lag, or is there some lag reduction 'built-in' to GM, too?

Thanks again.

[adder]

Hi Calamity can i ask a couple of frame delay questions here:

im thinking of just setting frame delay to '2' for every game and not worry too much about going any higher. i still dont really understand how frame delay works though as im a right slowmo with all this stuff so my question is, let's say i had a game i can run with my pc/groovy setup at 100%, but only just.. so ie. if i tried to run it at max unthrottled speed i only hit, say, 103%.. is frame delay set at '2' ok in this case, ie. i wont see/encounter any problems?
also im curious if you know the answer: if i was running a game with frame delay set to '2', but my pc/groovy setup was not breaking a sweat and in fact i could increase the frame delay value to something like '7'.. what kind of reduction (in milliseconds) in input lag would i see there? just wondering if we are talking a very low amount of milliseconds, in which case i think i would just leave frame delay set at '2' for everything and not worry about gaining just a small handful of extra milliseconds

[cools]

Not sure if Calamity worded it badly above or not, but the important bit is simply to have frame delay enabled. Set it to 1.

Read the other lag threads for results of tests with higher values.

[Calamity]

The logic that led to the -frame_delay option was discussed here: http://forum.arcadecontrols.com/index.php/topic,128993.msg1313217.html

Initially, -frame_delay was implemented to theoretically help removing 1 frame of lag by "delaying" the emulation of the next frame as much as possible, ideally right before or during the vblank period. This would allow to get the most up-to-date input state before going into the emulation itself. The "technical" problem involved is that it would require a cpu that's fast enough to emulate each frame at a fraction of the time that the original hardware did. A crude estimation was done that the cpu should be able to keep the speed above 1250% steadly when running unthrottled for the intended effect to be achieved. Then it was suggested to implement this option with gradual steps from 1 to 9,  where 1 stands 10% of a frame period, and 9 stands for 90%, so one could adapt it to get the longer possible delay with the current hardware.

So theoretically, using -frame_delay 1 would be almost equal to not using -frame_delay at all, just 10% more chances of catching the input in time for the next frame.

BUT, surprisingly, the way -frame_delay was implemented (when used with ATI cards and d3d) has an unexpected side effect: it bypasses a frame queue that the drivers secretly arrange when vsync is used. It turns out this frame queue adds a lag of 2-3 frames by itself, so bypassing it has a massive effect in input responsiveness, way more important that the one that was originally intended by the -frame_delay implementation.

That's why by simply enabling -frame_delay with 1, most of the perceived input lag disappears. The extra gain that would come from raising from 1 to 9 only translates to the last remaining frame of lag, and only statistically (e.g. it may help with 33% of the total frames), and probably may only be detected by recording a high speed video, and only on already highly optimized systems.

[adder]

ah ok great thanks for that, im getting it now finally i think haha i will keep reading up also, cheers!

[big10p]

If you want the lowest input lag you need to enable set -frame_delay option with a factor higher than 1 (ranges from 1 to 10, the higher the better). However you will get static tearing with this option and LCD screens, there's no solution for this unfortunately.

It's a shame but this turned out to be a deal breaker, for me. I can't live with the static tearing. Oh well.

Just out of curiosity, I notice a difference in Galaxian in GM and regular MAME: in GM, the background stars are short, vertical lines, but in ordinary MAME, they're single points/pixels. Also in GM, the yellow, player ship bullet is longer and extends further down into the ship graphic (if you see what I mean). I just wondered why the difference, and which one is correct?

[twistedsymphony]

I'm working on getting GM setup in a new LCD cab of mine... if I'm reading this thread correctly... for the lowest lag I should:

set "monitor" to "lcd"
set "aspect" to "16:9"
and set "frame_delay" to at least 1 but as high as 10 if my hardware can support it.

is that correct?

I should also note I'm running HLSL to emulate scan-lines and other CRT features... does this change the optimal settings for low lag?

Tearing Sucks, and lag sucks but I'm mostly concerned with smooth scrolling. I can deal with a frame or two of lag and a little bit of tearing but I'd really like scrolling to be smooth.

For reference I'm running Win 8.1 64-bit with a 3.4GHz i3 an an nVidia GTX580 out to a Samsung UN32EH4003  (60Hz 1366x768 display)

[Calamity]

HLSL doesn't change the optimal settings. The settings you suggested are fine.

Tearing will happen on an LCD or CRT when using a high resolution whenever you use -frame_delay and Direct3D. It will be mostly static tearing: scroll will be smooth but you'll have a stripe at a random fixed height of the screen.

[twistedsymphony]

Thanks for the clarification 

[MikeNZ]

Hi guys.
New here so I'll probably be asking a few of my own random questions in the future, but I thought I'd share my personal experience so far with LCD.

I've just started using GroovyMame for the first time with my first Bartop build using an LCD monitor and Windows 7 32bit.
Still not sure if I have the perfect LCD settings configured in my .ini, but the best way I've found to reduce LAG is to simply use DDRAW instead of D3D.

Wow - what a difference.
I tried all sorts of settings using D3D but just wasn't able to reduce enough LAG without other side effects.
Using DDRAW has sorted out that problem. Much better "feel" to the games now.

The only problem with DDRAW is that if I tried using any "effects" (scanlines) I would get too much slow down.
Still havn't figured out why. If i use D3D and enable effects there's no problem with speed at all.
I've since bought Toodles scanline generator to fix that issue. Now the games run sweet why much less LAG.

The thing I'm not sure about is trying to get smooth scrolling on all games with LCD.
I can get super smooth scrolling with games like Flicky and Wonderboy, but get jerky scrolling on other games like Pacland for example.
Any ideas?
I'm guessing it's a frequency issue with LCD's? I'm using an ATI HD4350 with a DELL 1708FP monitor.

Cheers.

 
 

[twistedsymphony]

Every-time I've ever tried using DDRAW it's slowed the games down to an unplayable crawl. this includes my CRT MAME cab which has no post processing.... i guess run whatever seems to work best in your setup.