Hi Stefan,
About implementing ddraw-style palette on top of device palettes - I think this way we would create more issues than we solve by it. As far as I'm concerned, I don't feel like there's a lot of confusion coming from the fact there are two palette interfaces, although there is some confusion primarily because device palettes are used for ddraw purposes, mainly storing p8 primary surface's palette. That isn't a big trouble to avoid, as same can be done by accessing dds_primary, I believe.
If ddraw palettes are mapped onto d3d8 style ones, then we need a mechanism of allocating palette numbers and freeing them as needed. For example, AVP1 does palette creation/destruction a LOT (every frame or every few frames), so it's not an unrealistic possibility to run out of palettes, if 65536 limit is kept and something is done wrong.
You may be right about checking palette in IWineD3D*Texture::PreLoad. I guess the palette9_changed call could simply be moved to PreLoad and it would accomplish something like that.
Stefan Dösinger wrote:
Am Sonntag, 9. März 2008 15:10:54 schrieb Alexander Dorofeyev:
Fixes problems with properly updating wine's P8 textures, when it is required because of device palette change.
Instead of iterating over all resources and finding P8 textures I think it would be nicer to store the palette the texture/surface was loaded with in each P8 / A8P8 surface and compare this stored palette to the current device palette in IWineD3DSurface::PreLoad(non-texture path) and IWineD3D*Texture::PreLoad.
With this, patch 4 could maybe be made nicer as well. If we have to verify the palettes anyway, we can remove the DDraw-Style IWineD3DPalette interface from WineD3D altogether, and just give each ddraw palette in ddraw.dll a WineD3D palette number and use the d3d8/9 palette management exclusively in WineD3D and avoid the confusion of having two palette interfaces.