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.
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: