Odamex is a free, cross-platform (Mac, Windows, Linux) modification of the Doom engine that allows players to easily join servers dedicated to playing Doom online. The goal of Odamex is to add enhancements to Doom while still retaining that "classic Doom feel" we all know and love about the original game.

Odamex is free software, however a copy of Doom or Doom II is recommended to play it. If you do not own Doom, it can be purchased on Steam. Other alternatives include using Freedoom, or the Shareware version of Doom.

Latest version: 0.7.0

Released: March 27, 2014 :: Updated: March 29, 2014
 Source Package  OR 

Events & Tournaments

Odamex Nitro Returns...with UptightDM


That's right, Odamex Nitro is coming back every week just for you! I had a great response to the Toke Memorial session I ran last week, and several people told me I should start up Nitro again. Well, here we are! I was surprised to learn that it had been over 3 years since HeX9109 or myself had anything to do with this event, so I decided to get the old team back together. We've also added two great guys to the team, Doomkid and Alt_Stab, and together we'll be doing our best to bring some kick-ass deathmatch, CTF, and even coop games back to Odamex.

This time around, Odamex Nitro will be held every Friday @ 7:30pm EST. I'll also be working on ways to get the community involved in what we choose to run. There are always going to be wads the four of us have never heard of, and remember, we love to test betas!

HeX9109 mentioned this the other day, and it's something I agree with, Nitro was the most fun when we were testing a brand new wad like a 32in24 or Back to Saturn X. We'll be doing that with our first return session here, running the recently finalized Uptight DM, which is a great newer set of Deathmatch maps. Hope to see everyone back in action!

Nitro Admins

HeX9109
Doomkid
Alt_Stab
HumanBones

Where to find us

irc.quakenet.org #odanitro

WAD: uptightdmfinal
Mode: FFA
Maps: 32 (uptdm01 - uptdm32)
Players: 16+
Server: doomleague.org OR Doomshack OR Funcrusher (being finalized)
Date: Friday, September 2nd, 2016 @ 7:30pm EST

Changelog

5486 - Dr_sean
2016-09-27
Address most of bug 1187. The key binding system used SDL key values instead of those defined in doomkeys.h. A few keys still need to be assigned values in doomkeys.h to fully resolve 1187.
5485 - Russellrice
2016-09-23
-Merge from trunk into SDL20

Bug Tracker

2015-05-12 16:36:50
2015-05-10 17:22:44

News & Updates

Odamex Nitro Returns Every Friday @ 7:30pm EST
You heard it here first, Odamex Nitro is back. We'll be running all you can eat DM, CTF, and Coop every Friday night. Don't miss out!

Check out the details for our first session of UptightDM RIGHT HERE.
Odamex is Looking for Programming Talent
The Odamex Doom source port is looking for someone that is willing to help with the programming side of the project. Odamex is a Client/Server modification of ZDoom 1.22 with some ZDoom 1.23 code imported in. The project is written in C++ for the client and server and uses SDL 1.2 and SDL_Mixer  1.2 as runtime libraries. The entire project is entirely GPL or GPL compatible as well.

Odamex has several advanced features, including on-the-fly wad changing, the ability to trigger between vanilla Doom and ZDoom physics and nuances, map voting, an optional 32bpp renderer, network packet-based multiplayer demos, and backwards reconciliation netcode optimizations for high latency players.

However the last release of Odamex was on March 29, 2014. There have been many code updates following the release but no new versions due to some plans not being completed. There are currently no “horrible” bugs and repeat offender crashes but the project definitely needs optimizations and maintenance.

If you are interested in helping Odamex, please respond here and/or join #odamex- on irc.oftc.net

Projects to consider:
* Implementing Survival Co-op
* Improving BOOM support
* Improving the ACS interpretor
* Implementing UDMF map format
* Improving Heretic and Hexen support
* Heck just pick something and go for it!
Network-related Client CVARs
Network-related Client CVARs

Note that these apply to Odamex 0.7 and may change in future versions!

rate ("Bandwidth" in the Network Options menu)
Sets the maximum bandwidth the client can receive, measured in kilobytes per second. The default value is 200, though setting it higher to 750 will allow for faster in-game downloading if the server allows it.

cl_unlag ("Adjust weapons for lag" in the Network Options menu)
Allows the client to enable or disable backwards reconciliation ("unlagged") for hitscan weapons. Enabled by default, this setting allows a player to aim directly at enemies when firing hitscan weapons such as the shotgun and chaingun.

It works as follows:
Every gametic (there are 35 per second), the server records the position of every player.When the server sees that a player with round-trip latency of X milliseconds pressed the fire button, it temporarily moves all other players to the position they were in X milliseconds ago.The server determines if the shot hit anyone.Players are moved back to their current position.
cl_updaterate ("Position update freq" in the Network Options menu)
Indicates the frequency of position updates a client wishes to receive. The default value of 1 indicates they wish to receive an update every gametic while a value of 2 indicates an update every 2 gametics. More frequent updates lead to greater accuracy at the expense of more bandwidth usage.

cl_interp ("Interpolation time" in the Network Options menu)
Allows a client to smooth the movement of enemy players due to network jitter in the connection between that particular client and the server. This smoothness comes at the expense of increased visual latency.

If the most recently received position update is N, the default value of 1 will display players at position update N - 1. Similarly, a value of 2 will display players at position update N - 2.

Network jitter causes the client to not always receive position updates in a timely manner. If a client displayed position update N - 1 last gametic and has yet to receive a new position update from the server, it can display position N, maintaining accurate, smooth movement even when there is jitter or small latency spikes.

cl_predictlocalplayer
Allows the client to enable or disable client-side prediction of a client's player position. This prediction, enabled by default, allows the client to immediately move its player position based on controller input instead of waiting for confirmation of a new position from the server. This is much more responsive compared to the alternative, which does not change the player position (and in turn the rendered view of the world) until the the client's round-trip latency time to the server has passed.

Although prediction allows for immediate visual feedback, it can also be incorrect. This is often the result of collision with other players or being thrust by weapon damage. When the prediction is incorrect, the client considers the server to be authoritative about the real position of the client's player.

Although most players would find it difficult to play with this CVAR disabled, it is immensely useful in diagnosing recordings of games for debugging purposes.

cl_prednudge ("Smooth collisions" in the Network Options menu)
Sets the amount of interpolation between a client's mispredicted player position and the corrected player position from the server. Valid values range from 0.05 to 1.0. The client can choose how they want to trade off between smoothness and accuracy when their player position is mispredicted (see cl_predictplayerposition for further background information). A value of 0.05 will nudge the player towards the correct position gradually and as smoothly as possible where as a value of 1.0 will instantly jerk the player to the correct position to be as accurate as possible.

cl_predictweapons

cl_predictsectors

cl_predictpickup
Overview of Hitscan Latency Compensation (Unlagged)
Hitscan latency compensation is a topic that causes a great deal of confusion as to how it works and what side effects are to be expected. The community has long ago adopted the term "unlagged", which in itself is a source of confusion but hopefully this post can clarify several points. For further detail on the topic, please read this excellent overview by Valve, from which Odamex's algorithm was derived.

For the examples in this explanation, we will consider two players: Player A with a 150ms ping and Player B with a 20ms ping.

Background info:
Odamex has a fixed frame-rate of 35fps, which means each frame lasts roughly 29ms. That also conveniently corresponds to the network update rate and the game physics update rate.

Odamex also uses a term "world index" to refer to the particular set of actor positions that the client has received from the server and uses to draw the sprites for actors in the game (enemy players, etc).

How it works:
When Player A aims directly at Player B and presses the fire button, his Odamex client will send all of his input (eg, fire-button, mouse angle, etc) to the server as well as the current world index. The server will receive this input from Player A 75ms later. During this time, Player B may have moved significantly and without latency compensation, Player A would miss his shot.

With latency compensation, the server will temporarily move all players except the shooter to their position in the world index that was received from the shooter. In the case of Player A shooting, it means that Player B would be moved to his position 150ms ago. The server then performs hitscan collision detection and then moves all of the players back to their current real position. This compensation allows Player A to aim directly at Player B and successfully hit him, even with adverse network conditions.

One side effect of this compensation can be seen from the point-of-view of Player B. It is possible for Player B to have gotten behind cover of a wall and still be shot by Player A. This is due to the fact that Player A has high latency and thus his input takes a noticeable amount of time to reach the server and during this time, Player B can move behind a wall. The latency compensation will temporarily move Player B to his position at the time Player A pressed fire, which was directly in the line-of-sight of Player A.

Hopefully this description is not too technical and also did not omit any details that are necessary for understanding the way latency compensation works in modern FPS games. Let me know and I can further clarify any points which are not clear.