Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
atroche

A quick comparison of the size of various Doom codebases

Recommended Posts

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!

VkQWvwI.png

WnB3VPK.png

Share this post


Link to post

I bet PrBoom+ has a huge number of lines of code, given how it has those compatibility options. Where is PrBoom+ anyway?

Share this post


Link to post
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.

Share this post


Link to post
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.

 

 

1-dlEI2_15zpoKUSI4wMRF_w.png

Share this post


Link to post
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?

Share this post


Link to post

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.

 

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

Interesting about Mocha Doom, I guess it really shows just how much work was needed to move to a completely different language.

Share this post


Link to post
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.)

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

Lines of code is one thing, but how about some more interesting static analysis?  Try messing around with CodeCityCodescene, 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 by david_a

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×