search

crosire / d3d8to9

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

Remove CreateImageSurface R8G8B8 swap with X8R8G8B #177

Closed WinterSnowfall closed 2 months ago

WinterSnowfall commented 2 months ago

I'm guessing this format swap is a remnant from the initial code, if git blame is to be believed. It should no longer be needed now, as image surfaces with R8G8B8 will be created just fine in D3DPOOL_SCRATCH, with the current fallback logic.

The swap usually works fine anyway, but has the drawback of causing minor issues at times, such as corrupting savegame screenshots in Chrome. Keeping R8G8B8 as is solves this problem.

elishacloud commented 2 months ago

Definitely, if the game requests R8G8B8 (a 24bit surface) and instead we create it as X8R8G8B (a 32bit surface) then that will cause problems for the game if they lock it (or try and get the device context for it) because they will either be putting the wrong content into the surface or reading the wrong content from the surface. The Lock and GetDC functions would need to be emulated for that to work.

In the mean time, I agree with not replacing the surface format. If creating the surface as a D3DPOOL_SCRATCH works that is even better. Otherwise, if there is a game with an issue then we should add emulation for these functions rather than just replacing the surface format.

WinterSnowfall commented 2 months ago

If creating the surface as a D3DPOOL_SCRATCH works that is even better.

In the case of Chrome at least, it does. The game uses a R8G8B8 surface to create a vegetation lightmap (and to fetch the backbuffer for screenshots it seems).

I think it was either "Hidden & Dangerous Deluxe" or "The Fellowship of the Ring" which was also creating some R8G8B8 surfaces. Otherwise it's not really commonly used in d3d8.