fraggle

This kind of Derekphobia has no place on Doomworld

Hi, this has been extensively discussed within the Freedoom project and we have decided not to do this. If someone else wants to start their own similar project that would be great, though it would be preferable if you could avoid confusion by not using the Freedoom name.

I don't think this is a thread is likely to lead to the thoughtful and nuanced discussion that I'm sure you were hoping for. Child abuse and sexual slavery are bad, I don't think you'll find anyone who disagrees. But I agree with roadworx that I think you should find an alternative forum in which to discuss this subject.

Chocolate Doom is a conservative, historically accurate source port that recreates the experience of playing vanilla Doom on modern machines. For common questions, read the FAQ To report a bug, file an issue on Github. But be aware that your bug might be intended behavior. For latest bleeding-edge builds, check out http://latest.chocolate-doom.org. See the first thread for older posts on Chocolate Doom.

Thanks for reporting. The server that the site runs on is currently in the process of being upgraded and it seems we're having a bit of a bumpy ride.

Nobody cares. None of the mods are harassing you, none of us hate you, you don't need to apologize for anything. Please just move on from this whole thing.

I'd certainly call it an advanced topic. It doesn't work very well, most people don't understand it very well (hell, I'm not sure I even understand it properly) and you have to read quite a bit to figure it out. I'd say for a beginner's guide it's best to ignore it and use the deaf monsters flag instead.

DEU repo now includes DETH branch and also ADE2. The Github insights page gives a nice little graph.

That's it. Thanks! Repo now includes this corrected source plus the other 5.0 beta that I mentioned in my previous comment.

That does appear to be it. Thank you! I spoke too soon. This appears to be the gcc port of 5.2, which I already have.

Yes, I saw that DEU.TXT in the older versions explained that. Side note, I just found another DEU5 beta on this CD (duum_1/grafix/deu5_b4.zip), so that's another one I can add to the history. It might be worth checking if there's anything else of interest on that CD.

We've done this thread a million times and we are still no closer to knowing which source port is the "best".

Thank you! There were a few there that I didn't already have; I've incorporated those into the history now. But a note to @deathz0r that DEU52.ZIP is not actually DEU 5.2; it's just another copy of 5.21 with the wrong name. I haven't been able to find a copy of 5.2 either but I reconstructed the (probable) source by comparing the 5.2 and 5.21 GCC ports. Thank you! This is also helpful - it means I now have a mostly-complete history of the DETH 2.x source history. It's a shame that with the 3.0 release they started shipping the source code separately. Here's DETH 2.3 as a repayment of sorts. I saw it wasn't in your .zip. deth23.zip

Thanks - I did see that version I think; unfortunately I'm looking for versions that have source code though, as it's a source code history that I'm trying to build. Anyone have versions of DETH? I've only been able to find three (2.3, 3.6, 4.24). There were definitely more released.

Thank you!! Now incorporated into the history. The site you linked looks very interesting but I wasn't able to download any files from it - I get a 403 access denied error. The DEU history is also now available, though it's a work in progress.

Those are exactly what I'm looking for! Can you please share? And out of curiosity where did you get them from?

I now have a history repository built from the releases of BSP that I've been able to locate. You can get some nice blames of the source files (example) that show how the code changed over time. Thanks to everyone in this thread for locating some of the old versions. Obviously it's an incomplete history; if you have copies of versions that are not in that list please let me know. It's particularly frustrating that I've been unable to find the earlier v2.x releases (bsp20x, bsp21x, bsp22x). The repository is autogenerated so expect the history to be entirely rewritten as I incorporate new things. In particular I've just noticed that the source dating back to v2.3 appears to have been tracked in CVS so I'll be able to get more fine-grained history. I'm in the process of doing the same thing for DEU and its forks. If you have obscure versions of that, let me know.

Interesting! Heads up that wadptr is now on GitHub and I've been doing a bunch of cleanups to the codebase (your comment may have inspired me a bit). If you have improvements like this I would certainly be interested in merging them upstream now.

This is kind of a tangent, but since we're talking about this kind of really early stuff - a while back I went digging through old stuff from textfiles and Usenet myself and collected as many versions of the different Doom FAQs that I could find. The result is here - each of the files has Git history, so you can look at the old versions and even use Blame to see when particular parts were changed. Maybe at some point I'll see if I can find the time to collect some of the source code from these early tools and do the same thing. It really sucks that all his posts are gone. I even went digging through the dumps on archive.org to see if I could find copies of them, but they aren't there either. Particularly frustrating because obviously it was him that posted the old versions of the FAQ.

You can still contribute! I'm reasonably convinced that there are a lot of people who tried Freedoom once 10 years ago, formed a strong opinion about it as a project and haven't tried it again since. For those people, I recommend trying one of the daily builds because the project has changed a LOT.

There's literally a Discord with people working on it every day. Version 1.0 of Freedoom has not yet been released. I'm confused?

That's not the point of Freedoom. I recently added this section to the Freedoom manual. Take a look and maybe it will help to better explain the purpose of the project.

Doom internally represents sidedefs with the side_t type, and the X offset is stored in the textureoffset field. The game then, once per tic, goes through all scrolling linedefs and adds one pixel to the offset (here). Effectively it's exactly the same as if a mapper uses the X offset on a texture to line up neighboring textures, it's just that the game changes it automatically while you're playing. However, there's a discrepancy in what I've just said. It's the sidedefs that store X position but the linedefs that do the scrolling. In the case of packed sidedefs, multiple linedefs share a sidedef, so every tic, the texture offset will be adjusted multiple times. Instead of moving at one pixel per tic, it'll be scrolling at N pixels per tic, where N is the number of linedefs sharing that sidedef. WADptr doesn't do anything to prevent this happening - it just sees multiple identical sidedefs and merges them. However, it *could* do something, which is that it could identify sidedefs used by a linedef of type 48 and ensure they don't get merged. That would fix the problem, but it would require a bugfix to the WADptr codebase. I'm not sure how much work that would be, because I haven't looked at the codebase in quite a while (and it's not particularly great code either) As a workaround, if people have maps where this is happening they can prevent sidedefs from different linedefs from getting merged by making them differ slightly. A simple example would be that you could adjust the X offset on each line so that each one gets a unique value.

Curious where on Earth you learned this nonsense.