taniwha wrote:Nice, that one has been bugging me for a long time (but never enough to do anything about it). However, why not SV_LinkEdict (ent, ent->v.movetype != MOVETYPE_NOCLIP)? A good compiler will do the same thing (I've seen gcc do it), but I feel the one call is clearer than two separate calls. Can even do SV_LinkEdict (ent, !developer.value || ent->v.movetype != MOVETYPE_NOCLIP).
I think this is one of those things that id never fixed due to lack of time and pressing need, rather than intended design.
ps, I prefer to use "if" to select different code paths rather than simple parameter values (unless things start getting too messy, then I'll use an "if"). Also, if you prefer to keep the ==, use !(ent->v.movetype == MOVETYPE_NOCLIP).
Making code easier to read for people who have less experience with the language and may be confused if they see a condition as a function param I guess, but overall it's not a big deal and about as useful a point of discussion as an argument over brace styles. On the other hand, if you ever want to add another condition in which something different is done, if ... else makes it easier to do so and without having to disrupt pre-existing code too much, so it has it's benefits. I've been burned by that one before when trying to be too cutesy and reduce lines of code in this manner - future maintainability can be a very large motivator.
Specific example from my own code:
if (RealFogDensity > 0)
Shader = &d3d_AliasPixelShaders[SS_MESHFOG];
else Shader = &d3d_AliasPixelShaders[SS_MESH];
Why not use a ternary operator here? Because if I ever wanted to add a third condition in which a different pixel shader was selected I end up with a mess of nested ternary operators. And a fourth condition? Hello potential bugs, goodbye easy maintainability.
Ultimately the purpose of tutorials is to show info, not to be one person's ideal of syntactically perfect.
Another useful addition for noclipping, by the way:
if (r_viewleaf->contents == CONTENTS_SOLID)
glClearColor (0.2, 0.2, 0.2, 1.0); // or whatever...
That can be optimized out into a single glClear call in R_Clear if people prefer, but noclip isn't exactly a high-performance mode anyway.