Can vanilla compatible ports play together?

Since Eternity, PrBoom+ and Chocolate-Doom already do efforts to support vanilla Doom demos and recording, why not extend this compatibility to net play as well? Since they all abide by the same rules, one may think they can also communicate in sync.

What would be the standard? Vanilla netplay over IPX? Even Chocolate didn't keep it.

Besides, in addition to a standard, it'd require getting compatibility hacks inside the netcode.

no, not ipx. Does Chocolate Doom use TCP/IP? And by compatibility I mean exactly the hacks and non-fixes that allow these ports to run plain Doom demos.

The hacks and fixes won't matter much unless all ports support exactly the same network protocol. I have no idea how much work had been invested here.

But it's not enough to have demos running. Depending on the feature set some ports may need different network data in order to work properly.

For example, a port may implement looking up and down, this info needs to be transported across the network so that aiming works as intended.

But now you have something that's no longer really compatible with a port that has no knowledge of this feature unless the network protocol can deal with the data differences caused by this.

You could have all ports use the same packet format (which is, essentially, a demo tic struct with some extra network stuff cobbled on), however they would also need to use the same handshaking, the same kind of conflict/error/delay handling etc. in order to fully understand each other.

And of course, they would all need to be fully vanilla compatible and interpret the packets in the same way, as they would demo tics. And also pretty much limited to vanilla packet limitations like no metadata, limited accuracy etc.

Why not IPX? What's the point of a "vanilla-compatible-compatible netcode" if it's not vanilla-compatible?

Looking up/down is the kind of things I was referring to. The "vanilla-compatible [not actually vanilla-compatible]" multiplayer mode would have to turn off such things while playing netgames. Anything that is turned off when recording demos -- and not that this includes, in some ports, features that are literally "make the map playable at all" -- would have to be turned off for multiplayer too.

Finally, at the moment:
Chocolate Doom uses a client-server architecture.
Eternity uses peer-to-peer netcode. Ladna was working on a client-server branch, but, well, see for yourself.
PrBoom+ sucks for multiplayer, do not use it for that.

There seems to be a bit of confusion here so I'll try to clear things up.

Vanilla Doom has a protocol that it uses to communicate; it uses various different lower-level protocols as transports for that data. For example you can communicate over serial (sersetup.exe) or IPX (ipxsetup.exe); there are also a bunch of third party tools that do the same thing for other transports (TCP/IP etc). LinuxDoom similarly has built-in code that communicates over TCP/IP but it's ultimately the same protocol. Doom doesn't care or "know" how the packets are getting to the other peers.

Most source ports don't support Doom's original protocol any more, including Chocolate Doom. There are a couple of reasons why: firstly setting up a netgame with peer-to-peer-based networking is terrible and clumsy as everyone nowadays has home routers that do NAT; it's much more sensible to route everything through a single server. Secondly, Chocolate Doom's networking does some more advanced things than the original networking code did: temporal compression for ticcmds to reduce packet size, and some more advanced clock / time sync (which unfortunately currently doesn't work very well).

In theory it would probably be possible to implement the original Vanilla protocol, although what the underlying transport would be is an interesting question. For modern networks it would have to be TCP/IP-based which the Vanilla *setup.exe drivers didn't support.

One idea I've considered in the past is making the Chocolate Doom server code also function as a DOSbox IPX server (I recently wrote a standalone DOSbox IPX server so I know what work is involved). If another source port implemented the same thing but the other way round (ability to act as a client to join DOSbox netgames) then it would then theoretically be possible for different source ports to play a game together. But it would probably be quite a huge amount of work and hackery to get it to work, and I'm not sure it would be worth the effort.

Gez said:

Why not IPX? What's the point of a "vanilla-compatible-compatible netcode" if it's not vanilla-compatible?[/url].

Depends what you mean. If it's "IPX wrapped in UDP" (ie. how DOSbox works) then sure, that's certainly doable. If you mean actual, real, on-the-wire IPX then that's probably more difficult because there isn't any cross-platform API for doing it. Certainly there are system-specific APIs (eg. Linux has one) but does anyone really want to waste time setting up IPX nowadays?

No.


And that's kind of the point. There's a demand for vanilla demo compatibility because there are demo records that people may want to play back.

There isn't a demand for vanilla netcode compatibility because you don't play netgames through a time machine with people that are still back in 1995. Online games, contrarily to demos, are transient and keep moving, so there's no reason to keep using a 20 year old protocol to play a new multiplayer session.

Besides, the multiplayer scene has mostly moved to ZDaemon, Zandronum, and Odamex. There just isn't a need for vanilla compatible network protocol.

It's possible to define a network protocol in order for various source ports to communicate. You also avoid a lot of problems by only supporting Vanilla features too, that's for sure.

All that said, to echo Gez, I'm not sure why you would want this. Chocolate Doom has pretty good netcode, considering it's using the synchronous ticcmd_t model, and you can configure Odamex to be Vanilla compatible (I think?). I'm all for standards, but I think it's a stretch.

I think the general question here is that if somehow there was a way for various ports to exchange vanilla-format data packets beyond the handshaking/game setup stage, and with all the complications of the underlying transport layers gone or abstracted away by some sort of super-duper TCP/Serial/Parallel/IPX/Whatever multi-platform network emulation/bridge driver, would they be able to have a decent game together? Would they "understand" each other, to a degree?