Aley Keprt wrote: > Slaves send their pressed keys with time stamps, master sends > back what keys should be really passed to the emulator (with > timestamps).
That sounds better, with the additional detail :-) I'm not sure the clients need to time-stamp their input though, as the server emulation will have already moved on past that point. The server would apply the client input as soon as it receives it, reporting back the exact time/frame it was applied so the client can apply it in step. The server's own input would be reported back in exactly the same way, of course. > Slaves just halt the emulation until master says "it's another > 1/50s tick". This way the delay is a few ticks, which is acceptable. Locking the frame-by-frame running of each client to the server sounds like it could make things choppy, as it relies on a smooth stream of updates to each client (even with it running a few ticks behind). Small variations in the receiving rate would be reflected directly in the smoothness on the client. Delayed updates would completely halt the client emulation until it arrives, and late updates would be bunched and require some frame skipping to catch up. Or is a smooth 50Hz rate an unrealistic expectation? It's hard to know how good/bad it'd be without trying it I suppose. It reminds me a lot of doing the cycle-accurate sound emulation in SimCoupe, where you've got the emulation running in parallel to a playing sound buffer that must remain seamless to avoid glitches. In that case some additional buffering to smooth out variations in running speed works well - something that might also apply to network input. Additional buffering gives a better chance of smooth running, but adds unpleasant latency to the sound/input. > (and it's the same as network gameplay on a PC - in Windows > games like Doom, Quake, Half-Life etc.) That doesn't match my experience in most FPS games I've played. During bad lag I can often move around the world as normal, with other objects (players, missiles, etc.) either frozen in their last known positions or with their movement continued along the previous vector. When the lag ends the master will _completely_ replace my local game state with what it has, so I might be put back on a ledge I jumped off, or more usually find I'd been shot! > Basically, this is the main idea. It can be optimized, but I > think we could start with this basic algorithm. :-) If it's something you're thinking of doing, I'd be very interested to hear how you get on with it. ASCD's AIR support might mean things are in a better starting position I suppose? I've yet to do the necessary changes to implement save states, which is probably something that would be needed to synchronise the initial state of all emulators for net play. > Note that all peers must use the same version of emulator to > be able to be in a sync. That's the prerequisity. Or just a compatability number that is incremented when any protocol-level changes are made that would break things? > Simon, you are a bit outdated. I played "1943" shooter in a > 2-player mode with a man thousands kilometers far away. And > we successfully finished it! I've not used it to know how well it works, but it sounds promising. Older arcade games might have a simpler machine state to update regularly, so it might use that method instead. If it's working on input updates instead, it could use a time-stamp method with/without buffering, or do a hard sync each update (which would surely affect the framerate with higher latency connections?). Could be worth further investigation if it'd help SAM multi-player... > Actually, AIR was a predecessor of all ZXS recording stuff - I remember it being first, and that AIR is technically superior to RZX in a number of ways too. The tournament coding works very well, and it was perhaps the closed format that stopped it being used more widely. RZX does benefit from being open, as well as (reasonably) compatable between different emulators. The last point is an important requirement in the Spectrum world, but not really an issue given the number of SAM emulators. > I just end with my statement: Network gameplay is possible, > and is not too hard to implement. Agreed that it's possible, but doing it *well* over a typical dial-up connection still seems tricky to me. Si
