„Ekskluzywna” paleta DirectDraw nie jest w rzeczywistości wyłączna

Utrzymujemy starą grę wideo, która korzysta z pełnoekranowego 256-kolorowego trybu graficznego z DirectDraw. Problem polega na tym, że niektóre aplikacje działające w tle czasami próbują zmienić paletę systemu podczas działania gry, co powoduje uszkodzenie grafiki.

Możemy (czasami) wykryć, kiedy to nastąpi, przetwarzając wiadomość WM_PALETTECHANGED. Kilka wersji aktualizacji temu dodaliśmy rejestrowanie (wystarczy zalogować nazwę okna / klasy / nazwy procesu), co pomogło użytkownikom zidentyfikować szkodliwe aplikacje i je zamknąć. MSN Live Messenger był częstym sprawcą.

Problem nasilił się, gdy dowiedzieliśmy się, że Windows Vista (i 7) robi to „samodzielnie”. Parametry WM_PALETTECHANGED wskazują na CSRSS i okno pulpitu. W systemie Vista obejście, które często działało, polegało na otwarciu dowolnego folderu (komputera, dokumentów itp.) I pozostawieniu go otwartym podczas uruchamiania gry. Brzmi śmiesznie, ale zadziałało - w większości przypadków. W systemie Windows 7 nawet to obejście nie działało. Użytkownicy stwierdzili, że zatrzymanie niektórych usług (Windows Update i usługa indeksowania) również rozwiązało problem w niektórych konfiguracjach.

Jakiś czas temu zacząłem próbować przypadkowych rzeczy w nadziei znalezienia rozwiązania. Odkryłem, że ustawienie palety GDI (przy użyciu Create / SelectPalette) przed ustawieniem palety DirectDraw (przy użyciu IDirectDrawPalette :: SetEntries) przywróci paletę po jej uszkodzeniu (obsługa WM_PALETTECHANGED). SetSystemPaletteUżyj i wywołaj SetPalette na powierzchni głównej pomogło trochę więcej. Jednak nadal istnieje zauważalne migotanie, gdy aplikacja próbuje ukraść paletę, co jest szczególnie widoczne podczas zanikania.

Pytanie: czy istnieje sposób na uzyskanie „prawdziwej” ekskluzywnej palety, która całkowicie uniemożliwia innym aplikacjom zmianę palety Windows, dopóki nasza gra zachowuje ostrość?

questionAnswers(5)

yourAnswerToTheQuestion