|
MAME input "flickering"
#342046 - 07/01/15 05:14 AM
|
|
|
Lately, I have noticed a problem in MAME that is becoming more and more of an issue for me, and I neither know how to best describe it, or where the best place to turn for help would be, but I'm going to try to explain it here with hope for some advice.
For the record, I am talking about SDL MAME which I build in Ubuntu using the latest from the git repository. I also use [A S D] and [Z X C] for buttons 1 through 6.
When I'm playing a game and I press a key on my keyboard, the input is not constant, but has a bit of a flicker to it. I have confirmed this by running any CPS2 fighter and going into service mode and running the input test. Let's say I press and hold A. I see the 1 light up for the light punch button, but it flickers, and I'll see a 0 briefly but frequently light up in that position.
Here's where it gets weird.
Now let's say I hold A down, and press the up arrow for joystick up. Now the light punch button stays constantly lit to 1, and the up direction on the joystick flickers. I can do this again for a third time, say by pressing Z, and now light punch and up will be constant and light kick will flicker instead. If I then release Z, the two remaining inputs will stay constant.
I believe this is only one symptom of a couple of things I am seeing, including negative edge failures (where I release a direction on my keyboard, but it's still registered as being pressed down in MAME until I press it again and release it) and hitches in the emulation where video rendering freezes until some kind of input happens such as scrolling the mouse.
All this being said, I'd be perfectly willing to accept that it may be a function of my own hardware, and may have nothing to do with MAME itself, but I don't see this behavior in any other emulator I use, so something in MAME seems like the culprit. I haven't run this same precise test using a joystick, but I don't believe I've ever experienced the same problems with a joystick, only with the keyboard.
So has ANYONE else encountered this? If I'm only in this, so be it. Just wondering if people might have some idea of what's going on with my setup. Thanks very much in advance for your thoughts.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: Procyon]
#342054 - 07/01/15 05:25 PM
|
|
|
> When I'm playing a game and I press a key on my keyboard, the input is not constant,
> but has a bit of a flicker to it. I have confirmed this by running any CPS2 fighter
> and going into service mode and running the input test.
This sounds very much like you have key repeat enabled and it's kicking in during MAME, which is obviously undesirable.
|
|
|
|
Re: MAME input "flickering"
[Re: R. Belmont]
#342057 - 07/01/15 06:38 PM
|
|
|
Thanks for the response RB. I went into my system settings and disabled key repeat, and then restarted. However, I'm still encountering the same issue. Two things that puzzle me:
1) The flicker is not at a constant rate, it's fairly intermittent and random.
2) If it truly was an issue with key repeat, wouldn't all the keys flicker, and not just the last key I pressed? Because once I press a second key, the first key remains constant, even when I let go of the second key. If I press a third key, the first two keys remain constant.
This issue may be isolated to me and my laptop, and if so, that's fine, but if anyone else has encountered this, I'd love to know. Thanks.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: Procyon]
#342059 - 07/01/15 07:30 PM
|
|
|
> 2) If it truly was an issue with key repeat, wouldn't all the keys flicker, and not
> just the last key I pressed? Because once I press a second key, the first key remains
> constant, even when I let go of the second key. If I press a third key, the first two
> keys remain constant.
Actually, it's this specific behavior that makes me suspect something involving key repeat (maybe a wonky keyboard microcontroller?). On the Dell workstation I'm typing this on, I can open up a SlickEdit window and hold down A. I get aaaaaaaaaaa as expected. If I keep A down and press and hold G, I start getting ggggggggg. Which is quite similar to what you reported.
Do you have a USB keyboard around to plug in and see if it's your laptop's internal keyboard being weird?
|
|
|
|
Re: MAME input "flickering"
[Re: R. Belmont]
#342069 - 07/02/15 04:24 AM
|
|
|
Excellent suggestion, I don't at the moment, but I will have access to one at the end of the week. I will report my findings then. Thank you!
|
|
|
| Comboman |
|
Can't think of a good title
|
|
|
|
|
Reged: 12/30/12
|
|
Posts: 431
|
|
Loc: Halifax, Canada
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: Procyon]
#342076 - 07/02/15 02:29 PM
|
|
|
> So has ANYONE else encountered this? If I'm only in this, so be it. Just wondering if
> people might have some idea of what's going on with my setup. Thanks very much in
> advance for your thoughts.
I've never seen the "flickering" problem but I have definitely experienced the "key stuck on" problem. It was with a cheap wireless keyboard. I suspect the "key release" signal would sometimes be missed by the receiver. It would rarely happen when typing but often happen in MAME, (presumably because the keys are held down much longer?). Anyway, I went back to my old wired keyboard and the problem went away, so for me at least it was definitely a hardware issue.
|
|
|
|
Re: MAME input "flickering"
[Re: R. Belmont]
#342243 - 07/08/15 01:35 AM
|
|
|
> Do you have a USB keyboard around to plug in and see if it's your laptop's internal
> keyboard being weird?
OK, I was finally able to give this a try and much to my surprise, the flickering still occurs with a USB keyboard.
Mind you, this is in Ubuntu with the latest SDL build of the code. I took the very same USB keyboard and tried it out on a Windows 7 box, and there was no flickering. So I can conclude the following:
1) It is not isolated to my laptop's physical keyboard.
2) It is possibly a deeper issue with how the entire laptop processes input -or-
3) It is possibly an issue with SDL...?
I'd make a video of the issue if it would really help, but I'm not sure how useful that would be. I don't have Ubuntu loaded on any other device at the moment. I wish I did, I would test it immediately.
Is there anything else I can do to help isolate this? Maybe enable debugging output or something? If there is, let me know. And if there's not, I can live with it.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: Procyon]
#342272 - 07/08/15 07:56 PM
|
|
|
Huh, I didn't expect that. Not sure what the deal is - could be SDL, could be X11/XInput, could be some interaction between SDL and some other component.
Maybe it's one of the many, many things SDL 2.0.4 should fix. (It should've been out about a year ago at this point, but at least they appear to be nearing a release finally).
|
|
|
|
Re: MAME input "flickering"
[Re: R. Belmont]
#342431 - 07/13/15 03:34 PM
|
|
|
Had the chance over the weekend to test this on an Ubuntu Desktop running 14.04. Not identical to mine (running 15.04), but the flickering was not present. So either the versions make the difference (unlikely) or the problem is specific to my hardware (more likely.)
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: Procyon]
#342436 - 07/13/15 07:26 PM
|
|
|
> Had the chance over the weekend to test this on an Ubuntu Desktop running 14.04. Not
> identical to mine (running 15.04), but the flickering was not present. So either the
> versions make the difference (unlikely) or the problem is specific to my hardware
> (more likely.)
Super-weird, but it explains why there haven't been any other reports.
|
|
|
|
Re: MAME input "flickering"
[Re: R. Belmont]
#342717 - 07/19/15 11:42 PM
|
|
|
So it's about to get weirder, I was experiencing many more problems such as hitching and freezing... on a whim, I went into mame.ini and turned off multithreading. All my problems went away. The hitching, the input flickering, all gone. I doubt that that necessarily narrows any of this down, but I thought it would be interesting to report. I have a Core-i7, I figured turning multithreading on would be an improvement. Then I saw a discussion about it on the forum in arcadecontrols.com... So I'll be leaving it off from now on.
|
|
|
Tafoid |
|
I keep on testing.. testing.. testing... into the future!
|
|
|
|
|
Reged: 04/19/06
|
|
Posts: 3135
|
|
Loc: USA
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: Procyon]
#342718 - 07/19/15 11:45 PM
|
|
|
> So it's about to get weirder, I was experiencing many more problems such as hitching
> and freezing... on a whim, I went into mame.ini and turned off multithreading. All my
> problems went away. The hitching, the input flickering, all gone. I doubt that that
> necessarily narrows any of this down, but I thought it would be interesting to
> report. I have a Core-i7, I figured turning multithreading on would be an
> improvement. Then I saw a discussion about it on the forum in arcadecontrols.com...
> So I'll be leaving it off from now on.
The -MT command isn't working too well (there is a bug related to it in the database). It isn't for CPU cores or anything but for graphics rendering and it causes issues for a lot of people.
Good reasoning, though, to keep it off and use at your own peril.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: Procyon]
#342787 - 07/21/15 05:22 PM
|
|
|
> So it's about to get weirder, I was experiencing many more problems such as hitching
> and freezing... on a whim, I went into mame.ini and turned off multithreading.
Hahahaha. No, that's not weird at all - there's a number of very sound reasons MT now defaults to OFF when it didn't used to. I wanted to remove it entirely because the ratio of fuckups to helpfulness is nearing the singularity, but the one system it actually helps on is Couriersud's and he'd cry like Nancy Kerrigan if I took it out.
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: R. Belmont]
#342792 - 07/21/15 09:22 PM
|
|
|
> Hahahaha. No, that's not weird at all - there's a number of very sound reasons MT now
> defaults to OFF when it didn't used to. I wanted to remove it entirely because the
> ratio of fuckups to helpfulness is nearing the singularity, but the one system it
> actually helps on is Couriersud's and he'd cry like Nancy Kerrigan if I took it out.
Have MAME check to see if it's enabled and if it returns true insert a "nag" screen 
|
|
|
|
Re: MAME input "flickering"
[Re: R. Belmont]
#342816 - 07/22/15 07:29 PM
|
|
|
> Hahahaha. No, that's not weird at all - there's a number of very sound reasons MT now
> defaults to OFF when it didn't used to. I wanted to remove it entirely because the
> ratio of fuckups to helpfulness is nearing the singularity, but the one system it
> actually helps on is Couriersud's and he'd cry like Nancy Kerrigan if I took it out.
I take from your statement that it must be a heart-breaking view to watch Nancy Kerrigan (HTF is Nancy Kerrigan) cry.
I agree that the current MT code in osd is sub-optimal. The proper way would be that the mame-core would be executed in it's own thread and deliver frames to the main-thread via some queue. That would eliminate all the issues we currently have with MT. It's really not the MT code, it's the design.
I could easily live without MT if we would have proper support for "background" vsync wait. That's the whole reason I am sticking to MT.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: MAME input "flickering"
[Re: couriersud]
#342820 - 07/22/15 09:27 PM
|
|
|
> I take from your statement that it must be a heart-breaking view to watch Nancy
> Kerrigan (HTF is Nancy Kerrigan) cry.
It's a very old Cartman line from South Park.
> I agree that the current MT code in osd is sub-optimal. The proper way would be that
> the mame-core would be executed in it's own thread and deliver frames to the
> main-thread via some queue. That would eliminate all the issues we currently have
> with MT. It's really not the MT code, it's the design.
It seems like all we'd need to be able to do that is for the core to allocate the display list and its attachments each frame and make OSD responsible for freeing them, instead of assuming OSD has consumed them when it returns from the submit call.
|
|
|
|
Re: MAME input "flickering"
[Re: R. Belmont]
#342823 - 07/22/15 11:10 PM
|
|
|
> It seems like all we'd need to be able to do that is for the core to allocate the
> display list and its attachments each frame and make OSD responsible for freeing
> them, instead of assuming OSD has consumed them when it returns from the submit call.
+1 and a lock blocking the mame-thread from accessing the input memory while the osd updates it. And a bit more. But none of this is magic.
|
|
|
|
Re: MAME input "flickering"
[Re: couriersud]
#342834 - 07/23/15 11:35 AM
|
|
|
You may want to have a look at the multithreading implementation in GroovyMAME (only for the Windows OSD, I don't fully understand how baseline manages worker threads from the SDL side).
With GroovyMAME implementation, -triplebuffer enables background v-sync (e.g. run 55 Hz game on 60 Hz monitor at 100% with no tearing), while -syncrefresh forces the main and blitting threads to wait for each other.
Obviously the -triplebuffer idea (asynchronous blitting) requires being able to drop frames, which D3D9 doesn't allow natively (apparently D3D9ex does with the D3DPRESENT_FORCEIMMEDIATE flag). What we are doing is, in the window_update function, try to get the lock instead of acquiring it, and if it fails just exit without drawing. The rendering is done in a third thread separated from the window thread and the main thread. It's cumbersome but it's the only way I found to achieve this with D3D.
As it's currently implemented in baseline, you do the draw operations from the window thread, which is detached from the main thread. This is a bad idea, because the window thread also processes input, and if you v-sync you stall the thread so input gets seriously affected. It's even worse if the emulation and the screen are refreshing at different rates, because you may get weird no-input interference patterns, as it's probably the issue reported by OP.
Unfortunately the weakness of GM's implementation is that D3D still forces you to create the device from the window proc thread so the synchronization with the blitting thread is prone to dead-locks if you're not very careful. Besides you can't use this method with multiple windows.
|
|
|
|
Re: MAME input "flickering"
[Re: Calamity]
#342845 - 07/23/15 10:05 PM
|
|
|
Thanks a lot for the detailed description. It adds to the fact that we need to make the mame core able to run in a thread and communicate in a thread-safe way with the osd. Everything else just is half-working workaround - like the current MT implementation. And I'm responsible for the SDL part of it.
|
|
|
Index 
Threaded 
MAME input "flickering"
Reply
[Re: 
