Oh, and yet another note: Unfortunately, RZX format is full of mistakes. For example, the authors define RZX security-protection schemes to be used in tournaments. But all these so-called "protections" are absolutely void! It can be hacked even with the original RZX SDK! I can' believe it. So, when I read the specs and see all the nonsense, I'm not sure the whole project is worthy...
---------------------------------------------------------- Mgr.(MSc.) Ales Keprt (also known as Aley) [EMAIL PROTECTED] *** www.keprt.cz *** ICQ: 82357182 Dept. of Computer Science, VSB Technical University Ostrava, CZ - [EMAIL PROTECTED] - www.cs.vsb.cz ---------------------------------------------------------- ----- Original Message ----- From: "Aley Keprt" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, January 03, 2005 1:33 AM Subject: Re: Multiplayer Sam >> Aley Keprt wrote: >>> You just define what particular keys will be accepted from >>> remote computer, and you send just the keys (in both directions). >> >> That doesn't solve the main problem, which is keeping both emulations >> perfectly in sync. Even time-stamping the input would require everything >> (including local input) to be delayed until both sides agreed on it, >> adding >> lots of lag. > > This is partially incorrect. One machine is a master (server), and other > ones must simply take, what their master says. So works the > synchonization. Slaves send their pressed keys with time stamps, master > sends back what keys should be really passed to the emulator (with > timestamps). Slaves ust halt the emulation until master says "it's another > 1/50s tick". This way the delay is a few ticks, which is acceptable. (and > it's the same as network gameplay on a PC - in Windows games like Doom, > Quake, Half-Life etc.) Basically, this is the main idea. It can be > optimized, but I think we could start with this basic algorithm. :-) > > Note that all peers must use the same version of emulator to be able to be > in a sync. That's the prerequisity. > >> It's something that has been discussed a number of times in CSS, with no >> perfect solution. One of the better ones seemed to be to have a master >> emulation, with the secondary emulation state updated from that. The >> state >> does includes the full RAM image (or some sort of delta image) updated >> frequently, with the secondary emulation continuing as normal in-between. >> Modern FPS games seem to use that method too, but with the state >> information >> being smaller and easier to manage. > > 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! > With POKE / infinite lives, of course. :-) > >>> I added .AIR support even to Win32 SimCoupe, but these changes >>> never went into the original development source code version.... ;-) >> >> That might have something to do with AIR being a closed file format, >> which >> isn't compatible with an Open Source emulator! RZX >> (http://www.worldofspectrum.org/faq/reference/formats.htm#RZX) is much >> more >> likely to be added instead, and is already the format used by most >> Spectrum >> emulators that have an input recording feature. > > Actually, AIR was a predecessor of all ZXS recording stuff - it was the > first time a ZXS emulator could do the record and playback. I never wanted > to send AIR into open source, so the people who liked AIR invented the > other thing. I think it's obvious - AIR is for tournaments, it's full of > security code, and there's no reason in using it in every single emulator. > I just mentioned AIR, since it's an example of that just a 5KB file can > contain a 1 hour game play. (This huge compression applies to AIR only, I > can't say much about the other format.) > > NOTE THAT THERE EXIST EVEN SIMCOUPE 0.81 WITH AIR SUPPORT!!! It just > haven't been publicly released, since it would be against GNU GPL license > without the source code, and against the AIR license with the source code. > :-) > > I think we can discuss it off the sam-users list, since it's too technical > for the majority of the people. I just end with my statement: Network > gameplay is possible, and is not too hard to implement. > > /-- > Aley > > >
