> 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