WebMSX Release 5.0 - NetPlay! - Nextor Hard Drive - Turbo 8x

Page 3/4
1 | 2 | | 4

Par tfh

Prophet (2612)

Portrait de tfh

08-05-2018, 12:03

ren wrote:

So, has a news post been submitted?
Didn't tfh do one or two of these in the past as well? Smile

TFH doesn't do submits any more.

Par abslide

Resident (33)

Portrait de abslide

10-05-2018, 06:55

WebMSX HDD does not work after installing SymbOS.
I would like to know how to install SymbOS from WebMSX.
The SymbOS site is:
http://www.symbos.de/download.htm

Par ppeccin

Champion (375)

Portrait de ppeccin

10-05-2018, 16:32

abslide wrote:

WebMSX HDD does not work after installing SymbOS.
I would like to know how to install SymbOS from WebMSX.
The SymbOS site is:
http://www.symbos.de/download.htm

That's because WebMSX includes a standard HardDisk (mass storage) driver, but SymbOS does not follow the standard. It comes with its own drivers for each hardware it knows, and it does not try to use the standard driver implemented on WebMSX.
In other works, SymbOS does not access standard drivers, it talks to the hardware directly, so it cannot access any "new hardware" it does not already know about. And it does not know about WebMSX... Yet.

I will have to write my own driver for the proprietary SymbOS architecture, which I plan to do soon.
Stay tuned! :)

Par Grauw

Ascended (9489)

Portrait de Grauw

10-05-2018, 17:37

Maybe emulate Sunrise IDE with Nextor…

Par ppeccin

Champion (375)

Portrait de ppeccin

10-05-2018, 23:15

Grauw wrote:

Maybe emulate Sunrise IDE with Nextor…

Well, WebMSX is an imaginary machine. It will not emulate specific hardware devices and models.

MSX is a standard, not a product. That's the beauty if it!!!!
That's why the original spec, and also Nextor, they define a standard device driver architecture. If any software respects the spec, then it is said to be MSX compatible and will run in any MSX, including WebMSX or any other future model or machine created on the same spec...

Unfortunately its not the case of SymbOS... I will try to create a device driver for it, if I can find how.
Any suggestions on how to discover the SymbOS driver architecture?

Par Manuel

Ascended (17296)

Portrait de Manuel

11-05-2018, 00:32

Ah, WebMSX is doing high level emulation regarding storage devices?

Can you tell a bit more how you handle latency in the netplay stuff?
So, how to handle the input from remote player(s) being a bit later, i.e. their input being based on emulation state that may be outdated compared to the hosting session... That sounds like the most interesting part of netplay, coding wise.

Par ppeccin

Champion (375)

Portrait de ppeccin

11-05-2018, 03:43

Quote:

Ah, WebMSX is doing high level emulation regarding storage devices?

Yes, its like new hardware that comes with drivers... More or less like that.
Since I don't want to replicate the exact behavior of any specific model, I don't need to implement low level emulation for storage devices... The platform has a driver layer for abstracting this! Smile If SymbOS followed this specs, it would work out of the box.

Quote:

Can you tell a bit more how you handle latency in the netplay stuff?

As I see it, not much can be done to really "correct" the latency experienced by the Client machines, so in fact I don't even try... There is no practical way, at least not one that I can see working.

The NetPlay strategy on WebMSX is really simple (and I think it must be), but it can't eliminate latency. So yes, in a competitive gaming scenario, for instance, machines "closer" to the Server have an advantage as their latency is lower, and the Server machine of course has no latency. Same thing with all real time network games, even modern.

All I try to do is keep all machines as close to the same clock as possible (excluding latency), in the simplest possible way... And its necessary to guarantee that the emulation will be deterministically equal in all machines.

Did I answer your question? Smile

Par Manuel

Ascended (17296)

Portrait de Manuel

11-05-2018, 09:34

Mostly... The point is indeed to keep the emulation in sync with the host on all connected clients. E.g., you're playing Salamander. In the host session, the player hits an enemy and dies, but in the slightly delayed client session, the other player shot that enemy just in time causing that player not to die. That information will come into the host session a bit later. This means both sessions are out of sync. How do you cope with this?
One way would be to get the delayed input from the client and reverse the host a bit to included the delayed input and calculate the new state. Are you doing something like that? Or do you have some other strategy?

Par FiXato

Scribe (1671)

Portrait de FiXato

12-05-2018, 13:03

I'm wondering if it would be an idea to implement support for a more turn-based / asynchronous approach of Netplay as well. Smile

Imagine playing MSX versions of games like Scrabble, Monopoly, Battleship, etc, where you hit a button once you're done with your turn, and it will save the state, and send a notification to your opponent who can then continue with the updated state.
This way both players don't need to be active at the same time, and it could even help with finding opponents, as you could create an 'open' game after your first turn, and anyone could pick it up.
As for the notifications, I guess the simplest way would be by e-mail.

Par ppeccin

Champion (375)

Portrait de ppeccin

12-05-2018, 22:15

Quote:

E.g., you're playing Salamander. In the host session, the player hits an enemy and dies, but in the slightly delayed client session, the other player shot that enemy just in time causing that player not to die. That information will come into the host session a bit later. This means both sessions are out of sync. How do you cope with this?

Actually, the way I do it, this scenario is impossible!

In WebMSX we have a clear separation between parts of the emulation that are completely deterministic, and parts that may be affected by external influences, for instance the controls sockets, cartridge slots, disk drive media changes, etc. Those parts include all the machine interfaces to the world.

Those parts are Net-aware and talk to each other when there is a NetPlay session active, coordinated by the Server machine. All external stimuli are combined in this layer, then all machines "see" the exact same stimuli, at the exact same emulation time. The core parts of the emulation down the path are completely unaware of the NetPlay.

This way, the emulation time may be slightly delayed on the Client machines (due to network latency), but it will never show or make any actions that are only processed locally.

This ensures all machines will always react to the same inputs, and emulate the same thing.

Paulo

Page 3/4
1 | 2 | | 4