0 users browsing Programming. | 1 bot
Pages: 1
| Duck Penis |
Posted on 19-07-21, 21:39
|
|
Stirrer of Shit
Post: #528 of 717 Since: 01-26-19 Last post: 1767 days Last view: 1765 days |
It's not the same thing as game state prediction. It's not the same thing as rollback. Is it the same thing as client-side prediction? Does it presuppose game state prediction and rollback? I'm at a loss here. I would think it has something to do with predicting inputs, but whose inputs and how? There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| funkyass |
Posted on 19-07-22, 05:35
|
|
Post: #60 of 202
Since: 11-01-18 Last post: 663 days Last view: 19 days |
input prediction is just auto-completion. nothing more, nothing less. why you conflated it with various methods of achieving smooth multi-player gaming experience with single player emulation is something you should reflect on. most of this post was typed with input prediction. |
| CaptainJistuce |
Posted on 19-07-22, 07:29
|
|
Custom title here
 Post: #583 of 1164 Since: 10-30-18 Last post: 66 days Last view: 3 days |
 --- In UTF-16, where available. --- |
| Duck Penis |
Posted on 19-07-23, 00:14
|
|
Stirrer of Shit
Post: #531 of 717 Since: 01-26-19 Last post: 1767 days Last view: 1765 days |
Posted by funkyass And how is input-based emulator netplay incapable of this? Surely, you could do input prediction to get an approximation of the last few frames of opponent that haven't arrived yet? There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| funkyass |
Posted on 19-07-23, 05:33 (revision 1)
|
|
Post: #61 of 202
Since: 11-01-18 Last post: 663 days Last view: 19 days |
emulation is hard enough, synchronizing multiple instances across a tempermental network adds even more difficulty. especially when the emulated software was never designed with lag as a concept. rollback for something like the snes would be a complicated mess of synching many things across the network. Its just easier to trust the emulator is deterministic enough not to require any client-side prediction and just suffer with desyncs and the crashes that follow. |
| Duck Penis |
Posted on 19-07-23, 15:23
|
|
Stirrer of Shit
Post: #533 of 717 Since: 01-26-19 Last post: 1767 days Last view: 1765 days |
Can't you just use save-states, provided the emulator supports them? Then it seems like it'd be trivial to sync, no game support or anything needed. The emulator is deterministic, but the humans using it aren't. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| funkyass |
Posted on 19-07-23, 17:56
|
|
Post: #62 of 202
Since: 11-01-18 Last post: 663 days Last view: 19 days |
Perfect is the enemy of good. |
| wareya |
Posted on 19-07-25, 08:02 (revision 5)
|
 Post: #76 of 100 Since: 10-30-18 Last post: 1785 days Last view: 1350 days |
Input prediction is the prediction of the direct effects of a client's inputs on the client's own gamestate without fast-forwarding the rest of the gamestate. For example, assume you're playing a FPS and you have 500 milliseconds (half a second) of ping, and the server is looking at Time=102seconds. Let's assume that there is no input prediction. When you, the player, see the entire game world at Time=101.5 seconds, that includes your own character's position. And there's going to be a 500ms round trip on your client sending its inputs commands to the server and having the server finish simulating the gamestate up to that point and return them back to you. Let's assume that you're using some sort of rollback or fast forwarding for the entire gamestate, taking into account all the inputs that you have sent to the server but your client has not yet seen the server acknowledge. If you do this, then you're going to have to re-fast-forward the entire gamestate whenever an input that is not your own changes. This is fine for fighting games because it's very important for everything to have consistent relative positioning, which we will see that input prediction does not ensure. Fighting games can add buffer frames to reduce the appearance of "oh, he died but then it rewound and turned out he didn't get hit" glitches and so on. Let's assume that there is input prediction. When you, the player, see the game world at Time=101.5 seconds, your client will fast forward its own movements and actions only to Time=102. This eliminates the network-induced input lag, without causing the gamestate as a whole to ever need to rewind. The only thing that will ever be re-fastforwarded is the player's own motions, which the client is almost always going to get almost completely correct. This causes problems for things like attacks, because now the player isn't seeing exactly what the game server sees. This is why in games like Quake 1, Quake 2, and vanilla Quake 3, you need to shoot ahead of moving players to hit them. If you aim directly at someone, you're aiming from a fast-forwarded point in time to a time in the past, so once the attack registers, the opponent will have moved out from under the line of sight your crosshair was aiming down at the time you saw the attack on your screen. This is what "lag compensation" is for. There are several approaches to lag compensation. I will describe two of them. The first one is a limited form of fast forwarding applied to individual entities rather than to the gamestate as a whole. This fast-forwards the client's view of certain aspects of the gameworld (specifically, other players' positions) so that their own "fast forwarded" position is no longer out of sync with them. This has similar problems to fast forwarding the entire gamestate (rollback), but it's much cheaper, and you can "cheat" as a developer and add things like position smoothing to hide erraneous extrapolations. Things like damage events and deaths are only applied when the server says to do so. This is what Quake 3 CPMA uses. The second is good old "backwards reconciliation". In short, the server keeps a log of old gamestates and looks for the one that the player was looking at when their input events fired when doing things like calculating hitscan attacks. When it receives an input at Time=102seconds from a player with 500ms (0.5 seconds) of latency, it will compute certain effects of the player's inputs (namely hitscan attacks) based on a gamestate from Time=101.5seconds, in order to make up for the fact that the player was looking that far into the past at the time that the input was triggered. This is what is used by Quake 3 Unlagged and every Valve game. Backwards reconciliation is a perfect match for input prediction as FPS games know it. But as you can see, you have to be able to selectively ignore the side effects of the player's own actions when they shoot weapons, and only actually put them into effect after the server checks your inputs and calculates the effect itself (with or without backwards reconciliation, depending on the game). This means that if you have 500ms ping, you won't see someone take damage from your attacks until 500ms later, but that will be the only inconsistency. This is what makes it "input prediction". It only predicts the direct effects of your inputs like your movements and weapon animations, not the effects that those predictions have on the game world. |
| Duck Penis |
Posted on 19-07-25, 12:53
|
|
Stirrer of Shit
Post: #537 of 717 Since: 01-26-19 Last post: 1767 days Last view: 1765 days |
Thank you, that makes perfect sense and also explains why it can't be done for unmodified emulator games. So what do you call prediction of inputs then, like in smartphone keyboards and whatnot? As in, you have input i1, i2, i3, and you want to predict i4. There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this. |
| Kawaoneechan |
Posted on 19-07-25, 14:36
|
|
It's made of the crew's shit, y'know?
 Post: #307 of 599 Since: 10-29-18 Last post: 199 days Last view: 14 hours |
Predictive typing. |
Pages: 1
[Your ad here? Why not!]