Talk:PrBoom

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)


 * clarification:

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
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)