[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
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free