In regards to sf5, the game itself is essentially playing against you if your connection is good and the other person's is bad. The delay is so high, it has to make predictions for you because it is flawed and designed to help those with bad connections be allowed to play with people far away from them. As horrible as rollback netcode is, it wouldn't be quite as bad if the person with the bad/slow connection/high ping had no predictions made and if their data didn't respond in time it was just too bad for them. Then, the correct thing would happen, the person with the good connection would pound the person with the bad connection because there wouldn't be any predicted moves(basically playing against the CPU on the hardest mode). Another way to explain it is, the laggy player inputs one button, the netcode sees their connection is bad, it predicts the full combo or next move over and over again, then checks to see if it was correct later, this alone adds extra lag. When the delay is high enough, there is simply not enough time for the game to verify what the next set of button presses were. They start teleporting because the game is constantly checking the real inputs against predicted ones. Often, the predictions are used not the actual inputs. So not only are they lagging like crazy teleporting around like a maniac, they're also getting off perfect combos every time event though they weren't even close to executing the button presses correctly.
All GGPO and other rollback netcode scams do is hide the lag while make it much, much worse.
Take a look from the creator of the scam himself, it doesn't make any sense even on the most basic logical level.
"I wrote GGPO to try to do a better job of solving the lag problem, without sacrificing all the other great properties of this method. Instead of adding an input delay to the entire simulation, GGPO gives the local player immediate control over his avatar by hiding the latency of the connection in the start-up of each remote player's action. This does a much better job of faithfully reproducing the offline experience in the online game.
GGPO uses speculative execution to eliminate the perceived input delay for each local player. Instead of waiting for all inputs to reach a player's simulation before executing a frame, GGPO will guess what remote players will do based on their previous actions. This eliminates the lag experienced by the local player created by the traditional frame-delay method. The local player's avatar is just as responsive as when playing offline. Though the actions of the other players cannot be known until their inputs arrive, the prediction mechanism used by GGPO ensures that the game simulation is correct most of the time."
Bullcrap.
A fighting game needs to be correct all of the time, every input needs to be accurate. The fairest way to do that is to let the inputs be what they are, not to hide or to try to compensate for the weaker connection in any way at all! That's Next to real time netcode. Actual real time netcode is not possible because of speed limitations and what you perceive as distance limitations or realities. If you humans could produce data signals that travel from any one place on Earth to any other place on Earth, that entire distance with one signal, it would essentially be as close to real time as possible. You are not intelligent enough to do that yet.
However, even with the technologies you already have you can come close to mimicking real time netcode. You need to create your own TCP/IP and UPD hybrid system for your netcode. It's actually quite simple, humans are just incredibly stupid now because of all the poisons you consume. Multi core CPUs help the situation even more, developers for the most part completely ignore them and their benefits.
Ideally, the backbone of your netcode is this setup. TCP/IP/TCP/UDP(I'm just going to say TCP/UDP from now on) or your own proprietary version that feeds directly into TCP/UDP connections(I think you humans call them pipes or pipelines), should handle all the real time data that must be accurate under any circumstance. So, input data, the opposing player's position, if you hit the other player, if the other player hit you, blocking data, damage data, etc... If you want next to real time netcode then every single piece of real time critical data should have it's own TCP/UDP connection, if you don't know what that is it's an open direct connection between two modems, basically. You need to create an order of importance, obviously based on how critical each individual type of data is. These take top priority. No extra header information is required, just where to send the data to, the application layer then transfers it to the software level, your netcode within the game.
Your code should then use, if we assume a 4 core cpu, 3 cores for real time critical data based on the order of importance you've already created, and 1 core for non critical data. And, obviously graphic calculation should be sent to the GPU, that's really not much of a netcode matter though. The receiving end of the initial data should fire back a very small acknowledgement 1's and o's/yeses and noes baby, just those. The critical data now has to be received. The fact they have a slow connection does not matter. If they send back a reply they didn't receive the data correctly, it gets sent again but on the sender's machine it is verified anyway as a hit or whatever the case may be, block, jump, etc... The person with the worse connection should never be accommodated for, never be compensated for, their connection and PC's capabilities are what they are. Don't ever try to hide them.
What about the UDP connections, what will they do? They handle any non critical data and pre and post fight data. For instance, the score isn't really critical data is it? lol No, if it gets calculated 100% accurately it doesn't really matter too much. A lot of statistical data isn't real time critical data to be honest. This kind of data can be sent in larger chunks without any regard for order. If a significant delay on any data is required, this is the type of data that should get delayed to not interfere with the critical data. You could even keep the score data on the players on machine until the match or round is over with, then send it. You don't want to waste bandwidth on non essential pieces of data. It simply isn't that important.
How do you handle input lag? Well, you sure don't arbitrarily grab a number out of thin air and say this is it. You let the players decide what feels and seems right to them. Anything below 40ms is very good, the average is between 40-70ms for display devices. You've arbitrarily doubled the average for some strange reason. Let the users pick the frame delay, then let them be matched up with people who pick the same input delay, or you could do it the safest way, the least complicated way that will generally be accepted by the vast majority of people. You logically go ever so slightly above the average 72ms 4.5 x 16. Bingo was his name-o, 4.5f delay. The vast majority of people are going to fall in that average range. 1-2f less isn't all that noticeable, nor is 1-2f extra. You should always give the user the option though. Pros will likely get TVs and monitors with the lowest input lag they can possibly find because it, in turn tournaments should use the same generally accepted input delay TVs and monitors, be exact. This is many of their livelihoods. Why shouldn't they be able to always compete under the most optimal conditions they possibly can? They should be able to play against their friends who are also likely pro players set it to 3f or 4f of input delay and expect the same tight range at a tournament.
To reiterate the main points of GGPO being a scam, socialist netcode does not work for good online fighting games. Like all socialist scams it tries to be inclusive at the expense of those who have better or more. It rewards those who have worse or less. In the process it creates an unfair online environment for everyone one way or another except under the most ideal conditions. In the case of the most ideal conditions it isn't necessary and adds latency and extra calculations for the sake of adding latency and extra calculations. To clarify when I say have their own connections, I mean each individual button. You press a punch button that gets sent on its own connection right away along with did it hit. You press d-pad down, immediately it is sent on its own TCP connection. You press kick while dpad is held down, that gets sent immediately along with whether or not it is a linker and whether or not it hit within the necessary frame window on it's own connection. The person on the other end has to acknowledge the data before they can do anything else, before they can respond with blocking or moves of their own. Since the data is now being sent in such small pieces, the chance of any long idling in gameplay are very low, the latency would have to be very high for both players and the bandwidth slow. The inputs of the laggy player get discarded because they can't keep up, their connection isn't good enough. Keep in mind that not all of them will be dropped since they are individual inputs. There won't be any screen freezing allowing the slower connection to reestablish itself. They will simply idle on the other player's screen. You cannot reward bad connections or people will do it intentionally on top of it already being rewarded by your netcode. People will lag switch, people will download or watch movies while they play the game on purpose to shit on their already sub-par connection.
Here are some other very important things you can do to create the best online experience for fighting games, you know since you don't want to exclude those in remote places or with bad connections or high latency. You give players a couple of new online mode options. Low latency mode and extreme low latency mode. You simply add extra frames to every move, in low latency mode there should be no 3 frame moves at all, 5 should be the minimum. Now the players have extra time to send and receive each piece of data as well as to verify them to the sender. You have to add the option to do this offline as well, so they can practice executing with more leniency on the moves. Extreme mode you bump it up to 8 or 10. And, you keep the frames as they are for pro players and anyone who wants that experience. You can even go further and in extreme mode allow them to set their own minimum frame moves and search for others with the same settings.
Not everyone wants to be a pro player, most people just want a fair and smooth experience online. No one wants to be cheated by the netcode or actual cheaters. Lag cheating would be advantageous to the person not cheating instead of the cheater now. :) They are just going to idle and get their brains beaten in.
None of this is exceptionally hard to do. The only question is do you give a shit enough to actually do it? Or, is money all you care about? I will give this to your competitors as well. The time of the GPPO scam is coming to and end!