Revision as of 14:20, 5 May 2008

Getting Started

You'll want to have a look at our svn and bugs pages.

Code structure

Conventional file prefix

• am_*: automap related code
• c_*: console related code
• cl_*: client only code
• d_*: game/net code
• f_*: finale related code
• g_*: game related code
• hu_*: hud related code
• i_*: system/hardware dependant code
• m_*: ???
• p_*: game/object related code
• r_*: render related code
• s_*: sound related code
• sv_*: server only code
• st_*: ??? (mostly hud render related code)
• v_*: video related code
• wi_*: intermission related code
• z_*: memory allocation related code

Files of interest

• i_main.cpp: application entry point

Style and guidelines

See the coding standard

Subsystems, APIs, and Interfaces

Odamex is a very large and deep program with around 13 years worth of hacks and additions added to it. It can be very daunting to a new developer, so in this section we will try to document some of the interfaces provided by the source and some of the quirks that need to be accounted for.

Network Interface

The network interface is rather simple and is composed of multiple Read/Write functions. These functions wrap converting from host to network byte order, building packets, and sending data. They are mainly composed of MSG_Read* and MSG_Write* The wildcards can be replaced with anything from the following table

TODO: add table TODO: explain some other network functions and when they should be used

Players

Map Objects

szp pointers

Proper practices considering networking

Networking

Odamex uses UDP

Debugging the client on Linux

There's a problem with breakpoints and SDL under Linux. When a breakpoint pauses execution, the client keeps a lock on the mouse and keyboard (you can no longer do anything). If you kill the client process, you lose the breakpoint info. The current workaround is to use the -nomouse commandline parameter.