riderr3 Posted December 15, 2017 (edited) On 08.12.2017 at 1:23 PM, soner du said: Looks like Doom95 is... 4 Share this post Link to post
Kroc Posted December 23, 2017 (edited) Doesn't PrBoom/PrBoom+ implement MBF's extensions? edit: yes, it does: https://doomwiki.org/wiki/PrBoom 0 Share this post Link to post
Grazza Posted December 23, 2017 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). 1 Share this post Link to post
termrork Posted December 24, 2017 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 1 Share this post Link to post
soner du Posted December 24, 2017 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) 0 Share this post Link to post
Grazza Posted December 24, 2017 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). 0 Share this post Link to post
soner du Posted March 2, 2018 I've updated the French wikipedia article : https://fr.wikipedia.org/wiki/Portages_de_Doom and also the English-language one : https://en.wikipedia.org/wiki/List_of_Doom_source_ports 2 Share this post Link to post
MadGuy Posted March 18, 2018 (edited) Hey where is Classic RBDOOM 3 BFG on this one? Sure it's not perfect but it worth a mention. Spoiler Plus it might be the ONLY modified version of classic DOOM 1.11 0 Share this post Link to post
Jon Posted March 19, 2018 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! 0 Share this post Link to post
soner du Posted March 19, 2018 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; } 1 Share this post Link to post
wesleyjohnson Posted April 4, 2018 (edited) 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 April 4, 2018 by wesleyjohnson 0 Share this post Link to post
Quasar Posted April 4, 2018 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. 0 Share this post Link to post
wesleyjohnson Posted April 4, 2018 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. 0 Share this post Link to post
Quasar Posted April 4, 2018 Cuz I mean, these are just the ones I can think of off the top of my head :P 0 Share this post Link to post
wesleyjohnson Posted April 4, 2018 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. 1 Share this post Link to post
wesleyjohnson Posted April 4, 2018 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 0 Share this post Link to post
printz Posted April 4, 2018 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. 0 Share this post Link to post
Quasar Posted April 4, 2018 1 minute ago, printz said: Demo compatibility and glitch emulation. Also, SDL app state maintenance, PC speaker emulation, and some other minor stuff. 0 Share this post Link to post
wesleyjohnson Posted April 4, 2018 (edited) 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. 0 Share this post Link to post
fraggle Posted April 4, 2018 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. 0 Share this post Link to post
Quasar Posted April 4, 2018 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. 0 Share this post Link to post
Jon Posted April 5, 2018 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. 0 Share this post Link to post
Edward850 Posted April 5, 2018 (edited) 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 April 5, 2018 by Edward850 1 Share this post Link to post
printz Posted April 5, 2018 (edited) 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... 1 Share this post Link to post
Jon Posted April 5, 2018 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. 1 Share this post Link to post
Doomkid Posted April 5, 2018 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. 0 Share this post Link to post