![]() ![]() The twitter post is indeed back to front, it was getting to midnight when I posted, and I got it the wrong way around. The opposite can happen as well, where I've had input windows as short at 15 or perhaps 14ms being read as a button being held for two frames. This I believe happens because the polling window does not appear to be fixed, but can vary frame by frame. The reason I am not too interested in the times the dropped inputs have occurred is by my interpretation this is where, despite the input lasting for 17ms, it has missed being read by the game. The green flash is where both buttons are triggered, the purple flash is not the second input, but seems to be more of a hangover or rebound when the signal is allowed to flow again. Now, the setup that I ran was triggering each button for 17ms, although you can vary this length of time. The result of this is that I can send a signal to the buttons to turn on, and at the same time cause the transmission of selected components (red or blue) of the signal to turn off, resulting in a watermark on the screen, which can be analysed later. Two further optocouplers are also connected to buttons on joysticks. Then, I run the red and blue parts of this signal through two optocouplers. Basically, what I have is the HDMI output converted to a component signal. If you look at my twitter profile you can see some of the hardware involved. The setup is quite complicated, but I am happy to explain it. I have tested this on at least three separate occasions, with consistent results each time.Īny thoughts? Has anyone else tested this? Given they differ by about half a frame, it shouldn't be too hard for someone to either corroborate all of the above. (deleted old tweets with incorrect text, uploaded same images with correct text) If you can't do that, just look at these two tweets, What is happening is that the wired DS4 is lagging behind the wireless DS4. If you advance one further frame P2 will duck. ![]() If you advance three frames from there, you will see P1 (red, wireless) duck, and P2 (blue, wired) still standing. When you get a green bar on the screen (happens every 24 frames), this is when the input has physically occurred. Skip ahead to 0:20, and advance from there. Now, if you watch this video in HD (720p60) you should be able to advance frame by frame (using the, and. As I mentioned, you're going to have to ignore the fluoro lighting, it does serve a very important function, but you'll have to just accept it for now. ![]() Now, you could take my word for it, but instead I'll post a video which should hopefully demonstrate it. If you look here (sorry for using twitter, but I find it is an easy way to upload images) the DS4 wired is some 7-10ms slower than the DS4 wireless. ![]() On going through various different controllers, one of the things that surprised me was how slow the wired DS4 was. Capturing this provides a very accurate way to determine input lag. I went about developing my own method for analysing input lag, which I can go into (significant) detail about, but the summary is, it uses an arduino to send an input to a controller(s), and at the same time it watermarks the screen (by removing colour, hence the fluoro lighting in the video in this post. Which compared the input lag for various different sticks/pads for fighting games. One of the threads that I found very interesting was this one Now, so far as I can find, no one has actually tested this. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |