[mike_s]

I think if I could work my whole system a bit, I could make it where players that play Duke Nukem from Eduke32 can connect to those who use my driver to play Duke Nukem for DOS.

I looked at manuals for Eduke32 Here. And its suggesting anyone who wants multiplayer with an older Eduke32 can use Yang multiplayer client. (I'm going to replace multiplayer clients with a web version in my driver suite.) But I did notice something interesting....

In DOS duke Nukem 3D, the parameter to -net is a pointer to multiplayer game data which contains an interrupt address for the networking code. The game data is illustrated in the README.TXT file contained in this zip file from 3D realms.

Like Eduke32, my driver is useless without valid Duke Nukem 3D components.

So now the question remains...

How to associate?

Because Eduke32 is (for the most part) a modification of the presentation of Duke Nukem so that high graphics and more operating systems are supported, I think I could get a lobby consisting of some players on Eduke32 and some on DOS duke Nukem via my driver. This will be GRAND!

---RAVE---
it would be so grand that you could backup the whole gaming experience on a CD-ROM or even a Zip drive (if you still have those) Then if your computer crashes, pop the media in and you're good to go. LOL
---END RAVE---


Anyways. What I want to know is, would the underlying network code remain untouched?
With the sources to the Dos Duke Nukem Commit specification, I can only predict the network data to and from a player can be up to 2048 bytes in length but doesn't describe the data in detail. Then again the original commit driver was meant to work for multiple games (including Shadow Warrior), so I would predict the data itself is dependent on what game is being played.


If I were to adopt Eduke32, I'm trying to figure out how to blend it in to my lobby system.

Going by the Eduke32 multiplayer manual last edited almost 10 years ago, it states the host could start with the "-server" parameter and I think each client can start with the "-connect xxx.xxx.xxx.xxx:yyyy" where xxx are digits to the IPv4 address and yyyy are digits to the port. Would all IP addresses here be on the UDP/IP protocol? Because that is faster for gaming than TCP/IP. Also, if this setup is true, I'm wondering how two "clients" could connect to each other, unless all networking is passed through the game host's PC.

Also, other than using IP addresses as parameters for clients, is the underlying network code the same as in the original Duke Nukem 3D when the game is in action or has that been modified? By this, I don't mean the protocol the code travels through the net over (UDP vs IPX), I mean the data format of the code itself.

And is there anything special I need to be aware of with regards to the networking functionality to Eduke32?

[oasiz]

You will not get eduke32 and DOS players working together as the games are fundamentally different by this point.

[Striker]

The mainline EDuke32 networking code is drastically different, and isn't even deterministic lockstep anymore. It's using an incomplete Client/Server Authoritative networking model. You won't be able to get them to work together. Even if the old lockstep code was still there, you'd still not be able to get them to network properly, because the actual game code is drastically different, and won't have the same deterministic outcome.

[mike_s]

Striker, on 12 July 2021 - 03:07 AM, said:

The mainline EDuke32 networking code is drastically different, and isn't even deterministic lockstep anymore. It's using an incomplete Client/Server Authoritative networking model. You won't be able to get them to work together. Even if the old lockstep code was still there, you'd still not be able to get them to network properly, because the actual game code is drastically different, and won't have the same deterministic outcome.

I might be able to.

The thing with the DOS duke nukem is that the COMMIT driver that was shipped with it controls ALL the underlying networking transport functions which includes player addresses. At the time, the data is transferred through serial lines or IPX protocol but I don't know the name of the addressing at the time.

The games themselves have the ability to control what specific game data goes out and identifies each remote player simply by a player number. Then it can also request data, and if the player number returned is not -1, then it had data from the player number returned. This means it is up to the COMMIT driver to transport data to and from the right places, which in effect, it can control data flow and even data speed. It can even scramble the original data but will never know how to determine the data to expect from the local game itself.

Having said this, the end goal of my driver is to learn the IP address and open port number of each player in a game, and associate each IP:port pair with a unique player number so when the game sends or receives data, it is transported across today's UDP/IP network to the appropriate network.

I may be able to do a client-server authoritive model as you mentioned, because at the beginning, what I want my client to do is make sure everyone is connected in the lobby before the game starts, then on the usual Duke Nukem game loading screen (with the red bar at top), the loading speed would be fast because everyone would have been connected at that point. This means I may be able to synchronize with Eduke32's startup sequence of connecting to a master.

The only way I can't see my driver being able to associate Eduke32's is if the network data portion during gameplay has been so modified to the point where it doesn't mimic the original data being transferred back and forth during the old COMMIT days of duke nukem.

Since I am able to use the latest Eduke32 for win32 in my linux box, I'll do some tinkering to see if I could make my networking coding compatible with it. After all, the author states that Eduke32 is a "port" so I would think it modifies the original source code so that networking and advanced video features are built in while leaving the original the code the same.

Anyway, I'll play around with the original Duke Nukem 3D and the Eduke32 32-bit and see if I can get lucky.

[mike_s]

I did notice that the -net switch is not supported on Eduke32 since a certain version
But I'm wondering if the author (Termin-X) and I could create a unified API at the network level somewhere down the road so DOS duke Nukem 3D and Eduke32 can connect together seamlessly.

[NY00123]

The thing is, even different DOS versions (with sufficiently different behaviors) are incompatible with each other. The original Duke3D sources have a version check. Without it, chances are a game would go out of sync after a short while.

EDuke32 is simply too different from any of the original DOS versions. Even DOS versions 1.4 and 1.5 may have incompatibilities between them, while EDuke32 has significantly more (mostly 15+ years of changes).

[Phredreeke]

mike_s, on 12 July 2021 - 01:42 PM, said:

I did notice that the -net switch is not supported on Eduke32 since a certain version
But I'm wondering if the author (Termin-X) and I could create a unified API at the network level somewhere down the road so DOS duke Nukem 3D and Eduke32 can connect together seamlessly.

I don't think you realise the state of EDuke32 in regards to multiplayer. If you really want to approach this do it with a port closer to vanilla (such as Rednukem or DukeGDX)

[Striker]

mike_s, on 12 July 2021 - 01:38 PM, said:

I might be able to.

The thing with the DOS duke nukem is that the COMMIT driver that was shipped with it controls ALL the underlying networking transport functions which includes player addresses. At the time, the data is transferred through serial lines or IPX protocol but I don't know the name of the addressing at the time.

The games themselves have the ability to control what specific game data goes out and identifies each remote player simply by a player number. Then it can also request data, and if the player number returned is not -1, then it had data from the player number returned. This means it is up to the COMMIT driver to transport data to and from the right places, which in effect, it can control data flow and even data speed. It can even scramble the original data but will never know how to determine the data to expect from the local game itself.

Having said this, the end goal of my driver is to learn the IP address and open port number of each player in a game, and associate each IP:port pair with a unique player number so when the game sends or receives data, it is transported across today's UDP/IP network to the appropriate network.

I may be able to do a client-server authoritive model as you mentioned, because at the beginning, what I want my client to do is make sure everyone is connected in the lobby before the game starts, then on the usual Duke Nukem game loading screen (with the red bar at top), the loading speed would be fast because everyone would have been connected at that point. This means I may be able to synchronize with Eduke32's startup sequence of connecting to a master.

The only way I can't see my driver being able to associate Eduke32's is if the network data portion during gameplay has been so modified to the point where it doesn't mimic the original data being transferred back and forth during the old COMMIT days of duke nukem.

Since I am able to use the latest Eduke32 for win32 in my linux box, I'll do some tinkering to see if I could make my networking coding compatible with it. After all, the author states that Eduke32 is a "port" so I would think it modifies the original source code so that networking and advanced video features are built in while leaving the original the code the same.

Anyway, I'll play around with the original Duke Nukem 3D and the Eduke32 32-bit and see if I can get lucky.

The only thing Duke3D networks are inputs. Things like player and enemy locations are not. Unless you're planning to memory hook into all of the game's linked lists and arrays, and completely rewrite how DOS Duke functions at the base level, it's not going to work. Even then, EDuke32's netcode in and of itself is broken/unfinished.

[mike_s]

Striker, on 14 July 2021 - 01:16 PM, said:

The only thing Duke3D networks are inputs. Things like player and enemy locations are not. Unless you're planning to memory hook into all of the game's linked lists and arrays, and completely rewrite how DOS Duke functions at the base level, it's not going to work. Even then, EDuke32's netcode in and of itself is broken/unfinished.

In that case I'll continue with my own driver and hope for the best