Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Quake 2 hacking

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,205
Location
Poland
Strap Yourselves In Codex Year of the Donut
I went digging into Quake 2 code. That game brings so many good memories of school truancy. I've been able to analyze and understand several subsystems, e.g. lightmap and immediate mode GL code, "tick"+async, mouse input, network. Few of my changes went into the modern source port already.

Then Deus Ex is interesting. I don't know the internals of that. But I can see their awful lighting implementation, where the light cutoff is too steep even for that level of tech (no SSAO, no soft shadows). In that game's case, dark lighting wasn't meant to obscure bad graphics, but turned out dark and unnaturally dense anyway. Is it bad light placement or something more?

In Quake 2 era we've had shitty indexed pixmaps, less than 24-bit color. Now there's full png/jpeg support and all that. Also very recently someone added full GLSL shader support, with actual fixes to how light values are computed. I particularly like the macro abuse!

I have no idea how the renderer would perform with high visibility range, and why would it perform badly in principle to begin with. The original map size limit is prohibitive, but I recently made a version w/ the size increased from 4096 units to some absurdly high amount. The wire protocol and mod support aren't compatible but it's another excuse to improve upon the wire protocol at least. Interestingly, there was only one instance in baseq2 that depended on the old limit, relating to 3d sound origin.

The open mods (tdm, jump) are fixable enough, given how easy it had been to change server and common code to accept 32-bit origins rather than 16-bit. They're based on either baseq2 or ctf. I'd like to introduce an ABI breakage for mods supporting large maps anyway.

So next I plan to replace the immediate mode renderer with 3.3 or 4.2+ GL and possibly look into making a total conversion with a particular community. Once a modern renderer is done, I can rip out all lightmap code and make a deferred renderer. Despite the old cruft (keyframe animations, etc.). At that point the code starts to look more modern.

Why Quake 2?

1. Carmack's code quality is real fucking good!
2. This is high quality C rather than bad "early days" C++.
3. It's easy to start with an existing project and replace subsystems, rather than start from scratch.
4. Learn GL, and how to use modern GL. Upward mobility at work, not necessarily at the gamedev industry.
5. Netcode was good and now is even better.

I like Fabien Sanglard's analyses, but take the criticisms with a grain of salt. Many issues were fixed in the source ports following the initial release. Animations and server Hz no longer unconditionally run at 10 Hz. There's some crazy shit like MVD support I wouldn't have dreamed of.

TL;DR If you by chance intend to work on the codebase or make a game based upon it, here's my roadmap:

- replace immediate mode with modern deferred mode
- replace lightmaps[1] with deferred rendering
- introduce a new wire protocol version and ABI-breaking changes into few existing mods
- look into BSP code
- look into geometry culling code

In a TC, think about skeletal animation, SSAO, parallax mapping, physics, all that modern nonsense

This is actually fun for me. Original id code is of quality comparable to modern non-game open projects. Compare to Falcon 4.0 that was shit.

[1] They have trouble with some convoluted object geometries. Also they're good for static lights only, causing map makers to prefer simple lights. And so it goes.
 
Last edited:

Twiglard

Poland Stronk
Patron
Staff Member
Joined
Aug 6, 2014
Messages
7,205
Location
Poland
Strap Yourselves In Codex Year of the Donut
It's not that lightmaps are bad. It's that there are barely any lights on the entire maps. Like less than 20 on whole q2dm1 or base1. I can directly show lightmaps instead of textures.

I should probably look into how light falloff works and try make it more linear or log scale or something. Push more out of these few lights.

- made an unofficial patch that in theory allows for maps larger than the official limit. there are also some limits regarding map geometry complexity, can deal with them separately. requires patching mods and editors. not worth much at this point.
- made it work on the mips architecture, without patches
- minor server crash fix

Also got an IDE (CLion) that works properly with C code.
 
Joined
May 5, 2014
Messages
1,677
Regarding the Unreal source code theres only leaked versions available, an early version and its later UE2 incarnation.
The only person legally allowed to use the code is responsible for Unreal 227.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom