search

crosire / d3d8to9

A D3D8 pseudo-driver which converts API calls and bytecode shaders to equivalent D3D9 ones.
BSD 2-Clause "Simplified" License
880 stars 78 forks source link

Check for Palette support #38

Closed elishacloud closed 6 years ago

elishacloud commented 6 years ago

I updated the palette code a little bit. With this update the code will first check if palettes are supported. The PC_NOCOLLAPSE flag will only be set if palettes are not supported. Also this update will do some extra error checking on the SetPaletteEntries, GetPaletteEntries and GetCurrentTexturePalette.

Note: as far as I can tell there is no way GetCurrentTexturePalette will ever work if palettes are not supported. It always seems to crash. This code should prevent crashes from any game that properly uses any of these four palette APIs (whether palettes are supported or not).

PatrickvL commented 6 years ago

The palette check via raster caps doesn't work on all systems when checked under Direct3D 8. See https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/commit/02987ae7e95830b94bf2c8c4359267930947c36d

elishacloud commented 6 years ago

Interesting! But, one thing to note here is that we are running under Direct3D 9, not Direct3D 8. This may be an issue with Direct3D 8 but do we know if the same issue exists in Direct3D 9? I know the OS does handle palettes differently between Direct3D 8 and 9. For example in Direct3D 8 you can call some of the palette functions even when it is not supported without it crashing, whereas in Direct3D 9 if you try and run any function related to palettes it will crash if palettes are not supported. It is possible that the same update done in Cxbx would work on Direct3D 8 but cause a crash in Direct3D 9.

When I was testing this I did see that RASTERCAPS would return incorrect results if I put this check under the Direct3D8 class constructor. This is part of the reason I added this under the Direct3DDevice8 class constructor because by this point we have already created an IDirect3DDevice9 device so Windows will see us as a Direct3D 9 application. In my tests this made it so that RASTERCAPS result was correct.

If you have any more data about when the RASTERCAPS call could be incorrect under Direct3D 8 I would be interested to test it with this update and see if we have the same issue.

elishacloud commented 6 years ago

One more comment here is that Cxbx called RASTERCAPS before creating the Direct3DDevice. I found that to be troublesome also. However when calling this after creating the Direct3DDevice it seemed to be reliable based on my tests.

PatrickvL commented 6 years ago

Thanks for the feedback. I'm sorry I don't have more detail on this. I guess it would need testing on a wide range of cards and drivers. And thanks for the heads up about when to check rastercaps, we'll look into that too