Does PrBoom stand for "portable boom"? I always thought it referred to Proff who started the project. Fraggle 16:43, 7 Apr 2005 (EDT)

I thought it was Professor Boom… :-) Ducon 16:58, 7 Apr 2005 (EDT)
Now that I (re)think about it, I'm not entirely sure. I recall it was named PrBoom because it was a windows port of Boom, but I could be wrong here. I'll remove the bit until I can confirm which it actually stands for. Janizdreg 17:11, 7 Apr 2005 (EDT)
11:16 <@Jon> cph: what does pr in prboom stand for?
11:16 <+cph> originally it stood for Proff, I think
I also asked Florian himself about this and he told me PrBoom is short for Proff Boom. Janizdreg 13:23, 8 Apr 2005 (EDT)
Bah, ain’t Proff equal to Professor? ;-) Ducon 23:56, 8 Apr 2005 (EDT)

Source ports using 100% CPU[edit]

The part about "most source ports using 100% CPU" is probably actually correct. The original source code sits in a loop until the next tic occurs, using all of the CPU while it waits. PrBoom and Chocolate Doom put the process to sleep while waiting, allowing other processes to run or the CPU to enter a sleep state and use less power.

If (as I suspect) other source ports haven't changed from the original behavior, they will continue using all the CPU to do nothing, making the comment in the article correct. Fraggle 12:05, 15 June 2009 (UTC)

ZDoom does, unless using the cl_capfps or vsync options. You can get 200+ FPS in ZDoom (some people have reported over 1000 FPS in vanilla levels) because it uses all the CPU available to go as fast as possible. But if capped by the video refresh rate or the ticrate, then it hands the CPU to other programs while it waits. I suppose other uncapped ports do the same. --Gez 12:45, 15 June 2009 (UTC)

announcement of the PrBoom/LxDoom/LsdlDoom merger[edit]

I feel like the URL for this is wrong? --Linguica (talk) 15:27, 16 June 2015 (CDT)

I believe it's a bug in Mailman, because I've seen the same issue with Wikipedia's list archives.  Links suddenly point to the wrong message.  In this case, even headers and bodies appear mismatched [1] [2]!  I hope all those databases haven't been corrupted, although I can't find the bug here so it could be fixed now (recent months look OK in both archives).  Of course that assumes the server admins ever upgrade, and they're probably busy coding.  :7     Ryan W (talk) 17:49, 16 June 2015 (CDT)
and... this is currently the only "pipermail" string anywhere in main space.  (MediaWiki's link search doesn't work because the top-level domain is variable.)  Further, if a new link is added, there's a good chance it isn't broken or the editor has read the message first.  Therefore preventive measures probably aren't needed.    Ryan W (talk) 19:14, 16 June 2015 (CDT)