Dr. Sean

I'm writing something from scratch but using the TRIBES white-paper as a basis for the message reliability system. There are some things I want to do that just looked too difficult to shoehorn into the TNL libraries. I am looking to have the network message format described in a data-definition language in such a way that the client and server can compose message writing and parsing objects from the format definition. When a client connects to a server, the server sends its message format definition to the client and the client then builds objects to parse each type of message. This would allow the client to connect to a server that uses a different message protocol version. More importantly, it would allow clients to play network demos recorded with older versions automatically. TNL achieves world consistency by always sending the changes in entity state since the last acknowledged state - the same as Q3A. PVS does become an issue with cooperative play, where you have 300 monsters and an assload of projectiles flying everywhere. I plan on using PVS even for DM or CTF in the interest of reducing network latency by transmitting smaller packets. What I've read while researching the topic is that routers do not subject small, fixed-size packets transmitted at regular intervals to as much buffering (read: additional latency) as irregularly sized packets when the router comes under load. So my goal is to send 35 packets per second at 64kbps with a fixed packet-length of 228 bytes (and pad if it's smaller). When the connection between the client and server appears to become congested, the packet-length and the packet frequency is temporarily reduced to avoid those unseemly 2-3 second latency spikes that occur when the router's incoming packet buffer gets filled. Agreed. It looks like you're sending delta states for the entire game world to keep things conceptually simple and I'm sending them on a per-entity basis for finer-grained control. Both methods will get you there. The only important thing is to move away from manually sending network messages for entities like it's 1997.

Surely I do!

Sending changes in an entity's state is indeed a far better scheme than periodically sending an entity's full state. It allows for superior decoupling of the game simulation from the network serialization as entity states are simply serialized at the end of the game loop. I employ a similar scheme in a new branch I am developing based on the TRIBES engine architecture. In my approach, the game play simulation sets a flag whenever it changes the state of an entity. For example, if P_ZMovement() changes an entity's Z position, P_ZMovement calls a function to set a flag that the Z position was changed this during gametic. Under the hood, each entity has a circular buffer of bitfields, with a different bitfield for each of the last N gametics. And each bit of the bitfield represents whether a specific field of an entity's state was modified in that gametic (eg, Z position). Thus when sending a client the delta state of an entity gametics 50 and 55, that entity's bitfields for gametics 50 through 55 are bitwise AND'D together to get all list of all fields that were modified and need to be serialized. This paper describes the architecture of the TRIBES engine and subsequent TNL library. http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tribes_networking_model.pdf Video and slides for similar information: http://coderhump.com/austin08/ This paper describes Doom 3's architecture, which is an advancement over Quake 3 Arena. http://mrelusive.com/publications/papers/The-DOOM-III-Network-Architecture.pdf This video describes Halo's architecture, which is based heavily on the TRIBES architecture. http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking

Sponge from id Software has confirmed it several times on IRC. He's also one of the organizers of QuakeCon and was great to work with regarding the 20th Anniversary tourney at last year's QuakeCon.

I would say the issue is not auto-aim but rather the fact that Zandronum uses your round-trip ping time (calculated once a second) for the unlagged system. This is problematic when your connection has jitter (packets don't always have the same round-trip delivery time), which is usually pretty noticeable when you're playing over-seas. It means that when you press fire, the packet containing your input may not reach the server in the same amount of time as the last ping value and thus your accuracy will suffer.

Doing so may possibly lead to integer overflows when the scale value returned by the function is used, and in particular, rendering when the player walks underneath 2s midtextures. In my experience, 256 was a better value than 1024. Eventually this issue was the catalyst prompting me to rewrite Odamex's renderer to eliminate angle-based scale calculations entirely.

id is definitely aware of the differences. I (and others) have spoken to Sponge regarding the Steam version of Doom 2 and the topic of BFG Edition came up as an example. Whether or not id chooses to introduce new IWAD changes in future releases is up to them but at least the topic of maintaining compatibility is on their radar as well as a few options for making changes without breaking IWAD compatibility (hard-coding the executable to load PWADs containing changed maps instead of changing the IWAD).

Uncapped framerates do not cause additional input latency. However, most ports that have uncapped framerates also use interpolation to approximate the player's view angle and position between 35Hz gametics. This does add a sense of input latency because there is now additional latency in the result of the player's input being displayed to the screen. Interpolation requires two known data points and for a Doom renderer that is trying to interpolate the player's viewing position, those two data points would be the player's position in the current gametic and the player's position in the previous gametic. If it has been 14ms (approximately 50% of the time of a gametic) since the last time the game performed its input handling and physics, interpolation will find the position that is halfway between the previous position and the current position and then render from that interpolated position. So the interpolated position is always somewhere between the current position and the previous position. This creates a varying latency that can range from 0ms to 28.6ms (1/35Hz).

Odamex decouples the rendering frame-rate from the gameplay frame-rate so that they can be completely independent. The net result is that renderer frame-rates can be capped at arbitrary rates, such as 60.0fps or anything that the user wants. When Odamex is rendered at 35fps, there is no game-world interpolation, but with any other frame-rate, interpolation is used determine the position and angle of all actors, lifts, etc. Odamex's code is very much built on the info in this article: http://gafferongames.com/game-physics/fix-your-timestep/

This is very important with the Doom software renderer's method of drawing wall columns, which makes extremely poor use of the CPU's cache and causes the CPU to fetch and cache a line of the destination frame buffer from RAM for each pixel of the column the renderer draws. Fortunately there are some tricks to making better usage of the cache such as drawing four interleaved columns at a time to temporary buffer or by drawing in 64x64 blocks but the speed it takes to fetch from RAM is still a bottleneck.

This was really great exposure for the Doom community and I think the tournament showed FPS players that Doom can be an incredibly exciting game when played competitively. I know Odamex and Doom in general have gained several new players as a result of the stream and the wonderful job Jehar did explaining some of the subtle nuances and quirks of the game as the matches unfolded. I felt fortunate to work with Sponge of id Software to ensure things went smoothly and I think we're all grateful to see Doom take center stage for its 20th anniversary.

In Odamex, the flags are only spawned on the map when you're connected to a server running the CTF game mode (sv_gametype 3). In single player mode, you'll only see the flag pedestals.

When I made a patch that implemented ZDoom 1.23b33 weapons as an option, the vertical spread for the ZDoom 1.23b33 SSG was noticably reduced, with ranges from around 18% to 28% less than that of vanilla Doom's SSG vertical spread. The code you quoted above was what appeared to cause that diversion.

I haven't seen this issue before. Could you provide a screen-shot and hopefully a link to a pastebin of your odamex.cfg file so I can determine which combination of settings you're using? The Detail option in the Video Modes menu is misleading now that I look at it again. "Double Horiz & Double Vert" does not actually increase the level of detail - it instead halves it. Not withstanding that, based on what you wrote, it looks like you're using the option to try to emulate the look of 320x200. I think Odamex would be better served by removing the Detail option and implementing a scaling mode to mimic 320x200 in a proper manner. It should definitely be possible to have the same mouse feel as Chocolate Doom in Odamex. Although Odamex's mouse is very similar to Chocolate Doom's with Odamex's default configuration, it appears Chocolate Doom enables its mouse acceleration code by default. To do this in Odamex, type set mouse_acceleration 2.0 and set mouse_threshold 10.0 into the console.

Although there are numerous differences in the client/server code and how latency compensation, interpolation, and other bits of smoke & mirrors that ports use to try to hide the effects of latency, your post does specifically mention "oldschool" so I'll focus on that aspect alone. IMO, a true oldschool experience would be one capable of exact fidelity with vanilla Doom. To that extent, an oldschool-flavored port should be able to play the vast majority of vanilla LMP demos perfectly to emulate the little quirks, bugs, and nuances of vanilla Doom. The three major client/sever (c/s) ports are all based on different versions of ZDoom, which has notably diverged from vanilla Doom compatibility in favor of a perhaps a more modern game feel. Zandronum is based on the 2.x versions of ZDoom where as ZDaemon is based on ZDoom 1.23b33 and Odamex is based on ZDoom 1.22 with 1.23b33 physics. All three ports make some attempt to offer some degree of (toggleable) vanilla feel beyond what they inherited from ZDoom, with Odamex being the closest (it can play vanilla LMP demos), ZDaemon being second, and Zandronum being a distant third. Some key differences you'll find between Zandronum and vanilla Doom are the physics and the weapon damage. Zandronum has a different vertical spread for the SSG and a different method of calculating the damage per pellet. Some competitive players complain that this SSG feels too weak, but that is hardly conclusive. ZDaemon does not have the same spread or damage that vanilla Doom does, nor does it appear to be the same as ZDoom 1.23b33, however it is closed source and no further information can be determined. Odamex's spread and damage match that of vanilla Doom. While I'm not that well versed on Zandronum or ZDoom 2.x's physics code, I probably qualify as an expert on the ZDoom 1.23b33 code as I added the ZDoom physics code on top of Odamex's vanilla physics code. Some of the general changes all versions of ZDoom have when compared to vanilla is wallrunning in both north and south directions, aircontrol, proper three-dimensional explosion damage/thrust, altered gravity, smoothing of the player's view when going over bumpy terrain, and non-projectile actors moving over/under each other. Typically when you hear competitive players complaining about Zandronum physics, keep in mind that they are typically complaining about the differences between Zandronum/Zdoom 2.x physics and the ZDoom 1.23b33 physics that they prefer, rather than comparing it to vanilla. There appear to be some real differences that do change the feel of the game but I'm sure someone more versed in ZDoom 2.x would be able to offer a better comparison in that direction.