Game mode revisited

[jsmorley]

That's sorta why we added the "Additional process list" functionality.

[Yincognito]

That's sorta why we added the "Additional process list" functionality.

I know, but considering that it previously worked just fine without it, I figured it would continue to work without it (if that makes sense).
One other thing I forgot to mention: the game is unfocused when re-running it (I have to click once in the game window to focus it). It might be because my skins are always on top, or something else entirely.

[Yincognito]

I corrected the problem earlier, it turned out that it wasn't Rainmeter, nor the game itself (neither the old or the new version), but something in the game configuration files that (I assume) wasn't properly updated/upgraded and caused the aforementioned Game Mode "malfunction". As soon as I installed the game cleanly (i.e. uninstall the old version, delete the old version's "game profile", install the new version and create a new "game profile"), the issue disappeared and Rainmeter's Game Mode got back to its usual behavior.

Now I have to identify exactly where the problem was, since obviously I want to keep my "old" profile data/saves in the "new" game version...

[Yincognito]

Just curious, did anyone had any silent crashes of Rainmeter while using Game Mode? The feature works perfectly (even for the game I mentioned earlier) in 99.99% of the cases, it just happens that I had 2 silent crashes of Rainmeter (i.e. Rainmeter unloading from system tray) during the past few days. It might, of course, be due to the particularities of my suite or some other thing, but then, it works fine in the other N-2 cases. Unfortunately, the Rainmeter Log is helpful only while Rainmeter is running so I can't get anything from there, but the Windows Event Viewer shows something like this (I suppose these are those 2 silent crash instances, since they're the only error events related to Rainmeter in recent days, in Event Viewer):

Code: Select all

Faulting application name: Rainmeter.exe, version: 4.4.0.3445, time stamp: 0x6071ad94
Faulting module name: WININET.dll, version: 11.0.17134.112, time stamp: 0xae925e84
Exception code: 0xc0000005
Fault offset: 0x000000000006d4a0
Faulting process id: 0x1294
Faulting application start time: 0x01d73fda58ffcc5d
Faulting application path: C:\Program Files\Rainmeter\Rainmeter.exe
Faulting module path: C:\Windows\SYSTEM32\WININET.dll
Report Id: 7e0b8399-bdb2-4bb4-b2b7-991223d9910f
Faulting package full name: 
Faulting package-relative application ID: 

Code: Select all

Faulting application name: Rainmeter.exe, version: 4.4.0.3445, time stamp: 0x6071ad94
Faulting module name: WININET.dll, version: 11.0.17134.112, time stamp: 0xae925e84
Exception code: 0xc0000005
Fault offset: 0x000000000006d4a0
Faulting process id: 0x21fc
Faulting application start time: 0x01d73f3b9a87184f
Faulting application path: C:\Program Files\Rainmeter\Rainmeter.exe
Faulting module path: C:\Windows\SYSTEM32\WININET.dll
Report Id: fb44c61d-a3af-4899-820c-986fa15205d2
Faulting package full name: 
Faulting package-relative application ID: 

Judging from the faulting module name, it might have something to do with internet related things in Rainmeter, e.g. WebParser measures and such (which I do use in my Feeds and Weather skins, with 0 problems otherwise).

I don't know if you'll deem this important enough to take a look at it or if my report contains something useful, I'm just sharing my experience with the otherwise great feature (Game Mode, that is).

[alvarobf]

Hey guys, to avoid GPU and resources consumption, I'd like to see game mode for any fullscreen running app someday... Rainmeter is going great.. Thanks to the developers!

[Yincognito]

Hey guys, to avoid GPU and resources consumption, I'd like to see game mode for any fullscreen running app someday... Rainmeter is going great.. Thanks to the developers!

But isn't it for any fullscreen running app already, after the latest implementation?

[jsmorley]

But isn't it for any fullscreen running app already, after the latest implementation?

It detects any D3D full-screen exclusive mode application. This would not include for instance hitting F-11 in a browser, but would detect the vast majority of full screen games.

[Yincognito]

It detects any D3D full-screen exclusive mode application. This would not include for instance hitting F-11 in a browser, but would detect the vast majority of full screen games.

You're right - didn't think of the browser / F11 cases. But one can add such (rare, I reckon) processes to the additional processes list, right? I mean, one can add any process to that list, can't he?

[jsmorley]

You're right - didn't think of the browser / F11 cases. But one can add such (rare, I reckon) processes to the additional processes list, right? I mean, one can add any process to that list, can't he?

Well, you might not want to add chrome or firefox to the list, as then it would go into game mode any time you are in your browser.

This is not likely to change, as it is quite simple to detect actual full-screen games, and more tricky and difficult to detect full-screen desktop applications. Since it is our assumption that resources are not a big deal with YouTube and such, we are probably not going to take this any further.

[Yincognito]

Well, you might not want to add chrome or firefox to the list, as then it would go into game mode any time you are in your browser.

This is not likely to change, as it is quite simple to detect actual full-screen games, and more tricky and difficult to detect full-screen desktop applications. Since it is our assumption that resources are not a big deal with YouTube and such, we are probably not going to take this any further.

Yes, this makes sense, obviously. Even more so when you think that since the system is in desktop mode in these cases, other methods of unloading skins would be available (which isn't the case when in D3D/whatever mode). Also, for some always on top skins (like my suite, for example), unloading them in desktop full-screen would be undesirable.

That being said, I guess the common denominator of applications in desktop full-screen is that the application extent (i.e. its "window" span) covers the task bar, or makes it non-visible, so in theory it would be enough to check if this happens (or even whether the window span equals the current desktop resolution, though this latter approach might create "false positives" for maximized windows and auto-hidden taskbar). This would be made easier if there was an universal way to check for that span for the active/focused application, and also if the auto-hidden taskbar would permit using the "covered" taskbar check under the same conditions as if the taskbar was set to be always visible.