Hacker's Guide
Contents
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.