tir, 07,.06.2005 kl. 23.00 -0700, skrev David Albrecht:
VOID CreateLcdBitmap(VOID) { // create LCD bitmap _ASSERT(nLcdDoubled == 1 || nLcdDoubled == 2 || nLcdDoubled == 4); bmiLcd.Lcd_bmih.biWidth = LCD1_ROW * nLcdDoubled; bmiLcd.Lcd_bmih.biHeight = -64 * nLcdDoubled; hLcdDC = CreateCompatibleDC(hWindowDC); _ASSERT(hLcdDC != NULL); hLcdBitmap = CreateDIBSection(hLcdDC, (BITMAPINFO*)&bmiLcd,DIB_RGB_COLORS, (LPVOID*)&pbyLcd, NULL, 0); _ASSERT(hLcdBitmap != NULL); hOldLcdBitmap = SelectObject(hLcdDC, hLcdBitmap); _ASSERT(hPalette != NULL); SelectPalette(hLcdDC, hPalette, FALSE); // set palette for LCD DC RealizePalette(hLcdDC); // realize palette UpdateContrast(Chipset.contrast); }
When creating a memory DC for an 8-bit DIB section, it is normal to create a palette matching the DIB color table, then just selecting it into that DC. In such usage, RealizePalette is not used. Perhaps there's an explanation to be found in that direction.
MSDN says, for example:
"The RealizePalette function modifies the palette for the device associated with the specified device context. If the device context is a memory DC, the color table for the bitmap selected into the DC is modified. If the device context is a display DC, the physical palette for that device is modified."
This suggests that RealizePalette should set the DIB color table from the palette, something Wine might not do properly. Although this is the opposite of your hack, it does make the palette and the DIB color table identical again, so perhaps it would still work for you.