Minimize pauses the application, CPU still at 99%

Blitz3D Forums/Blitz3D Programming/Minimize pauses the application, CPU still at 99%

Sake906(Posted 2010) [#1]
The main problem is that I would like the application to keep processing stuff when minimized, and after searching around the boards on here I found that blitz3D will pause the application when the user minimizes to the taskbar no matter what. This I know well by now.

I'm still not understanding what's up with the CPU usage after it, why is that? I know the graphics flags 6 and 7 sort of solve this however, but if under normal windowed mode you still get 99% of CPU usage while "paused" then what gives?


Yasha(Posted 2010) [#2]
blitz3D will pause the application when the user minimizes to the taskbar no matter what


Uh... no it doesn't? Blitz3D only pauses when minimised if you use flags 6 or 7 - that's the entire difference between them and 2/3.


Sake906(Posted 2010) [#3]
I keep getting the program "pausing" under mode 2. The delay is mostly noticeable on the frametimers taking their time to "catch up" on the time that was lost, and without any frame limiting code I get no updates the game code after a time while minimized.

Could be missing something but so far like I said I read on many threads that it's impossible to keep the game running while minimized, you being the only exception with what you just tell me.


Yasha(Posted 2010) [#4]
OK, changed my mind.

Firstly, note that it's a parameter to Graphics, not to your program as a whole. I just tested this and am of the opinion that 6 and 7 pause graphical updates but not logical updates, i.e. RenderWorld or Flip do nothing but otherwise the program continues running as normal, because when defocused the image stayed frozen but immediately reverted to where it "should" be once it was refocused; minimising didn't seem to slow it down at all. By comparison of course in mode 2 things kept updating normally despite the loss of focus, and again showed no signs of slowing down when minimised. The FPS only seemed affected by the Windows transition animation and not the amount of time the window was minimised.

So... yeah. The application doesn't pause when minimised. If it does on your machine then this must be machine-specific, because it certainly doesn't on mine. Frankly I would take the continued processor use to mean it's not fully paused on your machine, and it's confusing the graphical updates only somehow.


Warner(Posted 2010) [#5]
Have you tried adding a "delay 1" right after Flip?
That should help the 99% cpu usage.
I believe there is a way to create a windowless b3d program.
Maybe you can find it, and work from there to a program tat runs when minimized?


_PJ_(Posted 2010) [#6]
I think there's a Shell32.dll function that enables a check for whether or not an app is minimised etc.


Zethrax(Posted 2010) [#7]
Adding a 'Delay 20' in a loop that runs while the game is paused should solve the problem. As far as I'm aware, 20 milliseconds is the standard threading timeslice (at least for Windows XP).


_PJ_(Posted 2010) [#8]
Thanks once again, Bill. I often wondered if there was an 'ideal' value to use, typically I've used a range from about 1 to 25 but it's good to know there's a 'standard'.


D4NM4N(Posted 2010) [#9]
that is interesting to know, thx


jfk EO-11110(Posted 2010) [#10]
BTW there is one thing that I remember: When you minimize a Fullscreen app, then it will be minimized and indeed paused, I mean really paused, until it gets focus again.


Adam Novagen(Posted 2010) [#11]
Adding a 'Delay 20' in a loop that runs while the game is paused should solve the problem.


Sorry, but I just can't hold it...

BAD BAD BAD BAD BAD BAD BAD BAD BAD IDEA. XD

Actually it's not ALL bad. But 20 milliseconds is a terrible period choice. If a game's running at 60FPS, each frame will be 1000/60 milliseconds, which amounts to 16 and two-thirds. Rounded down, this means that essentially, a single frame shouldn't last longer than 16 milliseconds. Using Delay 20 is going to slow it down below the 60FPS mark; 20 milliseconds is just too long.

The best way that I've yet found is to use some variable "CPU breathing code." That'd go something like this:

Global FrameTime = 1000 / 60
Global LoopStart


;Here's the main loop for the game...
While Not KeyHit(1)


LoopStart = MilliSecs()


;All your code for doing neat stuffz


;Take a breather
Delay FrameLength - (MilliSecs() - LoopStart)


Wend



That code you just saw will use the Delay() function for any remaining time in your main loop, but only up to the 16 millisecond mark.


_PJ_(Posted 2010) [#12]
I'm not too sure what difference framerate makes if the game is minimised and, as originally mentioned, effectively 'paused'?


Adam Novagen(Posted 2010) [#13]
I'm not too sure what difference framerate makes if the game is minimised and, as originally mentioned, effectively 'paused'?

Well, if the game is "hard paused," that is, paused by the actual minimizing of the window, then none of the code will execute, whether you have a Delay() call in there or not. So yeah, neither my code nor anything else will be any good if the window's minimized.

Last edited 2010


jfk EO-11110(Posted 2010) [#14]
Then again, using Delay for the remaing time seems to be good practice. Although, waiting for a Vsync would do the same, I guess. But there are some Displays without Vsync.