Kodewerx

So there's this hack

http://www.justin.tv/hextator/b/281099551

I've been working on, working offline beautifully.

As someone of you may know from my complaining, it doesn't work online because the game desynchronizes whenever saves are loaded.

As the hack currently is, the first save is loaded in multiplayer so that your save data can be used for co-op play when you press the L button while in multiplayer.

When you do this while playing online with Mupen and Kaillera, the only way to currently do so, the game desynchronizes instantly and even crashes the emulator at times.

Obviously whoever coded Mupen and/or Kaillera fucked up, because Kaillera is only supposed to synchronize key presses and be entirely agnostic of what the game is doing.

So I'm proposing a solution that will resolve this problem not just for this game, but for all applications...a way for people to synchronize the input received by any application on any PC.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Moving on, this is basically an RFC for this project.

I want:

- Requirements suggestions (my own to follow)
- Interface ideas (related to the above)
- Implementation suggestions (would I be able to prototype this in C#? I hope so but I don't know if it can do what I need)

Here are the ideas I have.

- There will be an application which, when it has the focus, will forward input to the application specified.
- The specified application will need metadata concerning a benchmark for synchronization, such as an address of execution that can reliably be broken upon to ensure input is sent to it at "the same time" on all clients.
- Following the previous, the implementing application will forward input to the application only while it is waiting for input as per the synchronization utility (as suggested above, I'm thinking breakpoints) after negotiating with other clients what the input to forward even is.
- It will not be necessary to forward the input to anything, and input could simply be assumed to be synchronized on clients who are not forwarding their "negotiated" input to anything - in this case, only one "player" needs to have the application receiving the input running, and if other players can see what the "host" sees through other means they will be able to play (although they will be able to play anyway whether they can see what they're doing or not, in this case)

The pros of this include
- No need to actually have the game that's even being played
- If implemented correctly, this solution will be cross platform and be application agnostic, even allowing someone playing one game in something like Project 64 to be able to be synchronized with someone playing the same game in Mupen.
- The application will be open source, so ways to resynchronize will be able to be implemented (or perhaps in the case of synchronizing emulators, save states could simply be passed between clients...an FTP widget could be added to facilitate this).
- The application will only forward input while it is in focus, so it will be secure.

The cons, of course
- Limited to the same input device (in other words, it will virtually be as though clients are sharing the same keyboard, fighting over which keys to use)
- Settings for the applications being synchronized will need to be precisely mimicked across clients
- Latency could be an issue? (This is mostly negligible, latency will ALWAYS be an issue...but if it's synchronized, it should be fine, right?)
- Ensuring synchronization may be difficult
- How the heck are we supposed to do cross platform breakpoints?

Optimizations could be made to this model. For example, emulators keep track of the input status of the emulated controllers. Following the note about application metadata for synchronization purposes, the implementing application could add an interface for specifying how to translate keyboard and other input device input (hopefully support for input devices such as mice and USB controllers, rather than just the keyboard, will be implemented in the future if this idea works out) into the format the emulated controllers use, and then that data could be synchronized and given to the emulator instead of the less abstract raw keyboard status of the clients.

Ideathoughtsopinions?

Final note: I know this is basically what Para did for the SRDP - post a good idea (I'm hoping this qualifies anyway), request suggestions for how to improve the implementation and then expect people to do so. That seems to have fallen through and as I'm one of the people that offered to help with that project it probably doesn't look so great for me to go and ask for ideas about my own.

All I can say about that is all of this shit needs to get done eventually anyway.

_________________

This is a horrible architecture. It's not enough to synchronize key presses. You need some context (frame of reference) to synchronize to. The only way to synchronize context is by introducing serious latency. For example, synchronizing not just the input, but the events which read key status. Or synchronizing vertical blank periods.

It the same kind of idea with a "common ground" for multiple electronic devices. The term "ground" just means 0 volts. But how do you measure 0 volts? A volt is just potential; The potential between 0v and 3v is 3v; the potential between 4v and 7v is also 3v. It's entirely possible for your ground to be my 4v... So the solution is to use ground as a frame of reference: connect them together, and all 3v signals will be 3v above the reference.

When synchronizing in the time domain, you have latency to consider. At 60fps, that's 16.667ms between each vertical blank. When attempting to communicate over the internet, distance is a significant factor. Consider the speed of light. Even at 186,000 miles per second, it still takes more than 67ms for light to travel half way around the earth. [source] The absolute theoretic minimum for worst-case scenario means a round trip of 134ms; well beyond the peak-to-peak time for vertical blanking. Clearly, achieving perfect sync in all cases is impossible.

However, there are established algorithms for dealing with the latency issues. There are prediction algorithms for filling in the "dead time" while waiting for a response from the other side. There are key frame algorithms for adjusting any skew introduced by latency and incorrect predictions. And there are asynchronous algorithms for handling interprocess communication with unpredictable delays. The all require some frame of reference, though, whatever you may choose that to be.


It is difficult to get people excited over an idea. A demo is far more interesting, even if non-functional. The only real requirement is that it has to convey the idea in a way that actually looks tangible. That generates interest! I just haven't done it for my project. Any of my projects.

_________________
I have to return some video tapes.

Feed me a stray cat.