I'd quite like to do a file-by-file analysis of the source code. Perhaps one article per file? How should I structure/name this?
That'd be awesome. It'd probably make most sense to create one page per file and just use the file names (the only problem is that foo.c becomes Foo.c, but I think that's bearable), with overview pages as necessary. If you just get it written, it can easily be restructured later on :)
By the way, article titles and headlines should go "Foo bar baz", not "Foo Bar Baz". Fredrik 01:19, 10 Jan 2005 (PST)
Actually on second thoughts I may just put it all on a single page. I'm really not sure I can say that much about each file for it to be worth doing a page for each. If neccessary I can add separate pages for subjects which need more in-depth attention. Like you say, we can always restructure it if neccessary.
That would be most excellent if it happened. To make a suggestion, any knowledge on how the files actually link together, ie what calls what and when, as well as how mods integrate with the retail doom (as retail doom is required for them to run) would be much appreciated. A flow-chart or something similar would really open doors to those just starting to dabble with the code.
- I'm not quite of the opinion any more that one article per file would be a sensible arrangement. Doom is divided up into subsystems, and it makes more sense to me to have articles about individual subsystems than about source files. There are already articles about the Zone memory system, Doom rendering engine, Doom networking engine and others which I think show this. Redirects from source file names to the writeups on their subsystems might be useful, though. Fraggle 08:21, 16 March 2006 (UTC)
Could we maybe get a better link to the Doom source code than 3DDownloads? I don't think anyone likes having to wait in line to get a tiny zip... 184.108.40.206 01:29, 15 July 2007 (UTC)
- Agreed. Not only that, sometimes 3DDownloads just sends you to the homepage instead of actually sending you to where you can download. -Wagi 220.127.116.11 20:08, 16 January 2008 (UTC)
- Er, this has been fixed now as far as I can see ... Fraggle 20:25, 16 January 2008 (UTC)
Does anybody know if there is a list of bugs in the Doom engine that were found fixed in the original source release? For example, I understand the Final Doom Z coordinate bug is not present in the source code. This information would be incredibly valuable to me!
Thanks! Zack 02:04, 25 January 2008 (UTC)
If I recall correctly, the only other bug that's in Vanilla Doom but not in the source release is the one where sounds on MAP08/ExM8 are loud when far away, and quiet when close by. I also remember hearing that the bug where the sky never changes in Doom2 when you get to it via exit switch was fixed in the source release. I'm not sure if an entire list would be possible, as you could probably count them on one hand. -Wagi 18.104.22.168 14:24, 13 May 2008 (UTC)
UML diagrams ?
Please ? : ) It would be of great help if someone who understands the code mades some diagrams explaining it.
- What kind of UML diagram? Do you mean a class diagram? Doom isn't written in an OOP language, so it would be difficult to do such a thing. The source is well-divided into logical modules, though. You'd probably be better off just reading the code. Fraggle 09:34, 13 May 2008 (UTC)