FS-UAE Net Play

[AmigaOnline]

Originally Posted by FrodeSolheim

* Save state saving and restoring is now synchronized in net play mode.

Really thanks for this update! (It works )

[FrodeSolheim]

I have discovered a race condition in the net play server where input events could (occasionally) be sent to players interleaved differently with frames. This will almost certainly cause a desync. A proper thread synchronization primitive (mutex) is added, and the fix is forthcoming

I have also replaced a busy loop in FS-UAE net play code with a condition primitive, which means that FS-UAE will use a lot less (unecessary) CPU in net play mode.

[FrodeSolheim]

* Fixed a bug where large positive mouse movement became negative.
* Event information is written to Synchronization.log during net play (this file can be quite large) -cannot be disabled yet.
* Include slow memory in memory checksumming (chip + slow, now).
* Replaced a busy-loop in net play with proper condition signal/wait, using significantly less CPU now.
* Fixed a race condition in the net play server where input events could be sent to some clients out of order (with regard to frames). This would have caused desync when it occurred.
* Fixed a bug in the net play server where input events could be sent to some clients before all clients were connected.
* Detect refresh rate properly on Mac OS X (was not included in 0.9.11beta2).

Version 0.9.11beta3 can be download here: http://fengestad.no/wp/fs-uae/download-beta

For net play, this version is incompatible with earlier FS-UAE releases, and also requires an updated server: http://fengestad.no/wp/fs-uae/net-play

[AmigaOnline]

Your updates are really appreciated!

[AmigaOnline]

Originally Posted by FrodeSolheim

If the game requires mouse + joystick at one point during the game, and joystick + joystick at another, this is not currently possible with FS-UAE. It would need a input configuration menu in FS-UAE (planned anyway), but also distributed joystick port swapping (this is possible to do).

That could be very useful

[P-J]

What happens if a game does something that involves random numbers?

Just say, for example, Sneech decides to place the collectibles based on randomness using the system clock or elapsed milliseconds as it's seed. Would this always result in the same behaviour on both systems?

[FrodeSolheim]

Originally Posted by P-J

What happens if a game does something that involves random numbers?

Just say, for example, Sneech decides to place the collectibles based on randomness using the system clock or elapsed milliseconds as it's seed. Would this always result in the same behaviour on both systems?

As your correctly mention, games (and programs) use pseudo-random numbers based on, for example, the system clock or elapsed time.

Since the Amiga are run synchronously in net play, elapsed time will be identical at the time the game wants to create a random number, so both Amigas in a 2-player net game will generate the same random number.

(Also, MSM6242B/RF5C01A clocks are synchronized -but just a hack for now - both are set to 0, -proper time synchronization will be fixed later).

But the point is, games should work just fine, also when using random numbers!

[AmigaOnline]

Originally Posted by FrodeSolheim

But the point is, games should work just fine, also when using random numbers!

I can confirm that. Sneech seems to work online And "random" numbers/results are the same for all players (in this game at least)

[FrodeSolheim]

Originally Posted by AmigaOnline

I can confirm that. Sneech seems to work online And "random" numbers/results are the same for all players (in this game at least)

Excellent

Originally Posted by AmigaOnline

... The same issue will probably occur with games like Rodland/Super Cars 2....

I believe Super Cars 2 (floppy version) (and any other floppy game) should work perfectly as well!

[AmigaOnline]

Originally Posted by FrodeSolheim

Excellent



I believe Super Cars 2 (floppy version) (and any other floppy game) should work perfectly as well!

Hehe, this game will be tested asap
Other games have been successfully tested:
-Base Jumpers
-Battle Squadron
-IK+
-Kick Off 2
-Lemmings
-Lotus Esprit Turbo Challenge
-Lotus Turbo Challenge 2
-North & South
-Pang
-Pinball Dreams
-Speedball 2

With the passing of time, the most awaited features are:
-input configuration menu
-distributed joystick port swapping
-a working/basic chat feature (just to make sure that the other players are not already dead)
-a message/info to explain why the players have been disconnected from the server (unexpected bug or normal shut down)

Keep up the good work!

[Foul]

@AmigaOnline : Vais ptet enfin ! pouvoir jouer en ligne sous nunux grâce à cet émulateur

@Others : i will maybe can play online under Linux with this fabulous emulator

[AmigaOnline]

Originally Posted by Foul

@AmigaOnline : Vais ptet enfin ! pouvoir jouer en ligne sous nunux grâce à cet émulateur

@Others : i will maybe can play online under Linux with this fabulous emulator

Okay

[FrodeSolheim]

Originally Posted by AmigaOnline

With the passing of time, the most awaited features are:
-input configuration menu
-distributed joystick port swapping
-a working/basic chat feature (just to make sure that the other players are not already dead)
-a message/info to explain why the players have been disconnected from the server (unexpected bug or normal shut down)

Keep up the good work!

I have been away for work all week, and haven't been able to code on FS-UAE, but I have made plans in my head -And I was just considering working on exactly these issues

Regarding disconnects / error messages: yes, I have of course planned to have the server report back error codes to the client. The current implementation where FS-UAE just quits on error with any message is just a preliminary implementation, due to net play being coded during a single weekend

But this is what I am thinking to do: if net play is aborted (for any reason), the server sends error code/message to clients, and shuts down (on unrecoverable errors, at least), but FS-UAE will continue to run in off-line mode (instead of quitting).

This way, it will be possible for players to continue playing alone, or save the game state (if one state is copied to other players, one could in theory continue playing later).

Regarding desyncs, in the future, the game will probably continue (for the same reason as above), but with a clearly marked error message / icon in FS-UAE letting the players know that the game is not in sync -but still, better than just shutting down (allows saving, etc).

[AmigaOnline]

Originally Posted by FrodeSolheim

But this is what I am thinking to do: if net play is aborted (for any reason), the server sends error code/message to clients, and shuts down (on unrecoverable errors, at least), but FS-UAE will continue to run in off-line mode (instead of quitting).

This way, it will be possible for players to continue playing alone, or save the game state (if one state is copied to other players, one could in theory continue playing later).

Regarding desyncs, in the future, the game will probably continue (for the same reason as above), but with a clearly marked error message / icon in FS-UAE letting the players know that the game is not in sync -but still, better than just shutting down (allows saving, etc).

Excellent!

[Toni Wilen]

Originally Posted by FrodeSolheim

(Also, MSM6242B/RF5C01A clocks are synchronized -but just a hack for now - both are set to 0, -proper time synchronization will be fixed later).

Better to just not include real-time clocks in emulation configuration when playing games, no game cares

Problem isn't actually the clock time directly but 68000 MUL/DIV instruction having different cycle counts depending on instruction parameters, time conversion routines usually use multiplication and division.

If I remember correctly, random numbers are only used in floppy emulation to generate random number of extra bits to disk image's emulated write splice (There are loaders that break if word sync state is _not_ lost during gap!) and internally in IPF decoding library (but it has API to set and get the seed value)

[FrodeSolheim]

Hi Toni, thanks for replying!

Originally Posted by Toni Wilen

Better to just not include real-time clocks in emulation configuration when playing games, no game cares

Yes, I found out after coding it that the normal Amigas (A500 etc) did not have real time clocks anyway ;-)

Originally Posted by Toni Wilen

Problem isn't actually the clock time directly but 68000 MUL/DIV instruction having different cycle counts depending on instruction parameters, time conversion routines usually use multiplication and division.

But if the clients are kept in sync, and using cycle-exact emulation, this should still work? (Of course, fastest possible modes are not supported). I haven't spotted any problems so far, but I am not an Amiga hardware expert, so if you believe there could be a synchronization issue here, I would appreciate any hint/help you can give!

Originally Posted by Toni Wilen

If I remember correctly, random numbers are only used in floppy emulation to generate random number of extra bits to disk image's emulated write splice (There are loaders that break if word sync state is _not_ lost during gap!) and internally in IPF decoding library (but it has API to set and get the seed value)

You are correct! This issue is handled in FS-UAE like this:
* All calls to random which can affect emulation is replaced with a call to uae_random(). uae_random does not use the system rand functions, but a custom random number generator (Mersenne twister from glib), and this is initialized to the same value on all clients in net play.

The net effect is that the random bits should be calculated identical on all clients. As an extra safe guard, a random number is calculated for each frame and sent to the server to check that the custom random number generators are still in sync.

I found the seed value for IPF decoding when implementing net play, and simply initialized this to 0 in the initial version, but will replace this with a call to uae_random().

[Toni Wilen]

Originally Posted by FrodeSolheim

But if the clients are kept in sync, and using cycle-exact emulation, this should still work? (Of course, fastest possible modes are not supported). I haven't spotted any problems so far, but I am not an Amiga hardware expert, so if you believe there could be a synchronization issue here, I would appreciate any hint/help you can give!

Yes, it should work fine.

[FrodeSolheim]

Originally Posted by AmigaOnline

-input configuration menu
-distributed joystick port swapping

I have released version 0.9.13alpha1 with new input configuration menu (joystick port mode switching should work in net play mode, but I haven't tested it yet):

http://eab.abime.net/showpost.php?p=...&postcount=287

[AmigaOnline]

Originally Posted by FrodeSolheim

I have released version 0.9.13alpha1 with new input configuration menu (joystick port mode switching should work in net play mode, but I haven't tested it yet):

http://eab.abime.net/showpost.php?p=...&postcount=287

Thanks a lot, Frode!

[FrodeSolheim]

Originally Posted by AmigaOnline

Thanks a lot, Frode!

I replaced the links to alpha1 with alpha2. A minor update only: joystick port mode is properly updated on the main menu for other players if one player changes joystick port mode.