atroche Posted July 20, 2017 Hey guys, I wrote a post about running CLOC over various id tech games and source ports. I've attached the key bar charts to this post. I'm by no means an expert, so let me know if I got anything wrong in that post. I'm definitely not trying to make any points or arguments about the various ports; this is just a tiny first step in understanding Doom engines better. Cheers! 3 Share this post Link to post
Voros Posted July 20, 2017 I bet PrBoom+ has a huge number of lines of code, given how it has those compatibility options. Where is PrBoom+ anyway? 0 Share this post Link to post
Linguica Posted July 20, 2017 Quote I’m a big fan of Chocolate Doom. But for a port whose chief goal is to “accurately reproduce the experience of Doom as it was played in the 1990s”, there sure is a a lot of code. Can’t wait to dive in and find out why. The Chocolate Doom codebase encompasses Chocolate Doom, Chocolate Heretic, Chocolate Hexen, and Chocolate Strife, for one thing. 5 Share this post Link to post
atroche Posted July 20, 2017 25 minutes ago, Linguica said: The Chocolate Doom codebase encompasses Chocolate Doom, Chocolate Heretic, Chocolate Hexen, and Chocolate Strife, for one thing. Updated! Thanks for that. 0 Share this post Link to post
atroche Posted July 20, 2017 28 minutes ago, Voros said: I bet PrBoom+ has a huge number of lines of code, given how it has those compatibility options. Where is PrBoom+ anyway? Ran out of time, gotta head out now, any chance you'd run CLOC over it and let me know? 0 Share this post Link to post
Graf Zahl Posted July 20, 2017 (edited) I wonder where Doomsday Engine would land on the list. I haven't counted, but the repository is huge, even compared to GZDoom. Also, regarding GZDoom and ZDoom: What parts did you count? Only the base engine or also the external libraries that are mainly shipped along as a matter of convenience (like GME, DUMB, libjpeg, 7z and zlib?) Let's also not forget that a significant portion of GZDoom 3.1 code is present in the form of scripts. 0 Share this post Link to post
dpJudas Posted July 20, 2017 Source code line count is a rather silly metric. The jump from ZDoom to GZDoom is most likely because of the two extra renderers (softpoly and the GL renderer). The refactored software renderer is also most certainly higher in line count because the original r_* files consisted of densely packed functions using global variables to pass data around. The refactored version puts that in classes. Those extra header files add up. All this really shows are three things that are generally true for all code from the 1990's: The original codebase is not very large. This is because CPU speed and memory was very limited back then. As a result the data structures are all based around static global arrays and other constructs that scale poorly. More modern C++ coding styles also means a lot more lines of code. Class definitions alone makes C++ code 25% larger than pure C. Likewise for other stuff like not using fixed array sizes, fixed memory layouts, not reading data structures directly into their final C structs, etc. More features means more lines of code. And that new code is generally coded in more modern ways as well. Next up: the static code analyzer reveals that there are more reported potential issues the larger the codebase is. 3 Share this post Link to post
chungy Posted July 20, 2017 16 hours ago, Graf Zahl said: I wonder where Doomsday Engine would land on the list. I haven't counted, but the repository is huge, even compared to GZDoom. The compile times reflect that. GZDoom on a ~10 year old system takes around 12 minutes to compile, which is pretty similar to Doom 3's compile time, actually. Doomsday takes over an hour. I'm not joking. 1 Share this post Link to post
Memfis Posted July 21, 2017 Interesting about Mocha Doom, I guess it really shows just how much work was needed to move to a completely different language. 0 Share this post Link to post
kb1 Posted July 21, 2017 21 hours ago, dpJudas said: Source code line count is a rather silly metric. The jump from ZDoom to GZDoom is most likely because of the two extra renderers (softpoly and the GL renderer). Silly, indeed, especially if you're getting paid per line count...(yep, that used to be how it was done. Lots of teeny-tiny lines.) 0 Share this post Link to post
Altazimuth Posted July 21, 2017 I echo similar sentiments here. Stuff like content definition languages will bulk up the repo size, ZDoom's moreso than Eternity due to how much of the engine is scriptified, and how much more stuff is definied by DECORATE than EDF currently (though I'm sure that gap will close over time with a more feature-complete EDF). Additionally, many ports will have to add parsers for the various lumps that need to be parsed, like MAPINFO or SNDINFO or other similar stuff. With all that said, I'd be interested in seeing what the code line count for Heretic and Hexen are compared to Doom. 9 hours ago, chungy said: Doomsday takes over an hour [to compile]. Sweet Jesus, what makes it so damn massive? 0 Share this post Link to post
Graf Zahl Posted July 21, 2017 20 minutes ago, Altazimuth said: Sweet Jesus, what makes it so damn massive? An entirely different approach to development. It uses Qt to implement a highly visual and modern looking framework in which the games run. The actual game code isn't really what makes this large. But even worse than the long compile times is that starting the engine allocates a whopping 500MB of RAM before any game is being started. For comparison: Starting MAP01 on GZDoom allocates 88 MB - still much but unavoidable because a large chunk of that is done by the graphics driver. The software renderer sits around 21 MB. I think it's rather pointless to discuss the pros and cons of Doomsday's approach here - the engine is clearly made for an entirely different target audience than what hangs around at Doomworld. 3 Share this post Link to post
chungy Posted July 21, 2017 Doomsday really wants to be a generic framework for game based on 2D-ish maps and sprites. Rudimentary support for Wolfenstein 3D and Duke Nukem 3D exists, both of which are very different from Doom. I think the compile times for it are primarily due to their over-(ab)use of C++ templates that always makes things slow to build. 0 Share this post Link to post
david_a Posted July 31, 2017 (edited) Lines of code is one thing, but how about some more interesting static analysis? Try messing around with CodeCity, Codescene, or Gource (disclaimer - I have not tried using any of these on C/C++ code). Edit: I've seen another one that visualizes the source like WinDirStat does for files but I can't find it. I don't even know what that type of visualization is called; there must be some standard name for it. I think it also had color coding to visualize how problematic a particular class/module/whatever is. Edited July 31, 2017 by david_a 0 Share this post Link to post
Maes Posted August 1, 2017 On 7/21/2017 at 3:56 AM, Memfis said: Interesting about Mocha Doom, I guess it really shows just how much work was needed to move to a completely different language. If anything, I'm surprised it barely surpasses Chocolate Doom, which is practically 95% vanilla. OK, under the hood lots of stuff in Mocha are virtually identical to Linux Doom v1.10, from which it originated. But considering how much fluff, support classes, interfaces, layers of abstraction etc. I had to add, and the fact that there's a good amount of dead code, testers, utils etc. it's surprising that it's only within a factor of 2 of the original. 0 Share this post Link to post
Gez Posted August 1, 2017 What could be more interesting would be if you had information about how much code is used for what - X lines of game code, Y lines of platform support code, Z lines for graphic rendering, T for audio rendering, U for resource management, etc. 0 Share this post Link to post