If you want to go down that rabbit hole, NTSC overlay stuff should be reasonably easy to get or build. Alternatively you can try a low pass filter (2-2.5Mhz) to strip the color out of the signal.
I don’t recall doing PS2 testing. That was NKI. https://www.youtube.com/watch?v=JoJzobmdGzU
Sadly the forum link in NKI’s youtube vid is broken and not working anymore. Would be nice to know what stick PCB he used in his tests.
And thank you for the links, Rufus. Awesome stuff.
Very interesting stuff!
So on the UFB the mode you’re recommanding for PC is 360 ? just wondering.
thanks for your hard work 
I used X360 mode of UFB on PC only because it is the default mode, so I assumed most people plugging in controllers would be using that.
Hmmm. In my experience the mode that’s auto-detected on the PC is the XboxOne mode, not the Xbox360…
You are probably right. I’ll go back and double check when I redo the PC tests.
Yup. Just confirmed.
@noodalls
The Dead or Alive 5: Last Round input lag frames reported in this thread may be 1 frame too big and should probably be tested again.
The game intentionally uses 1 frame of built-in “lag” in order to properly detect multi-button moves (such as P+K aka the Strong Punch command), but not always. This delay gets “bypassed” in 2 common scenarios: wake up animations executed while lying on the floor start 1 frame earlier compared to while standing, and the actual attack blocking function (H) activates 1 frame earlier than the blocking animation does, which is why inputting a frame-perfect Hold at an incoming attack will Block it instead of Holding it. Here’s a little demonstration of the standing vs ground input lag difference:
Thank-you for pointing this out. As I’ve said before, one of the challenges is finding suitable moves to test in games that I’m not as familiar with. It’s always good to have people familiar with the games give good examples.
I have been meaning to go back and test games that are across systems (PS4/PS3 versions of the same game) and DOA5LR was on that list. Because of the way I capture tests, I probably won’t test the two things you’ve mentioned (tests run ~100 times, with the animation needing to back to the neutral stance within 30F, and no real way to put the character into a specific stance/location) however I will check it and add it as a foot note.
I’m somewhat surprised there hasn’t been more discussion regarding the DBFZ result. ASW has consistently turned in results close to the fastest of any fighting games, but with DBFZ beta we are seeing a result slower than SFV. I had been waiting on this one to see what effect UE4 would have on ASW games. Now, people may say not to take too much away from testing on a beta/demo, however I’d take an alternative approach - this and MVCI is the first time we’ve
had results from pre-release, and it will be interesting to see if anything changes for release. It didn’t for MVCI.
Classic Unreal Engine.
On PC in Engine ini set the following option. (I recommend it done on MVCi)
r.OneFrameThreadLag=0
C:\Program Files (x86)\Steam\steamapps\common\MARVEL VS. CAPCOM INFINITE\MVCI\Saved\Config\WindowsNoEditor
Then double click on Engine.
Then copy and paste this on the bottom:
[SystemSettings]
r.OneFrameThreadLag=0
Having comparison between the default and this option and see if it reduces input lag. If so this should be able to be done across all PC UE4 games.
Edit: Also, test with AA set to medium or Low. Since it should lower the post processing too.
UE4 4.19 getting improved input delay.
This is huge this would drop input delay for UE4 games like say MVCi, SF5, DBZF, etc. By about two frames if the devs implement the engine changes.
Man I just now realized that Noodalls testing does not include monitor lag. Boy do I feel silly.
I only expect to see these changes in games like dbzf whcih are currently being developed. Updating the engine could potentially break things in game based on older revisions. Harada singled out UE4 but I doubt he would really follow through. TTT2 was like110ms total input lag already, they were already purposefully raising input delay back then. I hope I’m wrong though.
It’s actually easy to factor out the Monitor.
I mean noodalls setup is only testing for controller+game input lag.
…________
…,.-’"…~., .............................,.-"..................................."-., .........................,/...............................................":, .....................,?......................................................, .................../...........................................................,} ................./......................................................,:`^`..} .............../...................................................,:"........./ ..............?.....__.........................................:`.........../ ............./__.(....."~-,_..............................,:`........../ .........../(_...."~,_........"~,_....................,:`........_/ ..........{.._$;_......"=,_......."-,_.......,.-~-,},.~";/....} ...........((.....*~_......."=-._......";,,./`..../"............../ ...,,,___.`~,......"~.,....................`.....}............../ ............(....`=-,,.......`........................(......;_,,-" ............/.`~,......`-...................................../ .............`~.*-,.....................................|,./.....,__ ,,_..........}.>-._...................................|..............`=~-, .....`=~-,__......`,................................. ...................`=~-,,.,............................... ................................`:,,...........................`..............__ .....................................`=-,...................,%`>--==
……,-%…`
…,
Well, don’t leave me in the dark.
HDMI-AF-AM-V1A
USB-AM-AF-V1A
Bought some new equipment, sent today, hopefully will be able to do something with this. The thing I’ve always wanted to do is eliminate the HDMI to component adapter. As per previous tests, I’m fairly confident that it adds negligible lag, however it does mean I can’t test any higher than 1080p60, and as I’ve mentioned before testing PC can be a bit of a pain. I’ve tried several ways to get around this, but it seems that HDMI is quite fickle. Hopefully this will let me interfere with the HDMI signal directly.
Hi Noodalls !
I was wondering if you had any interest in Switch lag testing ? (with the rumor of arcsys games and soul calibur 6 coming to it)
I think there would be a lot of interest for wireless input lag analysis too (I know I’d love to use my modded tekken 6 stick)
but what’s the fastest ? pro controller ? joycon ? 8bitdo controller ?(might the easiest to hack ?) (no idea which has common ground of not though)
event for wired, so many options : brook ufb, brook converter, hori “pro” controller, pokken controller, WiiU GC adapter etc
I’m interested in testing, I just don’t have my own unit yet so haven’t been able to test. Hopefully this Summer (US winter) holiday I will be able to get one, possible testing in late Jan/early Feb.
There are some videos up on youtube comparing the input lag for some of the controllers.
So, for the longest time, I’ve been trying to find a way to remove the HDMI to component converter from my testing setup. Whilst a comparison between the HDMI to component converter against a component signal directly on PS3 suggested that the converter was adding very little lag (~0.2ms) it always felt like a bit of an unknown as to whether that applied to a HDMI signal as well.
With a lot of tinkering, I’ve finally found a way interfere with the HDMI signal without cutting it out completely. Interfering with component signals (the blue and red at least) is easy, as other than losing colour there is no problem is a signal drops out completely. HDMI on the other hand is very sensitive, and even with interruptions to the signal of <<1ms the HDMI signal is cut completely.
Finally I was able to use some HDMI breakout boards, and by providing an alternative signal path can get static to appear on the screen at the same time as a button is pressed.
This is not as easy to see as the colour dropping out of an analogue signal, however I wanted to take the chance to test and see whether my previous results done with a converter are still meaningful.
Tonight, I was able to run BBCPE PS4 UFB 2.0 through my standard testing protocol, and the results were fantastic. Comparing an HDMI signal to an HDMI–> component signal, I found no significant lag, 42.5ms for each test!
This I feel validates the previous results! Hopefully in the future this means that 4K signals and similar will be able to be tested with this setup.