void FuckingWellSetTheDocumentNameAndDontBloodyIgnoreMeYouCunt(LPCSTR psDocName)
{
if (gpLastOpenedModViewDoc)
{ // make absolutely fucking sure this bastard does as it's told... //
gpLastOpenedModViewDoc->SetPathName(psDocName,false);
gpLastOpenedModViewDoc->SetTitle (psDocName);
}
}
My heart goes out to whatever programmer had to meet that deadline. There are a lot more gems in the source tree if you just run:
Preferring sourceforge over github seems like an unusual choice, I didn't realise anyone still used it. It's a git repo too, I wonder why they did that?
Just to name a few. As a project admin of fceultra I cannot say that I'm 100% pleased with the UI of the bugtracker and the sf does have its quirks, but sourceforge has had a much better track record than github in respect to uptime. My question to you is "Why not?"
Tbh, I was speaking from a position of ignorance. The last time I used sourceforge properly must have been circa 2006/7 and it was an abomination then - clearly that is not the case now.
It definitely felt cleaner from a UI perspective today (albeit not github-clean) and the sluggish document load times that I remember were also not in evidence.
The open-source ecosystem is definitely richer for every hosting solution that exists, sf included, so if my comment seemed sneery I apologise. It just surprised me at the time is all.
Even with your reasoning "Jedi Knight 2" and "Jedi Knight 3" were the games that were open sourced (Outcast and Academy). I would love to see Dark Forces II: Jedi Knight get open sourced by LucasArts however :)
I have no idea why it's necessary at all. In fact why not get rid of the blog spam altogether and link straight to the code. Yes, I realise RPS isn't exactly a small site and has quite the following (which seems to extend to HN as well, apparently), but their article adds nothing of real value apart from a quote that was pulled from another article on Kotaku.
The source code for the engine should compile without the assets. Or at least with some minor modification to the source tree. Take a look at these other commercial games who have released the source code of the engine but kept the assets proprietary:
https://en.wikipedia.org/wiki/Duke_Nukem_3D
https://en.wikipedia.org/wiki/Doom_%28series%29 (1, 2, and 3)
https://en.wikipedia.org/wiki/Quake_%28series%29 (1, 2, 3, and 4)
I'm confident that there are others but I can't think of any off-hand. These open source contributions are a gift that allows the open source community to create ports to initially unsupported platforms and to enhance the engine. Have you checked out any of the enhanced doom ports? (http://dengine.net/). There are even user-contributed HD assets for Duke Nukem 3d (http://hrp.duke4.net/download.php).
Use of "structured gotos" for error handling is perfectly reasonable. Internal returns are far, far worse sources of error (mostly resource leaks, in my experience). Having functions with single exit points and avoiding contortions that involve extra control variables is better than the mindless avoidance of 'goto'.
I'm equally repulsed by huge, highly nested functions. However, I'd have to say that the game play provided by this function was one of my favorite parts of Jedi Outcast.
The nesting is too deep imho, but apart from that it looks ok. This looks more like a design problem, because there are lots of special cases, but the code style is ok.
That function is almost 1500 lines long, full of complex nested if conditions and commented out blocks. I understand how code (especially game character control code) grows to become like that, and I've probably been guilty of some similar horrors myself, but the most I can do with such code style is excuse it.
Sometimes the program logic consists of hundreds of cases and putting it all into one function is a good solution, since you see the complexity.
I know that object-oriented best practice would suggest a lot of different classes and using dynamic dispatch for switching. That might even be faster. However, I dislike the fact that this scatters the logic across hundreds of files.
The best solution would be to simplify the logic, but this is also the most costly/time consuming variant.
I was also surprised to see these huge functions with multiple nested layers. Is it common for game development? Or it was just a quick hack on top of Quake engine?
Yes, it's very common in player / vehicle controller code.
People start with a clean model of how the player should move, using minimal physics, then add layer upon layer of special case code for various environmental / state / networking edge-cases.
It's usually what makes the game actually feel good to play.
I've heard looking at the first person movement code for Valve's games will make you wish for your own death, but stripping out the weird stuff which looks ideologically wrong just makes the game play worse.
Skimming through the academy source, some are fine, some are not.
For example, codemp/game/g_saga.c uses goto just fine. Three "goto failure" jump to the end of the function to handle the error case differently than a normal return. Not a very good example for proper goto use, but ok.
In contrast, codemp/cgame/cg_players.c should be refactored. It seems to be model loading code. If the loading fails, some gotos jump to the start of the function and using a flag variable a default model "kyle" is used instead of the arguments. If the default model is broken, this becomes an infinite loop. My style suggestion:
if (loadModel(foo)) return;
if (loadModel(default)) return;
assert (false && "fallback/default model broken");