Input latency issues

[Chainsaw]

Hello. I'm having input issues with GroovyMAME. I'll explain it best as I can.

Using GroovyMAME, there's a noticeable delay in input. Also, sometimes on releasing the joystick, the input is "held" and it takes a few frames for the game to register I'm no longer moving the joystick.

Running regular MAME, I have no such issues.

I'm running on a fresh XP 32 bit installation. I'm running from command line. The latest MAME v154.

The PC is an AMD x4 with an ATI 3450.

Following a fresh Windows XP installation, on a fully formatted SSD, I installed the CRT_Emulator drivers, and ran VMMAKER (I limited total resolutions to 90 because ultimately I'll be using Hyperspin as the front end, and that has a limit). The monitor I have is a 31khz Nanao MS 2932 (I think, off the top of my head), so I'm using the arcade_31 preset.

Today is the first time I've got to run MAME on the cab. I've recreated the MAME config file, only changing monitor to arcade_31, and the issue persists, but as I say, only on GroovyMAME. Regular MAME works brilliantly.

I've tried framedelay 1 but that has a minimal improvement, if any.

Any advice would be appreciated

Thank you,

Matt

arcade_31

[Calamity]

Hi Chainsaw, please post a log of a game that shows this problem. Does it happen to all games? Also, have a look to this (maybe) related thread: http://forum.arcadecontrols.com/index.php/topic,140551.msg1456477.html#msg1456477

[Chainsaw]

Thanks for replying Calamity. One of my reasons to "choose" GroovyMAME was the excellent guidance you give.

I'm pretty new to all this, but I can't get a decent error.txt file out of MAME. I assume I should be running it "mame rtype -log -v" right? This is all I get, with both regular and Groovy:

Physical width 640, height 480
Soft reset
':maincpu' (3F80B): unmapped io memory write to 0040 = 0017 & FFFF
':maincpu' (3F810): unmapped io memory write to 0042 = 0020 & FFFF
':maincpu' (3F815): unmapped io memory write to 0042 = 000F & FFFF


That's it.

I have looked through the other thread you reference. It's purely a feel thing, but running "groovymame rtype -syncrefresh, -multithreading, -frame_delay 1" feels like half way between Groovy and regular MAME. At this stage I could just be going input blind.

So the game I've been testing on is RType. However, this occurs in all games I've tried. I've stuck with just the one because once you start messing around with variables, you can soon loose perspective on any perceived improvements. The best way to describe the issue I'm having with Groovy, is the ship in RType (or any other game) feels sluggish. Slow to respond, slow to fire. Running regular MAME, the ship in RType feels nimble, lighter in comparison.

The framerate on screen is a solid 100% (on both versions). I don't believe it's a framerate issue.

Any input (no pun intended) is appreciated. I don't have access to the cab often, but will do my best to produce any log files.

As a test, I redownloaded MAME and GroovyMAME and put them directly on the C:\ drive (with my regular installation being on the G:\ drive), just in case I had a config file or something causing issues. I'm afraid this did not resolve the issue.

Thanks in advance

[Calamity]

Hi Chainsaw,

To create a log, run:

groovymame.exe romname -v >romname.txt

This will allow me to see your current setup and its relevant details.

To make a fair comparison with normal MAME you should run it with vsync enabled. Notice vsync is disabled by default in normal MAME. This makes it feel less laggy regardless of losy video configuration.

The purpose of GM is to always use vsync without its associated input lag. With an optimal configuration it's more responsive than normal MAME, nearly as good as a real PCB.

[Chainsaw]

Hey. I've attached rtype.txt, thanks for the instructions.

I tried MAME with vsync, and it didn't make any noticeable difference - it was still more responsive than Groovy. I don't think the issue is framerate, I'd notice that, it's more like the control inputs aren't being read all the time, hence sometimes the ship keeps moving for a good few fames even after I've come off the controls.

[markc74]

I don't think the issue is framerate, I'd notice that, it's more like the control inputs aren't being read all the time, hence sometimes the ship keeps moving for a good few fames even after I've come off the controls.

This is what I thought as happening with mine but it only seemed to affect games with 256+ lines. I still notice it but not as bad as it was. It does drive you crazy switching between normal and groovy mame though - you start to doubt that the lag is there but then play 1942 or arkanoid and it feels all wrong.

[cools]

If you're using arcade_31 you must change VMMaker.INI to a suitable setup or it won't work well at all. Check my guide on Arcade Otaku

[Chainsaw]

markc74 - it's comforting to know I'm not the only person who "feels" this problem. I'd not correlated it to 256+ lines, when I can I'll try a few other games.

Cools, I'd actually followed your guide when setting it up in the first place mate. Good guide, it helped a lot.

I looked around but couldn't find a specific setup for the monitor I had, hence using the generic Arcade_31 settings.

[cools]

It was only recently I added in the vmmaker settings for 31k properly - the previous was using the VGA preset for VMMaker which doesn't match arcade_31, and there are a few other tweaks as well.

[Chainsaw]

Thanks Cools, but alas those match exactly what I have in my ini - I only installed Windows a week or so ago, so I'm pretty up to date.

I'm doing some tests with analogue games, as the issue is more noticeable in something like Centipede.

If anyone has any other ideas, that would be great. If I can work it out, I'll see if I can get SwitchRes working with generic MAME to see if the issue persists under those circumstances.

[Chainsaw]

A quick follow up....

I've downloaded SwitchRes 1.443, the latest version I could find (2012??).

Remembering I have little to no idea what I'm doing here, I created a new folder c:\switchresmame\ and put MAME 154 in there with a couple of roms. I unzipped Switchres inside the folder. I created a new MAME.ini, changed Switchres in there to 1, and then ran with the command line

switchres centiped

It felt fine / no latency. However I imagine I'm running Switchres incorrectly and I probably need a modeline in a file somewhere for it to read? Hope I'm not sound too daft here, just trying to run some scenarios to help narrow down what's causing the issue.

[cools]

Ahh, well I'm out then. I deliberately avoid analogue games as I've never found a way of making them feel right on a digital stick 

[Chainsaw]

Thanks Cools. It's not just analogue games unfortunately. However, Centipede is a good game for me to test, because last weekend I took it off my ROM list when I had a quick game and the control was all over the place (not moving, then darting to the opposite end of the screen, basically it was unplayable). In other words, the latency issues are more obvious than repeatedly playing RType.

[Calamity]

Hi Chainsaw,

Your log looks right except for the part that Cools pointed already. You don't have good enough resolutions precalculated for arcade_31. For this reason rtype needs to be stretched over 480 lines instead using integer scaling with 512 lines. But that has nothing to do with input anyway.

Instead of using standalone Switchres, you should test an older version of GroovyMAME. Get a version based on Switchres 0.014b, and check if the problem is there too. Make sure to use an independent folder for it and create its own mame.ini for this version.

We made a change starting with 0.015 that was aimed to reduce input lag. It actually did its job. But it turned out it broke analogue controls:
http://forum.arcadecontrols.com/index.php/topic,136443.0.html

However, a fix was done and now it should work fine. Maybe there's still some side effect resulting from that change and it hadn't been reported yet. (The issue you're describing with centipede sounds like something different to input lag)

Regarding digital inputs, they should work fine. The thing is I only have JPACs in my machines, which are keyboard encoders. What exact type of controls are you using?

[Chainsaw]

Hello Calamity,

I'm using a JVSPAC in a Naomi cab. I can notice the input latency with a regular keyboard, that was one of the first tests I done just in case it was an issue with the keyboard encoder.

Thanks for the info on anaologue games, I'll stop them as a comparison and return to RType and Salamander. I grabbed earlier GroovyMAME versions last night as it happens, I'll give them a test later

Regarding number of resolutions, as I'm using Hyperspin I understand there's a limit somewhere just under 100. Can I run VMMAKER in such a way to give my favourite games preference when creating resolutions? Maybe it's as simple as editing the mame.xml is creates to only list the games I want?

Thanks

Matt

[cools]

Clear out resllist.txt of everything except the desktop

[Chainsaw]

Thanks again Cools. I done that, and upped the total number of resolutions in VMMAKER.ini to 200 (I'll ignore the Hyperspin limitation for the time). Rebooted after the resolutions were created, but I'm still getting the same selected resolution in GroovyMAME.

Regarding latency, I've gone back a few versions of GroovyMAME and I'm convinced I can feel the issue on all of them (149, 151), even if I ran regular MAME with -waitvsync. I guess I'm at the stage where I use Switchres on other versions of MAME, not what I wanted.

Is there a guide I can read for this? Thanks guys

[Calamity]

Hi Chainsaw,

Regarding the video mode required for rtype, if you followed Cools's guide, specifically the "monitor_specs" part and created the video modes after that you should have one like 768x512, that scales 384x256 properly. You need to tell vmmaker that you want 31 khz modes, that's it. Besides, maybe you're using an old version of vmmaker, new versions of MAME require version 1.3c from here: http://mame.3feetunder.com/windows-ati-crt-emudriver/ due to the different format of their xml.

If the previous doesn't work (it will), you can always force vmmaker to create the mode you want, adding it in ReslList.txt. In this case the mode is:

 768 x 512 @ 55.017605

I have the feeling you're testing GM at 55 Hz (native rtype refresh) against MAME at 60 Hz (desktop refresh), which again, doesn't make a good comparison.

Now, regarding standalone SwitchRes, if you want to try it with normal MAME, use the --soft15khz option (use the --h for help and format of commands), this way it will tweak refresh rates the same as GroovyMAME, and it will set the proper commands (-syncrefresh, etc.).

I seriously doubt that once you configure MAME to use the proper refresh, synchronize to it in a proper way, etc. you can get better results. Mainly because GM is basically MAME properly configured.

[cools]

Post all your current INI and .txt files. It should just work - rtype is my goto hori game for testing and I've had zero problems on numerous setups.

[Chainsaw]

Wrote a long, detailed reply, attached files, and lost it all as I can't upload ini files! Renamed to .txt and I'll be briefer this time....

Thanks guys for the excellent support, I really appreciate it 

Using this config below, I'm no longer having the issues of Groovy keeping the ship moving when I've released the input. I can't be sure when / why / what / how this has happened, but it's not there anymore. The difference I am feeling, as Calamity puts it, must be down to 55hz / 60hz. I've been focusing on my ship speed, and saying it feels 10% when running in Groovy would tie in with a drop from 60hz to 55hz. That simple? Probably. I can't see clearly now, I've done too much testing

So you know, from here on in I'm not going to be able to get the PC into the cab until the week after next, so I can only run the PC (which I've removed from the cab) on a LCD 1920x1080 screen.

Assuming I'm now devoid of all perspective and the control latency issue isn't there anymore, the next thing I guess is to try and get RType working in the correct resolution.

I've redownloaded VMMAKER, added the resolution to ResList, rebooted, and I'm still not getting the correct screen mode up. I'm probably doing something daft, I've attached all the files I think are needed. Thanks so much

[Calamity]

Hi Chainsaw,

Are you possibly booting the pc with an lcd monitor attached? If so, don't do it. Boot directly with the crt monitor. Your files show the required resolution 768x512 has been created, but for some reason it's being filtered out and GM can't see it. This usually happens with 256/512-line modes when an EDID is read from one of the connectors. One workaround is to switch to -video ddraw and disable the option -lock_unsupported_modes in mame.ini.

[Chainsaw]

Yep that's exactly what I was doing when running the tests earlier. I can't get on the cab for a while, and have no other CRT around. lol. 

Brilliant advice again, thanks