[PATCH 6/6] wined3d: Dirtify p8 textures when device palettes change.
thunderbird2k at gmx.net
Sun Mar 9 17:44:43 CDT 2008
> Hi Stefan,
> About implementing ddraw-style palette on top of device palettes - I think
> 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
> palette interfaces, although there is some confusion primarily because
> 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
> 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
> palette creation/destruction a LOT (every frame or every few frames), so
> not an unrealistic possibility to run out of palettes, if 65536 limit is
> and something is done wrong.
> You may be right about checking palette in IWineD3D*Texture::PreLoad. I
> 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
> > would be nicer to store the palette the texture/surface was loaded with
> > each P8 / A8P8 surface and compare this stored palette to the current
> > 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
> > WineD3D altogether, and just give each ddraw palette in ddraw.dll a
> > palette number and use the d3d8/9 palette management exclusively in
> > 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).
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
More information about the wine-devel