I hope this doesn't mean the end of Parsec as a standalone service. There's nothing out there that comes close to Parsec's performance and it'd be a huge loss.
> Oh, and one more thing: we love the communities around games as much as anyone, and have no plans to change anything about the free Parsec app. We hope creative professionals get as much joy out of creating the next great fighting game as you do playing them.
On the client side at least a lot of what Parsec was leveraging seemed to be built on webrtc, so there's a lot of potential for similar things to come along I think.
I'm working on something similar, which will be called CloudGamepad. The trick to getting good quality and low latency is forward error correction and UDP. UDP will arrive quickly but is lossy. And the FEC allows you to recover a certain percentage of lost packages.
Does it work similar to rollback netcode in fighting games? Where the game tries to predict what the other player is going to do by looking at what they’ve done in previous frames, and if there’s lag or dropped packets and a destiny happens it rolls back the game state and replays it correctly?
Not exactly, FEC basically means you add in redundant data to your transmission so that if some of the data is lost, you can “rebuild” the missing data from the packets that did arrive. The cost of this is extra bandwidth spent on the redundancy, as well as a little latency.
Rollback is as you say, if the game loses connection with your opponent, rollback 1) uses your opponent’s past actions to predict what they will do next and then presents that to you as if they did it then 2) when the connection is restored, reconcile (if necessary) the difference between what your opponent actually did with what it predicted, rolling back if needed.
FEC in basic form works like raid 5. M parity packets for every N data packets, allowing loss recovery of up to M of the M+N packets without round trip back to host.
You can dynamically tune M and N based on measured loss rates and RTT.
Just because it's a desktop client doesn't mean it's not using webrtc. WebRTC is a much broader standard than "in-browser videoconferencing".
The main thing is that it's an open(ish) standard built around peer-to-peer low latency connections, with a lot of software already built up around using it.
I figured they got better video encode/decode with real hardware and not in the web. But it also makes sense they can do better networking the lower to metal they can get. I was using a 2011 mac air, and web client was worked but the app install was like magic.
Parsec's latency is great, but it's not great for text (like to the point I can barely read text in VSCode). Are my settings off, or is this an acceptable tradeoff for the heavy graphics workloads they are targeting?
https://twitter.com/ParsecTeam/status/1425206344467034113
The Parsec folks are good people but I'm still a little worried.