Hacker News Reader

Comment by VortexDream | Hacker News Reader

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.

View on HN

> 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.

https://twitter.com/ParsecTeam/status/1425206344467034113

The Parsec folks are good people but I'm still a little worried.

Same. Hopefully some alternatives come along.

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.

thanks for the explanation

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.

They have a web client, but their desktop client was way better in every way.

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.

[edit] Ah I guess I'm wrong they use a proprietary thing outside the browser after all that they call BUD. https://blog.parsec.app/game-streaming-tech-in-the-browser-w...

Still I suspect that there's some cross-pollination there.

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.

https://github.com/rustdesk/rustdesk/issues/79

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?

Constant FPS mode will make a big difference here.

More details: https://support.parsec.app/hc/en-us/articles/360045797752-Re...

4:4:4 would also help but think you have to pay for that feature...

4:4:4 is great, but they need to switch to hardware decode. Currently software decode slams CPU on my Macbook.

Reply on news.ycombinator.com