Гайд D3D9 Hook: Решение проблем с гаммой и разрешением при Alt-Tab

[hex_cat]

Народ, кто ковыряет D3D9 хуки в играх на движке Source, сталкивались с тем, что после Alt-Tab в полноэкранном режиме игра ловит рассинхрон гаммы или ресайз? У меня эта беда отжирала нервы несколько дней.

Симптомы были классические: макрос mat_monitorgamma переставал работать, а при сворачивании игры был виден фрейм, где окно пытается нелепо растянуться в 1080p. При этом через OBS этот баг не ловится, что усложняло дебаг.

Проблема крылась в кривой инициализации хука. Вот пример того, как делать НЕ надо, если не хотите ловить такие приколы:

void hooks::d3d9::init() {
    com_ptr<IDirect3D9> d3d9 = Direct3DCreate9(D3D_SDK_VERSION);
    auto window = FindWindowA("Source001", nullptr);
    D3DPRESENT_PARAMETERS params{
        .BackBufferFormat = D3DFMT_UNKNOWN,
        .SwapEffect = D3DSWAPEFFECT_DISCARD,
        .Windowed = TRUE,
        .EnableAutoDepthStencil = TRUE,
        .AutoDepthStencilFormat = D3DFMT_D16,
        .PresentationInterval = D3DPRESENT_INTERVAL_DEFAULT,
    };
    // ... дальше инлайн хук через safetyhook
}

Спойлер: Технический разбор

Причина, скорее всего, в конфликте параметров инициализации при смене состояний Direct3D устройства. В "полном экране" движок ожидает жестко заданных параметров, а наш хук при переинициализации перехватывает управление в неудачный момент. Когда ничего не помогает — лучше снести все под ноль и переписать хук с нуля с учетом жизненного цикла девайса, что я и сделал за 15 минут. Проблема ушла.

Если кто-то глубоко копал в эту тему и понимает, почему именно стандартный подход к Present хуку так агрессивно роняет стейт драйвера в полноэкранном режиме — отпишитесь в тред. Интересно послушать мнение профи по внутренностям Direct3D.

Кто сталкивался с похожим крашем или багом в оверлеях — как решали?