Does the Brook PS3/PS4 board have the same lag as the universal fight board?
Given that there’s a video of it beating the PCB in the Madcatz TE2+, I guess not. At the very least it’s not as bad as the value measured by Teyah, if that’s where you’re coming from. The firmware version also matters, to my knowledge.
What’s the official statement? 
I have a question, if the test made with different games is useless, isn’t it?
I don’t know the games’ teyha use for ps4, but I see he created the tests before SFV, if SFV has 7,3 frames of delay (http://www.displaylag.com/video-game-input-lag-database/), the test result will be different than, for example, ps4 USFIV, because it has 5,3 frames, right?
1 frame=16,67 ms (this is an example, 7,3 is 122 ms and 5,3 89 ms, for more easy operation)
9ms+7,4ms=16.4ms
9,28ms+7.4ms=16,68ms
the first win
9ms+5.3ms=14.3ms
9,28ms+5.3ms=14.58ms
Draw, because if the game detect less ms than the minimum of the frame, is the same:
So, If I used for the test SFV, the second stick result will be much laggier than the same second stick in ps4 usfiv.
Sorry for being a little off topic but my neighbour has two Naomi Universal Cabinets which we sometimes play the arcade version of Virtua Fighter 4 Final Tuned on. Since it’s the official cabinet together with the actual arcade PCB, is there any type of input delay at all on official arcade cabinet sticks? Games seem much more responsive on arcade than on console, but maybe this is due to lag on the console and not the sticks themselves?
Anyway, I am guying the Brooks Universal Fighting Board this weekend and am absolutely thrilled reading it performing this well.
The chart is from March. I think the list for anything including Brook is irrelevant at this point.
PS360+
https://www.youtube.com/watch?v=vRGfGloBmQA
This is a novel method which I believe can be used for analysing input lag both of games and controllers, developed almost entirely by me.
What is happening here is that I have an arduino programmed to turn three pins on for 1 millisecond, and then turn them off for 200msec. This means that every seventh frame, the pins will be turned on. Two pins are attached to optocouplers - when they are on they will allow the colour signals of a component video output to show, as signified by the coloured bar moving down the screen. Another optocoupler is connected to the controller, and when turned on will allow the button to be pressed.
This allows a visual representation of when the button is actually pressed to be seen on the video capture (done with LGP portable at 720p, using component output).
With the PS360+ when there is colour over the lifebars, the input will be accepted. This generally happens once per movement through the screen and is very consistent. If you think about each frame being broken up into 16+2/3 milliseconds, what this is doing is testing each millisecond sequentially to see when a command will be accepted. On the PS360+ there is one (occasionally two, probably because of overlap) milliseconds where a command will be accepted.
UFB
https://www.youtube.com/watch?v=IOg-9IygIFk
What is different to the PS360+ is there are 4-5 milliseconds within the 16+2/3 milliseconds of a frame where a command will be accepted. This to me suggests a significant difference in the way in which inputs are read between the two devices.
How does the xbox one atrox pcb stack up?
What does this mean to the lay person?
What’s happening is that when the button is pressed, a visible indicator will appear on the screen. This is captured (using the Live Gamer Portable) and on review we can get some information about both joystick input lag and game input lag.
The input is less than a frame so that it is clearer within the 16+2/3 milliseconds per frame where the button is being pressed. The stripe that appears is a bit bigger than 1/16th of the screen, so exact numbers aren’t possible, but as a general rule the further down the screen the later the input was made and still accepted i.e. less input lag.
Interestingly not all sticks/pads work with this method. The Pokken pad seems to not respond to inputs shorter than 3msec, whereas most other sticks will respond. I don’t know the reason for this.
What I had thought would happen is similar to the PS360+ twitter screens (https://twitter.com/noodalls/status/770392888639315969) where there is a consistent time between button press to response.
However, the UFB has a wide range of areas where commands will be accepted. If you compare the final UFB screen to the PS360+s screens, it’s probably about as far down, suggesting that the UFB can respond as fast. However the first twitter screen shows the input happening significantly earlier and still being accepted.
If you compare the two youtube videos https://www.youtube.com/watch?v=IOg-9IygIFk & https://www.youtube.com/watch?v=vRGfGloBmQA you will see that the PS360+ only responds once every 16 instances or so, whereas the UFB responds more often (3-5 times).
There is something that I still want to test, as I believe there may be a downside to the UFBs wider window, however I’d rather confirm my suspicions before posting this.
Impressive testing , I own a few fight sticks , and I notice the lag in other sticks since my main sticks have UFB inside or a fighting board . My Omni , TE2, and all other madcatz that still have my stock PCB in them. I simply can’t go back to a stock pcb stick
Ever again. Call me spoiled but my standard is a Brook UFB inside
PS360+
https://www.youtube.com/watch?v=ROgPnnebRtE
UFB
https://www.youtube.com/watch?v=xYOvdLaCiww
Using Akira’s just frame knee because it requires a button to be held for just one frame (K+G for one frame, release G on next frame for those that are not familiar with the move). What you’re looking for is when his back foot doesn’t leave the ground, as this is when the non-JF version occurs. As you can see from the command history, this happens when K+G is held for more than one frame.
Arduino programmed with code below. Optical isolation to prevent electical interference between arduino and controller.
The basic setup is K+G is held for 1F, on the next frame G is released and K is held, then K is released. Wait for just over a second. Repeat. See how many reps before a typo occurs. Comparison is made between PS360+ and UFB.
digitalWrite(23,HIGH); //This is the K button, high is pressed.
digitalWrite(25,HIGH); //This is the G button, high is pressed.
delay(16);delayMicroseconds(666); //Wait for one frame.
digitalWrite(25,LOW); //Release G button
delay(16);delayMicroseconds(666); // Wait for one frame
digitalWrite(23,LOW); // Release K button
delay(1006); //Wait for just over a second. This helps prevent the inputs occurring at exactly the same point in each frame, which is pretty much the point of the test.
Have been trying for a while to come up with a sketch that illustrates what I think is going on with the UFB reading inputs. This one seems to serve fairly well. See at the bottom for the sketch.
Set up is similar to other times, arduino connected to UFB via optical isolation. This time, the input is for just 15msec (less than a frame). There is a delay of 205 milliseconds between each press (so not exactly a frame multiple of a frame, such that the inputs fall at different points in each frame.
What is interesting here is that on occasions, the K input will be displayed as having been held for 2 frames, despite in reality having been on for less than one frame. This doesn’t seem to occur with the PS360+.
Sketch is digitalWrite(23,HIGH); // 23 is the pin connected to the kick button, HIGH is pressed
delay(15);//less than one frame
digitalWrite(23,LOW);// LOW is released
delay(205); //not exactly a multiple of a frame so that it lands at different points within the frame for each trial.
Sorry for being a nood, but does this confirm that the UFB is still a great purchase or are you proving faults with it? What are the current conclusions with your Akira knee post? The PS360+ vid seems to show that the device is more stable than the UFB for continues motions, but how does it manually perform tournament wise?
Have tournament players bought a cat in a bag?
If you want to use ps4 or xbone, or both, you should get a Brook UFB. PS360+ is a great board, but not for current gen support.
My interpretation is the ufb seems to have issues with buttons having been released but not registering as having been released which I think is due to the way it checks for button presses.
I think it is checking either more than once per frame or at a variable point during the frame to see if buttons have been pressed. This seems like an okay idea but can lead to situations like the akira knee where the correct input is not accurately transmitted. Previous experience with blazblue where a and then b is often read as a,a+b is similar.
Should note I haven’t had a chance to test new brook firmware and am still waiting for more equipment to test on ps4 (although the blazblue text on ps4 was independent of that)
Didn’t know the OG 360 TE was that bad.
I didn’t know my MLG PS3 TE, MadCatz PS3 Fightstick Pro, and PS3 Hori FE was that bad, but I guess MvC2 and +R doesn’t require frame precise timings. I mean I even noticed a MASSIVE difference when switching from those default PCBs to the PS360+. The difference was more different than black and white.
Fyi this is just a joke, excuse my poor humor
https://www.youtube.com/watch?v=9M_GFvF0cqI
So this is more like what I was hoping to achieve. It may be somewhat hard to see on the screen, but there is a purple bar that appears every 100msec (ten times/second or every sixth frame.) This corresponds to when the button is pushed. This isn’t different from previous versions.
What is new however is the ability to control where the input occurs. As you can see from the video, initially the input is too early to be detected, and then as it occurs later in the frame, the input works, until it becomes too late and is again not accepted.
Review of video is necessary to work out how many frames it takes for the game to respond, however if the inputs are occurring on the same frame even visually this should give some fairly easy information as to lag for sticks and or games.
To see what’s going on, set the quality to 720p60, pause and then use , or . to go back and forward frame by frame.
https://1drv.ms/u/s!AizjHalveL7PjrVv29WYXsDau2PuWw
So, I got to play with some of the major PS4 controllers. The tests are setup so that the button is pushed for a millisecond. At the same time on the screen a purple bar appears (optical isolation, HDMI --> component signal conversion). Then for the next millsecond the button is released, and nothing is on the screen. Following this, alternating red and blue tinted bars appear on the screen to aid counting.
All of the tested boards (PS360+ old hardware newest firmware, UFB updated firmware, new Hori HRAP V Hayabusa) take just over 2 frames to respond (using BlazBlue CPE). Interestingly the PS360+ and the UFB came down to the exact same average speed, 2 frames and 2.43 milliseconds. However the PS360+ is more consistent, the UFB results spread over a wider range.
The Hori was 2 frames and 6.875 milliseconds. This had a similar range to the UFB.
I will try to get to a tournament and test out more setups if possible.
Average results are ~2 frames 5 milliseconds for the UFB and 2 frames 10 milliseconds for the TE2.
This I found interesting. Testing Xbox one TE2 versus UFB. It seems as though the TE2 is evenly spread across almost an entire frame, where as the UFB is more tightly bunched (can’t test the PS360+ on the X1 obviously, but previously it has been more tightly bunched than the UFB).
Note - reuploaded twitter image as I had written TE2+. This are the Killer instinct TE2 sticks.