Show HN: PSX Party – Online Multiplayer Playstation 1 Emulator Using WebRTC

Rollback networking is essentially event sourcing. Game states are immutable, and new game states are derived from adding inputs (events).

You keep the last dozen game states around in memory, and if you receive an input from the past, you rewind to the last game state prior, add it to your input stream, and fast forward to the present.

It has the same base advantages and drawbacks as RTS networking - the core logic is written as though the game is single player, and complexity can be scaled arbitrarily without bloating bandwidth requirements.

But in addition, you get the benefit of zero input latency (play a multiplayer RTS game and send a unit around - they won't move for 200ms or so), and the drawback of an absolute clusterfuck time rewind debugging madness if any inadvertent mutation of your immutable data happens.

The reason you do rollback with something like this is it gives you zero latency, and you can retrofit it on to an emulator without changing any game code just by using memcpy() on the game state.

Source: I've developed about a dozen titles using rollback networking.

Friends was also shot on film, and cropped to 4:3 for broadcast. Like Firefly, Friends also had unintentional things (crew, microphones, un-dressed sets, etc) appear in the edges in 16:9. While most were probably edited out before the uncropped 1080 re-release; some unintended things remain, which I personally really like seeing.

Additionally, like Firefly's pure VFX, some footage in Friends also appears in SD in the HD release (seemingly either because the original film stock was lost, or it wasn't originally shot on film), with the zoomed 4:3 SD vs 16:9 HD sometimes changing mid-scene, and …that too I find a humbling reminder of the quality of yesteryear.

I remember having a distinctive moment of clarity watching Seinfeld reruns in 16:9 HD. Did they have the foresight that it would be a classic making billions in syndication?

The darker edges seem to be due to ‘natural vignetting’, as I learned from this article recently posted on HN: https://ciechanow.ski/cameras-and-lenses/

In the comments on YouTube, people discuss some other race-related aspects that reveal the age of the video. Such as lack of protective barriers, and people standing right next to the race track.

Star Trek tng was shot on 16:9 film, transferred to 4:3 video to be cut and turned into a final 4:3 video. When they did the blu ray remaster, they had to match and rescan every shot from the source film, re-edit each episode and recreate the special effects (when not produced on film). There was the thought to maybe scan the material in 16:9, but the scenes and crew only considered the 4:3 frame - in 16:9 there would often be crew or mics in the frame or even perhaps sets missing. So they kept the show in 4:3.

Apparently for later trek shows (ds9, voy) the film crews were more careful to respect the 16:9 frame, but those shows aren’t as popular and may never get the expensive blu ray makeover.

Do a quick search of YouTube. You’ll find it already does.

Upcoding was done for ages, conceivably your TV might have some more clever algorithm than cubic.

But never in a million years will upcoding recreate the picture that was there in the original. It can create some new detail of its own, yes.

Looks like its gone now https://news.ycombinator.com/item?id=25017167

> There have always been arguments showing that free will is an illusion, some based on hard physics, others based on pure logic. Most people agree these arguments are irrefutable, but no one ever really accepts the conclusion.

When I had a big LSD trip, not only did I understand the fact that we don't have free will, I experienced it. It felt as real as my body.

I don't think about free will anymore, I feel like I've already watched the movie.

There usually is, though it's arbitrary — basically an implementation detail of the emulator which was tuned based on in-practice behavior observation. Input-event messages that haven't been integrated into the canonical state after a "long time" must be dropped/undone by those who did integrate them, including by the player who originally generated them. In effect, an implicit "anti-event" is generated saying the opposite of the original input-event message, and applied to history by all players who applied the original message.

How do players tell if their event managed to become part of the consensus state? Depends on the networking protocol. In a gossip protocol, messages get sent to peers individually, and ACKed by those peers. In an elected-leader client-server protocol, as long as the server peer ACKs the message as "in the queue", it's canonical. In an IRC-like spanning-tree message-relay system†... something complicated involving vector clocks containing message IDs.

† I don't think I've ever seen an emulator choose a hierarchical message-relay architecture. It makes good robustness+efficiency trade-offs, but it's just far too complex to work with compared to the alternatives. It's more the domain of MMOs, that need to be concerned with many nodes colocated in one site speaking to many nodes colocated at other sites.

> In other words, this causes players to see the monster dying twice.

The frames that are replayed aren't visibly replayed. They're re-computed, but the visible effect is more of a "lurch" from one world-state to another one. In this case, the monster has been dead for a second or two already, but suddenly each player's score counter would jump around to show that it's actually player P who did it, and gained the points for it. Except for player P themselves, who experiences no change.

It's very similar in experiential effect to the effect when an inherently-networked client-server game does client-side prediction, and then the server sends the canonical state which disagrees from the client's predicted state, and the client has to lurch into the server's canonical state. People's avatars pop into different positions; in an FPS, you might suddenly be dead "out of nowhere"; in a racing game, you might suddenly be spiralling out of the way because your path turned out to collide with that of another car that wasn't originally there; etc.

Inherently-networked games sometimes have interpolation ("lerp"-ing) code to smooth out this lurch between client-side predicted positions and canonical server-side state — usually, if the only thing that's incorrect is positioning, the client will try to generate a few interpolated frames of movement that takes objects from their incorrectly-predicted positions to their server-prescribed positions; and then it'll play those frames in fast-forward, so that they've all been played out well before the server sends its next update.

But this only works when the server isn't communicating every single frame (otherwise there's no time to replay the lerp); and it basically only works for positioning changes — if someone does manage to cause a discrete alteration to the game-state (like changing who killed an enemy), that will still usually cause a sudden "lurch" into the new game-state in these engines. The interpolation-frame generator code just gives up.

(Though, for especially-important things like who won a match, inherently-networked games just do a hard consensus-sync of all players — usually during a screen transition — before actually showing a results screen. People get quite cross when their results lurch!)

And, of course, games that weren't inherently-networked, but which are instead being networked "on the emulation layer", have no logic for lerping, and cannot, unless lerping logic is hand-written by some kind soul for each emulated game's engine. Possible if you're hand-crafting an emulator designed to play a single game; quite unlikely if you're just building a general system emulator — especially if, as with most authors of general-system emulators, your goal is faithful reproduction of the behavior of the original system.

> Would you suggest some reading on this?

No idea if there is any reading on how emulators do this, tbh. (I'm self-taught on this subject, from working with open-source emulator codebases.) But any modern textbook on [inherently-]networked client-server game-engine development should talk about client-side run-ahead prediction and interpolation-frame generation.

I believe there's some book which deep-dives into the network architecture of Doom, or Quake, or Unreal Tournament, or one of those early networked games, and uses it to explain the history/invention of these client-side prediction features. I can't seem to Google it for the life of me, though. Can anyone here assist?