Re: [PATCH 6/6] wined3d: Dirtify p8 textures when device palettes change.

[Stefan Dösinger]

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.

[PATCH 6/6] wined3d: Dirtify p8 textures when device palettes change.

[Alexander Dorofeyev]

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.

[PATCH 6/6] wined3d: Dirtify p8 textures when device palettes change.

[Roderick Colenbrander]

> 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.

I think we should continue splitting the ddraw and d3d8/9 palette interfaces. It took me a long time to get the ddraw in a reasonable shape (there are a few small issues left). There are differences and I think we get issues down the road if we don't explicitly split it like it is now. (at least you would get a lot of dxversion checks).

It is just that right now a few places which don't need the device palette code have it in (I mean there are places left which use the device palette when there is none set e.g. read_from_framebuffer, RealizePalette and others).

Roderick