You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As everybody knows, the gamma ramp only applies to whole screens.
For this reason, by default, the gamma ramp control from a windowed application is disabled. In DxWnd I added a hack to force it anyway, but the effect spawns to the whole screen including the visible portion of the desktop, with unpleasant effects.
I was wondering if the gamma ramp directive could be intercepted by a ddraw/d3d wrapper (so far, this is surely possible) and remapped to something else (a pixel shader?) that could emulate the same behavior, but limited to the window surface.
Maybe the WDDM callbacks could support a feature like this?
The text was updated successfully, but these errors were encountered:
Sure, DDrawCompat already has that. It was added in this commit: 31444c3
The shader was since then merged into a bigger one, but I would recommend starting with this older commit instead.
The function to hook is D3DKMTSetGammaRamp. Store the ramp in a 256x3 texture (R, G, B in their own rows) and look it up in the shader. Simple enough, if you're already familiar with shaders.
Thanks, it is exactly the solution that I hoped to find. I'm not expert of shaders, but I suppose it's worth learning. Maybe as the first steps I could try some experimental sw implementation (ok, it seems crazy, but maybe a tiny window can afford it).
I'll let you know how it goes ...
As everybody knows, the gamma ramp only applies to whole screens.
For this reason, by default, the gamma ramp control from a windowed application is disabled. In DxWnd I added a hack to force it anyway, but the effect spawns to the whole screen including the visible portion of the desktop, with unpleasant effects.
I was wondering if the gamma ramp directive could be intercepted by a ddraw/d3d wrapper (so far, this is surely possible) and remapped to something else (a pixel shader?) that could emulate the same behavior, but limited to the window surface.
Maybe the WDDM callbacks could support a feature like this?
The text was updated successfully, but these errors were encountered: