Cyberdemon
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Eternity > Netcode: The Quest Begins!
 
Author
All times are GMT. The time now is 09:34. Post New Thread    Post A Reply
Quasar
Moderator


Posts: 2133
Registered: 08-00
EE is now at the point where it needs some basic functionality in netcode so that when changes are made to support player classes, custom weapons, etc., those changes can be tested.

I started the process by adding in anarkavre's i_net.c module from WinMBF, which is a modification of earlier Chocolate Doom netcode. This is just a few calls to SDL_net which allow the high-level netcode to actually transmit and receive packets over UDP.

So far, the upper level netcode's behavior has confirmed every one of my fears: it is completely broken.

Problems found so far:
* If the "server" node (player 1) starts up first, all nodes will go into an infinite loop in D_ArbitrateNetStart
* If the "clients" are started first, the game will connect, run, and on the first gametic bombs out with "Tried to transmit to another node", due to "netgame" being set to false in G_DoNewGame
* If the netgame assignment in G_DoNewGame is removed, the game connects, runs, and then goes completely berserk. Player 2 has control of *both* nodes, and player 1 has no control at all. After walking around a bit using player 2, player 2's game commits an illegal operation, and player 1's game drops to console. If a new game is started from the console using player 1, the game is running at an unlatched framerate (~1000 FPS), the player shakes violently, there is no control, and consistency failure error messages begin appearing in the console.

In short, we've got a REALLY long way to go with this.

Update:
http://doomworld.com/eternity/engine/screenshots/ee_net_p1.png

http://doomworld.com/eternity/engine/screenshots/ee_net_p2.png

I have isolated the console from the netcode and have restored it to its state as of MBF, excepting some modifications which fraggle made in SMMU that stop the game from locking up if the key player drops. This has fixed most if not all of the problems, so EE currently has Doom's original netcode running over UDP ^_^

Last edited by Quasar on 10-16-07 at 03:49
Old Post 10-15-07 18:20 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
Ajapted
Forum Regular


Posts: 681
Registered: 04-02
Seems netcode is the flavour of the month, I'm working on it now for EDGE and the Legacy guys are working on theirs.

Not sure I can offer any useful advice for EE. Understanding how it all works is pretty mind-bending because all the computers are running in parallel, and UDP packets can arrive out-of-order or not at all.

You need a good idea on how it'll flow. For EDGE, the "host" (server) will need to be started first. Then clients will connect to the host. When enough clients have connected, the host will send a "LOAD" command to make everybody load the map, then a "BEGIN" command to actually start the game (set gametic/maketic to 0 and start exchanging ticcmds).

Good luck!
Old Post 10-16-07 03:05 #
Ajapted is offline Profile || Blog || PM || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 2133
Registered: 08-00
We're going to look at implementing Choco Doom's code as a stopgap. We'd eventually like to have a client-server architecture, but that can be a very difficult thing to transition to, especially while retaining compatibility. We hope that Odamex will be helpful in figuring out how to do that.

Right now though it's just the plain old Doom protocol with an SDL_net backend. This should be good enough for me to be able to test modifications made for the new extension module features :)
Old Post 10-16-07 16:34 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
Ajapted
Forum Regular


Posts: 681
Registered: 04-02
Client/Server architecture (as opposed to lock-step) is indeed very difficult. I can't say I recommend it, as it changes everything, a really huge job.

I didn't mean to give the impression that EDGE is using that model (authoritive server, dumb clients), it is not, I'm just using those terms for the connection process. After everyone is connected, it is lock-step model like standard Doom, with a small change of having a reliable connection between host and client which is used for sending lost ticcmds and other admin.
Old Post 10-17-07 00:39 #
Ajapted is offline Profile || Blog || PM || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
AlexMax
Forum Regular


Posts: 757
Registered: 01-03
Ajapted said:
Client/Server architecture (as opposed to lock-step) is indeed very difficult. I can't say I recommend it, as it changes everything, a really huge job.


I'd love to see a doom source port that actually does this the right way instead of hacking it on like csdoom/zdaemon/presumably skulltag/odamex does.
Old Post 10-21-07 21:38 #
AlexMax is offline Profile || Blog || PM || Email || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
Ajapted
Forum Regular


Posts: 681
Registered: 04-02
AlexMax said:
I'd love to see a doom source port that actually does this the right way instead of hacking it on like csdoom/zdaemon/presumably skulltag/odamex does.

Please elaborate.
Old Post 10-22-07 03:22 #
Ajapted is offline Profile || Blog || PM || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 4246
Registered: 07-00
You can do client-server in two ways: either "authoritative server", which is how Quake and all modern games do it, and is indeed a lot of work to implement in Doom. Alternatively, you can have a thin server that just routes packets, which is how PrBoom does it and what I've done for Chocolate Doom as well. With a thin server, you keep most of the original peer to peer structure, but just change how the data is passed around.

You really want to use a thin server at the minimum, because there are advantages just in having a client-server structure for passing data around. One of the biggest ones is that you have less problems with firewalls/NAT gateways (compared to a peer-to-peer system). It's also easier to set up.
Old Post 10-27-07 11:54 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 2133
Registered: 08-00
Thin server is definitely the way to go, at least as a stop-gap implementation. I think that a heavy server offers certain benefits, however, like being able to sync new clients on the fly, and offering more stability (all clients can drop without killing the game).

I'll be looking at Choco Doom's netcode soon, but probably not before the next release. It looks like the Doom protocol works well enough for purposes of testing modifications for the new weapon system and other player-input-altering stuff such as inventory (netcode must transmit inventory use events). That's all I needed to proceed with the current target feature set for 3.37.00 release ;)
Old Post 10-30-07 20:46 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
AlexMax
Forum Regular


Posts: 757
Registered: 01-03
Ajapted said:

Please elaborate.


Modern Doom multiplayer source ports basically "hacks" heavy server on top of the origional doom sources. It works, but because doom was not designed with client/server in mind, there are lots of little bugs, oddities and inconsistancies that are left over from the conversion. Also, in Odamex and ZDaemon at least, it's still possible to start the game in 'single player' mode, where there is no concept of client and server.

On the other hand Quake (and most other modern games) were designed from the ground up for client/server multiplayer. There is no single player mode, and when you start a 'single player game' it essentually starts a server in the background and has the client connect to loopback. Presumably, since it was designed from the ground up with client/server in mind, you don't have any of the oddities that you find in doom multiplayer source ports.

From my limited understanding of the doom source compared to the quake source, doing things the "right" way would be very tedious and would almost guarentee that you wouldn't be able to keep things like Demo Compatability. However, considering that Quake and Quakeworld use two distinct demo formats, among other things (such as physics), and everyone has gotten along fine, I'm wondering how much of an issue it actually is.

Only problem is what you would call a net-optimized Doom. Doomworld? :P

Last edited by AlexMax on 12-01-07 at 04:37
Old Post 11-24-07 01:30 #
AlexMax is offline Profile || Blog || PM || Email || Search || Add Buddy Report to mod || IP || Edit/Delete || Quote
All times are GMT. The time now is 09:34. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Eternity > Netcode: The Quest Begins!

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts 		HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Forums Directory