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

Doom Source Ports family tree (simplified, for Wikipedia)

Recommended Posts

Yes, it does, as do several other ports. However, the code for these extensions was added into Prboom, rather than MBF being used as the base for Prboom. The base code for Prboom (from 2.1.0 onward) was LxDoom and LSDLDoom (more info in my post here).

 

Share this post


Link to post

not sure if it is too much work but a scale with the years would be awesome, since I am very unaware but interested on how old all the source ports are

Share this post


Link to post
21 hours ago, Grazza said:

Yes, it does, as do several other ports. However, the code for these extensions was added into Prboom, rather than MBF being used as the base for Prboom. The base code for Prboom (from 2.1.0 onward) was LxDoom and LSDLDoom (more info in my post here).

 

At first, I attempted to draw dotted lines for features borrowed from one port to another, but the result was very confusing !

 

By the way, should there be a direct link between DOOM and BOOM ? (in addition to the line bertween DOSDoom and BOOM)

Share this post


Link to post

I wasn't suggesting that you should have done - quite the opposite, as my intent was to explain to Kroc that the mere existence of shared features is not the basis for lineage in this chart (which would indeed make it look like a spider's web).

Share this post


Link to post

Hey @soner du this is looking awesome :)

 

just to follow up on the CC0 discussion: would you be ok to share the latest .dot source?

 

thanks! 

Share this post


Link to post
8 hours ago, MadGuy said:

Hey where is Classic RBDOOM 3 BFG on this one? Sure it's not perfect but it worth a mention.

 

  Reveal hidden contents

Plus it might be the ONLY modified version of classic DOOM 1.11

 

 

You can add it if you want...

I preferred to only list those ones : https://doomwiki.org/wiki/Comparison_of_source_ports

and their major ancestors.

 

46 minutes ago, Jon said:

Hey @soner du this is looking awesome :)

 

just to follow up on the CC0 discussion: would you be ok to share the latest .dot source?

 

thanks! 

 

It's available on https://commons.wikimedia.org/wiki/File_talk:Doom-Ports.png


Here is it again :

Spoiler



digraph Ports {

/* options graphiques */

/* declaration des noeuds */

node [label="Chocolate Doom", fontsize=10] choco;

node [label="Crispy Doom"] crispy;

node [label="Doomsday Engine"] doomsday;

node [label="Linux Doom", shape=ellipse, color=black, style="filled", fillcolor="grey", fontsize=8] linux;

node [label="JDoom"] jdoom;

node [label="DOSDoom"] dos;

node [label="WinDoom"] win;

node [label="Doom", shape=box, color=red, fillcolor=yellow, fontsize=10] doom;

node [label="Doom95"] 95;

/* clusters */

subgraph clusterboomc {

label="BOOM-compatible";

labeljust="l";

color=lightblue;

fontcolor=blue;

style="filled";

filcolor="lightblue";

node [label="Doom Legacy", shape=ellipse, color=black, fillcolor=white, fontsize=10] legacy;

node [label="Odamex"] odamex;

node [label="Risen3D"] risen3d;

node [label="GZDoom"] gzdoom;

node [label="QZDoom"] qzdoom;

node [label="Zandronum"] zandronum;

node [label="ZDaemon"] zdaemon;

node [label="Eternity Engine"] eternity;

node [label="PrBoom+"] prboomplus;

node [label="Doom Retro"] retro;

node [label="Delphi Doom"] delphi;

node [label="3DGE"] tdge;

node [label="ZDoom", shape=ellipse, color=black, style="filled", fillcolor="grey", fontsize=8] zdoom;

node [label="EDGE"] dge;

node [label="MBF"] mbf;

node [label="SMMU"] smmu;

node [label="PrBoom"] prboom;

node [label="csDoom"] csdoom;

node [label="BOOM"] boom;

node [label="Skulltag"] skulltag;

};

node [label="Doom Classic", shape=box, color=red, fillcolor=yellow] classic;

/* relations */

skulltag -> {zandronum};

boom -> {mbf prboom};

prboom -> {prboomplus classic};

mbf -> smmu;

choco -> {crispy retro};

linux -> {choco dos jdoom zdoom delphi};

dos -> {boom legacy dge};

dge -> tdge;

{doomsday boom} -> risen3d

jdoom -> doomsday;

doom -> linux, boom, win;

win -> 95;

zdoom -> {gzdoom csdoom zdaemon skulltag};

csdoom -> {odamex zdaemon};

gzdoom -> skulltag;

gzdoom -> qzdoom;

qzdoom -> gzdoom;

smmu -> eternity;

}


 

 

Share this post


Link to post

Doom Legacy

What does derived mean after 20 years of borrowing from other ports.

I had to lookup in the logs to even find out that DOSDoom was an ancestor.

The early logs indicate that the developers spent considerable time restoring functionality of the original doom.

I cannot identify any actual feature that was inherited from DOSDoom.  Maybe the options pages.  Everything interesting came afterwards.  The option variables, the console (from quake), freelook, ...

 

DOSDoom has 4 mentions in the source code.

PrBoom has approx. 200 mentions in the source code (and the code is close to identical on many places).

Boom has approx. 750 mentions in the source code (and some actual code borrowed).

 

I think with 1.47 we may be more derived from MBF than from DOSDoom.

 

That lineage chart only represents what DoomLegacy was in 1998.  To represent the current version you have to account for the changes due to 20 years of development, and especially the cross sharing of wad capability.  We share Boom wad capability, inherited from Boom.

With 1.47 there will be MBF wad capability, inherited from MBF, PrBoom, and Eternity Engine.

Those dotted lines seem mightily important to me.

 

 

Edited by wesleyjohnson

Share this post


Link to post

It just means that "descended from" is an inadequate model for describing source port heritage in full and a more accurate model would be a web of derivations snapshotted at some given time. Of course, such a representation is difficult to produce in the first place, and would be difficult to understand or work with as well, given the huge number of connections it would have to represent.

Share this post


Link to post

Inadequate to the point it is misleading of the port anymore.  Perhaps something other than lineage would be more useful.  Lineage usually would indicate an ancestor that it resembled by default, except for notable enhancements.  That is clearly not the case for many of these source ports.  Maybe, some should stand alone, as no longer resembling any ancestor.  Or, instead, the amount of commonality between ports could be indicated by a line and the amount of uniqueness could be indicated by filling in the circle with some color.

 

Share this post


Link to post

One major problem with this chart is that it condenses a port to a single instance.  Unlike people, these ports do not inherit property, titles, or genes.  The code from a particular ancestor can have changed beyond recognition.  They really have a time axis, and should be displayed as bars, and having a lifetime.

 

The 3d floors of DoomLegacy were inherited by some other ports.  Is that not also an important inheritance.

This tree does not show DoomLegacy contributing anything to the other ports.

Software does not have just one or two parents.  It seems to me that a simple geneology tree here is more irrelevant than it is right.

 

Share this post


Link to post

That just about what I expected.  But it shows the truth, that the relationships between ports is not simple, nor elegant, nor pretty.

 

I assume that is showing features inherited (not code borrowed, or else there would be alot more lines), so I have to question what features Chocolate Doom could have contributed to Eternity Engine.

But, in general ..  yes that is more like what I remember

 

 

 

 

Share this post


Link to post
6 minutes ago, wesleyjohnson said:

so I have to question what features Chocolate Doom could have contributed to Eternity Engine.

Demo compatibility and glitch emulation.

Share this post


Link to post
1 minute ago, printz said:

Demo compatibility and glitch emulation.

Also, SDL app state maintenance, PC speaker emulation, and some other minor stuff.

Share this post


Link to post

I would categorize that as code borrowing, not feature implementation.

Implementing Boom generalized linedefs would be feature inherited from Boom.

The code we borrowed actually came from PrBoom, but if you are only going to show feature inheritance, then that indirect source would not have to be shown.   I think that the feature inheritance is probably more important to an end user than code borrowing.

I expect only source port developers would be interested in a tree that showed all the code borrowing too.

 

Share this post


Link to post
38 minutes ago, Quasar said:

Cuz I mean, these are just the ones I can think of off the top of my head :P

I think you're trying to put too much information in one diagram. It's reasonable to assume that every source port is borrowing from every other source port; if you try to represent this it in practice you end up with a fully-connected graph that shows nothing useful. Best to reduce the scope and stick with strict ancestry.

Share this post


Link to post
Just now, fraggle said:

I think you're trying to put too much information in one diagram. It's reasonable to assume that every source port is borrowing from every other source port; if you try to represent this it in practice you end up with a fully-connected graph that shows nothing useful. Best to reduce the scope and stick with strict ancestry.

Right, I know - that's the point I'm driving home with that diagram. It's not complete most likely and it's already too much of a mess to be useful.

Share this post


Link to post

Legacy was based on dosdoom. Just because @wesleyjohnsonwasn’t around back then doesn’t make it any less true.

 

I’d be interested to know which ports took 3D floors from legacy as I know of none, except srb2.

Share this post


Link to post
12 hours ago, Jon said:

I’d be interested to know which ports took 3D floors from legacy as I know of none, except srb2.

None, really. The closest is GZDoom but it only supports the level definitions, it didn't use any of the actual code and relied on its own implementation and rendering. And SRB2 didn't so much as take them from Legacy, rather it is Legacy (warts and all).

Edited by Edward850

Share this post


Link to post

You can also put AutoDoom as derived from Eternity. I should make it more relevant and improve it, but I'm busy with Eternity... Or maybe I should integrate it into Eternity...

Share this post


Link to post

The legacy situation is further complicated by there being two of them: the c++ rewrite that never got there (but apparently isn’t dead) and what Wesley is working on, which imho should assume the mantle of official, but he seems reluctant to do so. 

Share this post


Link to post

Just realized no one has answered Gez's question on page 1.

 

https://doomwiki.org/wiki/CsDoom

 

While Skulltag was built from ZDoom, the networking code was said to be directly inherited from csDoom. Surely that's enough to qualify it as part of Skulltag's (and thus Zandronum's) genealogy? I guess it's less of a parent and more like an uncle or something (rofl) but the two are most definitely related. Even if most of that code has been overhauled and improved since, historically, csDoom was pivotal in Skulltag's development.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×