ZDoom

I don't know if it was this bugfix or possibly the code sanity update, but one of the changes made most recently introduced a crash in GZDoom.

http://forum.drdteam.org/viewtopic.php?f=24&t=6533 Already reported here.

Fixed indeed. It's amazing how I literally could hear the difference when starting 3 instances of GZDoom - it's so much more quiet now... :mrgreen:

Can't test on Windows at the moment, but on OS X the issue is gone.
Taking into account that excessive CPU load was caused by a busy loop in common code, the problem should be solved for all platforms. Running multiple instances should be smooth now.

Applied, now I need to run some tests.

I'll check this evening.

How's this? https://github.com/rheit/zdoom/pull/255

Will anything be done about this? It's really annoying and if nothing happens I'll be forced to undo it as it causes a shitload of problems if the game is put in the background.

Here's another one:

http://forum.drdteam.org/viewtopic.php?f=24&t=6527

[quote="Enjay"]once I had a particular game in focus, I was still able to play that copy of the game (Doom2 map01) with no obvious difficulties:[/quote]
Windows gives a slight priority boost to the application with the active window, so that's probably why.

Any statistics can go above 100% due to rounding effects.

To give a simple example: Suppose you have 15 processes and they all inflict a perfectly identical workload on the CPU. 100/15=6.66666666666....% The CPU usage function reports an integer, so it rounds it up to 7%. Then when you make the tally, 15*7=105, so the reported CPU load is 105%.

Well, there's 2% left over... :lol:

No idea why it was still working fine and, although I don't remember what the values were, presumably some of the other processes were doing something that had a CPU load.

I know it sounds like a silly question but can the CPU usage as reported in the task manager go above 100%? I know CPU usage can't [i]actually[/i] be above 100% but perhaps there is something about how usage is reported?

[edit]
My computer got a little bit choppy this time as it flitted between giving attention to different instances but, once I had a particular game in focus, I was still able to play that copy of the game (Doom2 map01) with no obvious difficulties:

[spoiler][img]http://i.imgur.com/kkLNHA6.png[/img][/spoiler]

Amazing that it's still responsive with this high CPU load... If you add up the percentages you are at 100%.

So, you're cooking the Pi?

No idea why, but I'm just not getting this problem. I can run multiple instances of ZDoom or GZDoom, windowed or not and still have a perfectly responsive machine.

[img]http://i.imgur.com/NiYIXSL.png[/img]

It turns the Pi into a small oven, so there's that.

After toying with the [url=http://youtu.be/QZ-ocIbtpx0]rewind[/url] function a little bit, I think I may have a grasp on what the actual bug was. Something about how g_ticker is key control for pausing everything, despite itself being a critcal aspect doesn't make much sense, and it's screwing with player input a lot. It needs to stop running the playsim entirely, while still ticking.

Unless someone beats me to it, I may restructure it a little bit to make it more sane. (And maybe make timedemo a little less fatal.)

As for why my current fix is causing problems? I honestly never noticed them. It doesn't seem to cause any sort of unreasonable load on my system.
Funny that.

How about conditioning the new behavior to be only enabled when playing or recording a demo?