Widescreen Gaming Forum

Ian (the author of cclutch) can probably explain more in detail if he decides to sign up.

Indeed, I really would be quite interested in the technical details of implementing it. Right now most games are made exactly the same way, a window is created with WinAPI with a 'flag' to set it to fullscreen. So really by default it isn't the games fault. It's either Windows or the video drivers that disable it in Fullscreen apps.

If there is a way for the application to override it and explicitly ask to use the active color profile It would be really nice for documentation, and without it your idea really cannot go anywhere sadly.

To OP: I can see why people would be frustrated with this issue, as most people, who even have "Matching Monitors" Have different revs or may even have refurbs with different panels.

Though, I honestly don't notice the color difference too much. Also I thought you could force the color profiles through drivers.

_________________
System Core: | Intel Core i5-2500K + ASUS P8Z68-V + 16GB Corsair XMS3 DDR3 1333 MHz | Win7 x64 | MSI R7970 Lightning 3GB [1105/1400] |
Display: | 3 x Dell Ultrasharp 3007WFP-HC @ 7680x1600 | Dell u3011 |

In fact, I can only think of one WSGF member off the top of my head that I seem to remember having colour calibration hardware - X-Warrior.

I also have color calibration hardware and a color calibrated system (well, several). Nevertheless, my main gaming system only has TN panels, sadly.

It would be nice if developers implemented it, but it doesn't terribly bother me (wheras with photos it's essential).

[quote]Ian (the author of cclutch) can probably explain more in detail if he decides to sign up.

Indeed, I really would be quite interested in the technical details of implementing it. Right now most games are made exactly the same way, a window is created with WinAPI with a 'flag' to set it to fullscreen. So really by default it isn't the games fault. It's either Windows or the video drivers that disable it in Fullscreen apps.

If there is a way for the application to override it and explicitly ask to use the active color profile It would be really nice for documentation, and without it you're idea really cannot go anywhere sadly.
Alright, sorry it has taken me so long to get signed up here, I've been very busy these last few weeks with personal and school obligations.

Anyway, the problem is, at least on the DirectX front, not a problem of what a game doesn't do, but rather a problem of what a game does do. Full-screen Direct3D applications do not inherently screw up color calibration. The problem occurs when a specific function is called--in Direct3D9 and earlier, this is SetGammeRamp(), and in later versions it was moved to the DXGI and renamed SetGammaControl() (simply referred to as SGR()/SGC() from here on). These are the functions that cause loss of color calibration. While I can't say with 100% accuracy whether the problem itself lies in Microsoft's design of the API or the implementation by the various graphics card vendors (nVIDIA/ATi/Intel), with the problem occurring on several vendors cards I would assume it is behaving exactly how Microsoft designed it.

It's even more ambiguous when you look at the documentation. There is actually a flag that can be passed to the function, D3DSGR_CALIBRATE, which "If a gamma calibrator is installed, the ramp will be modified before being sent to the device to account for the system and monitor response curves." However, upon testing, I found that this either doesn't work as expected (at least on my 5850), or works exactly as expected but the "gamma calibrator" doesn't include installed monitor profiles and therefore is seemingly useless anyway. If it doesn't include the "curves" of monitor profiles, what does it refer to then?

The reasons for even calling such a function to begin with are dubious. Originally, it seems this was used by developers to "fade out" or "fade in" a scene, or provide some basic color filtering, which was not very easy to do efficiently back in the day. This doesn't seem to be in practice in any game made in the last ~5 years that I've played, judging from my experience playing them both with and without Color Clutch in use (explained later).

More recently, games seem to use it in a different fashion--to provide users who have no such monitor calibration some in-game adjustment. Ultimately, developers want the game to look the same way to the end user that it looked to them, and setting gamma ramps is a quick, though incomplete and incorrect fix for this. A better way would allow users to set brightness, contrast, and gamma using a shader, which is what I believe some of the newer games are doing. For instance, I recently purchased BF:BC2, and it has brightness and contrast (no gamma) adjustments which thankfully never call SGC().

The easy fix for those who want full screen gaming while holding on to their monitor calibration is to simply not call the function. Unfortunately, most games call SGR()/SGC() no matter what, even if there have been no adjustments to the gamma in the settings. That was why I wrote Color Clutch. The theory behind it is simple--prevent the games from calling these functions, and your color calibration will survive. There aren't a whole lot of good ways to do this, so I took what I thought was the best way; injecting a DLL into the process, and then, whenever it tries to call SGR()/SGC(), instead it calls my "bogus" function with the same parameters. The only difference between the real function and mine is that my function doesn't actually do anything.

As for current plans regarding Color Clutch, I'm working on support for some older versions of DirextX (specifically 6, which I think is the first version to include a SGR() function, and 7). This is made difficult by the complete lack of documentation pertaining to these old APIs, but I should eventually be able to get something out that works. OpenGL, though, has no apparent analog to SGR()/SGC(), so I don't believe I can do anything there, and I'm not entirely sure how, why, or even if some users are losing calibration on OGL games.

Sorry about the long post, but I thought it was better to be thorough than lacking. :)

Awesome stuff, thanks Ian.

Thanks for the great explanation.

From the looks of it, it looks like the single point of failure lies in with whomever the developers are. Which I suppose can be taken as good news, and it looks like the problem isn't a terribly difficult thing to "fix". If what Ian speculates turns out to be true, and that the only reason games lose their colour is because of an archaic means to fade out/in games, perhaps the developers could be lobbied to implement this properly. It is quite obvious that lobbying Microsoft for them to fix this error in their DirectX suites, so perhaps it's best going directly to the developers.

Is this related to Windows 7? Doesn't XP force fullscreen apps to use custom settings?

I'm pretty sure its DirectX related, and happens on all versions of Windows, XP, Vista, W7, etc.

I'm pretty sure its DirectX related, and happens on all versions of Windows, XP, Vista, W7, etc.

Yep, it definitely seems that it doesn't matter what version of Windows your running. According to Ian normally it works fine in fullscreen apps. Likely on all modern versions of Windows.

I have also contacted Mike, author of Monitor Calibration Wizard. http://www.hex2bit.com/products/index.asp

MCW works for a number of games, but it is still a "soft" option, and the game is still able to "hard lock" back to the default uncalibrated colours once the game goes fullscreen. However, it does work for some games, I am guessing it works for games that are not explicit about defaulting the colour values.