3 ms·
I really like Quake 3's code. My favorite parts are: - The client/server network protocol and syncing state - The VM architecture (e.g. most of the game can b
by jacobparker 8y ago
I really like Quake 3's code. My favorite parts are:
- The client/server network protocol and syncing state
- The VM architecture (e.g. most of the game can be compiled by LCC into a custom byte code and interpreted. This was for safely (although I wouldn't be as sure these days) distributing mods iirc. I think the main game was shipped compiled to x86 though. The interface between the VM and the core stuff is via "syscalls" and its fun to see how that's wired up.)
- The player physics/controls (i.e. walk/jump/collisions/etc.) (it's neat how fake first-person player physics always is. This isn't unique to quake 3 but quake 3 had notably good controls.)
It's a bit fun to trace what happens on 'w' keydown/keyup (when bound to walk forward.) When I first saw how that actually worked I was surprised (hint: it types commands invisibly into the command console ;) lots of string copies to do that.)
- jacobparker 8y agoA random thing I just remembered: https://github.com/id-Software/Quake-III-Arena/blob/dbe4ddb10315479fc00086f08e25d968b4b43c49/code/qcommon/msg.c#L1709 https://github.com/id-Software/Quake-III-Arena/blob/dbe4ddb1... They implemented adaptive huffman coding but ironically only use it during static initialization, feeding it with static data (see the defn of msg_hData a few lines up.) Note that the only calls to Huff_addRef are in the init, and notice how it gets called - the loop over msg_hData[i]. I found that pretty funny. I'm guessing there was some plans to use it adaptively but it's not easy/obvious how to keep it in sync reliably...