Closed nuzayets closed 6 years ago
Thanks, this is awesome! I've had situations in the past where time in a game doesn't get measured, even though I use mouse and keyboard (no controller), and I never figured out why that is.. but I guess this will fix it regardless.
Your check for dimensions, I wonder how robust that is, since games can be full-screen, borderless window, and windowed.. does it work equally for all of them? I guess windowed you DON'T want it to work on them, since it can be a regular application.
In terms of the code, can you fix the formatting? You use tabs, the surrounding code uses 4 spaces. variables should be snakecase
or snake_case
not camelCase
. Maybe add a comment above the if
that states something similar to the commit message above.
Hmm.. I guess GetWindowRect
will fail to match dimensions for any window as long as there is a start bar or whatever on the screen.. what about people that have their start bar set to dissapear? Won't any maximized window match?
There is also GetClientRect
.. which is the inside of the window minus the title bar etc. Would that match full screen and borderless windows more accurately?
OK I have made the changes.
I could not find a better way of checking whether another application is fullscreen. I can't think of a solution to the windowed game /w controller problem. Presumably Windows knows the user isn't idle because a screen saver does not start, the screen doesn't lock, etc but I am not sure a) if that is requested by the application or some internal Windows idle detection functionality and b) in either case, how to access the same information without elevation or dirty tricks. So fullscreen on the primary monitor is a good heuristic but it is not perfect.
Perhaps it might be a good idea to add a configuration option, "Allow fullscreen applications to trigger idle" and "Exclude processes from idle: " so people can manually configure this.
Otherwise - GetWindowRect will not match for maximized with the taskbar hidden. Windows are offset to hide the chrome (resize grip etc) when maximized. e.g. on my display, Windows 10 positions maximized windows at -8, -8 instead of 0, 0.
I'm guessing Windows's own idle detection may also include controllers and anything else it considers user input. PT however only considers mouse and keyboard, so one way would be to explicitly make it check for controllors, non-exclusively.
I bet things like movie players specifically ask Windows to not engage the screen saver. I doubt it is Windows "detecting" this use case somehow. https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-setthreadexecutionstate Not sure if there is a way to get that state, otherwise we could use it to avoid PT going idle. Don't think games use it, though.
Like I said, there is a problem with some games going idle even with mouse and keyboard. Maybe those games "steal" events in a low level way such that they don't even arrive at PT's input hook.
I'll merge this for now. If you have ideas on how to further improve it that'd be great!
For example: video games played with a controller, movies / presentations / videos played fullscreen, etc
Checks if foreground window is the same size as primary monitor