Official shmupmame Super Turbo thread


I guess I’m thinking about it more in an isolation of the lag problems. I.e., what’s the USB controller lag vs. the inherent lag of shmupmame. Maybe its not possible to isolate the various lag contributors with the nki test…not sure.

The nki test just (basically) measures the input lag as a whole, correct?



it’s the total lag, including input / processing / display.


Ok, cool. So, really just input and processing (for the CRT tests, anyway) since that shouldn’t be relevant from a lag perspective.


whenever I change any property of the game (game speed, enable cheats, etc) it doesn’t commit. If I go back to the properties menu they are set as the initial default ones.


Whenever you change a property, click on another box/option to ensure that your change is highlighted in “black.” I usually do this on the properties for the actual game and CPS2 options to ensure that the settings are intact. Once both the game and CPS2 properties match, then click “OK” and it should be good to go. You can also manually edit, the configuration .ini file to a particular option as well.

Did some more testing that yielded some very interesting results.

  1. The USB poll rate program does indeed actually work (using Win7) for most USB sticks (I haven’t been able to get my PS360 sticks to work, but all others worked). Basically, you can select the poll rate to 1000ms = 1ms as opposed to the standard Windows default USB poll rate of 8ms. There is a DEFINITE improvement.

  2. Disabling bi-linear filtering on Direct 3D seems to increase the responsiveness aka reduce the input lag as well.

Papasi’s test pretty much confirmed how close this emulator is to actually matching the cps2 board; these new adjustments should close the gap even more :wink:

Small reminder ** The best way to utilize this emulator is to output the video signal from your PC/Mac/laptop to an outside monitor that has 0ms delay (VGA CRT/IIyama LCD/Euro brand LCDs) or one of the low input lag LCDs mentioned in the tech talk section. **


Thanks DG. The highlight trick you mentioned let me change the settings. Btw, the cheats section has A LOT of things you can change. It’s really awesome.

Now I am curious about the minimum requirements to run shmupmame and still perform so close to the CPS2. I think the raspberry pi is not powerful enough (yet). Otherwise, it would be a very cool, cheap and portable device for ST.


Very interesting…which poll rate program did you use? Were you able to verify the polling rate actually changed via another program…if so, which one?

Also, which win7…x32 or x64?



Also, what sticks worked with the program?


I have a LOT of input delay with my usb Psx / Ps2 adapter, anyone knows how to fix it?


I’m not sure of the official name of the program. It’s the most commonly found USB poll rate program on the net ( The files/folder you download should contain this “HIDUSBFU.INF” I checked the poll rate adjustment also via the mouserate checker program…and it was verified. I tested this on Win7 x32 and Win7 x64. Switching between the default 125hz and 1000hz will definitely be noticed by the input lag aficionados.

Update: After testing various joysticks, it seems “so far” that this particular USB poll rate program only recognizes Playstation 2/3 joysticks and PSX adapters. When utilizing a 360 stick, the program does not seem to recognize the stick under the menu as “HID Compliant Game Controller.” I tested the PS3 MadCatz SFxTF VS stick, 360 TE R1 stick, HRAP2 with ps2/ps3 adapter (Sumitomo brand), PS360 modded sticks.

Geadom: What USB PS2 adapter are you using? From what I recall, there were only 2-3 USB PS2 adapters that had zero input lag (Pelican, Sumitomo, and another brand I can’t recall).


laugh’s inpin converter on


Thanks Dark Gaiden. I think I got it working…but doesn’t mouse rate just check the polling rate for your mouse? I.e., can you also check your stick(s) with this program?



papasi, have you ever tried groovyMAME? Might be a good alternative to shmupMAME without the occasional graphical issues that shmupMAME sometimes has.

groovyMAME introduces a special setting called “-frame_delay” that “Delays the start of the emulation of each frame by an amount of time defined in tenths of the frame period length (0-9), in order to give a chance to the emulator to have the most possible updated input for that frame, as an attempt to minimize input lag.”


Damn, just heard about shmupmame today. Where the heck have I been?


Yea, mouse rate only checks the polling rate for the mouse. Just toggle between the different polling rates and test them out via your joystick…it’s pretty noticeable between each setting.

Testing Update: Disabling Bi-linear filtering on Direct 3D also seems to reduce the delay slightly.

Ah…someone has been on the forums I see! I’ve been following the developments of groovyMame for the past few months. I definitely caught the post mentioning the “-frame_delay” option and it sounds very intriguing. I haven’t spent too much time with the emulator, so I don’t really know the optimal settings…I think it works best with Radeon graphic cards using the CRT_EMU and/or SwitchRes programs along with WinXP I believe. Hopefully the community can delve into this other Emu and compare results.


Ha! Yep! I’ve been fooling around with it for a while and its really good, imo. I set the framdelay to 1 and the apparent (subjective mind you) input lag is very low, especially in combination with 1000hz setting on my stick. Been testing with a lot of very input lag sensitive stuff like super turbo and many shmups.

Its great, too, because unlike shmupmame, you can access the entire mame library. The ati support is much better than its nvidia support, right now, but I know its nvidia support is being worked on.



papasi, when you did you “regular” MAME measurements, can you tell us what version of MAME and what video settings you used, including whether v-sync, triple buffering, etc. were on / off?



i downloaded the latest mame 0149, everything is default.


Thanks. I believe stock, MAME does not use v-sync or triple buffering but DOES use d3d / post-processing filter instead of directdraw / no filter. I think this (d3d + filter) is laggier than directdraw / no filter.



Yeah, 360 controllers use a “Vendor Specific” device class (FFh). Sounds like that program will handle any HID device (class 03h). Unfortunately, even if the author of that program wanted to make an exception in order to support 360 controllers by allowing vendor specific devices, there’s really no general way to be guaranteed that it’s a 360 controller and not some other crazy vendor specific device. With UD-CPS2, I am able to make the assumption that people aren’t plugging in a USB coffee pot, so when I see a device class of FFh, I assume it’s a 360 controller.