This is a long-needed cleanup aimed at removing the ddraw_primary,
ddraw_window, ddraw_width and ddraw_height members from
IWineD3DDeviceImpl, which just do not belong there. Destination
window and screen handling is supposed to be done by swapchains.
ATI cards prior to the radeon HD series did not have unconditional non
power of two support. So far we've used texture_rectangle for that, or
created a bigger power of two texture with padding. This had the
disadvantage that we had to correct the coordinates, which causes
extreme problems with shaders(doesn't work, pretty much).
Both the MacOS and the fglrx driver have support for
GL_ARB_texture_non_power_of_two, and run it on the hardware as long as
we stay within the texture_rectangle limitations. This allows us to
have conditional non power of two textures with normalized
coordinates. This patch adds an internal extension, and the code
creates a regular GL_TEXTURE_2D texture with NP2 size, but refuses
mipmapping, filtering and texture_rectangle incompatible
operations. This makes np2 textures work with shaders on fglrx and
macos.
IDirect3DDevice9::ProcessVertices takes a vertex declaration, not a
vertex buffer. The source for ProcessVertices is taken from the
stateblock, not the vertex declaration.
This is to allow StretchRect to pass the texture filter to WineD3D.
DirectDraw sets the texture filter to WINED3DTEXF_NONE, simmilar to all
other functions which do not need filtering.
Previously the surfaces stored a flag if the system memory copy was
ahead of the gl copy(SFLAG_DIRTY) or the gl copy is
ahead(SFLAG_GLDIRTY). The pbuffer copy was 'managed' differently using
SFLAG_INPBUFFER and SFLAG_INTEXTURE.
This patch replaces them with 3 flags, INSYSMEM, INPBUFFER and
INTEXTURE which specify which copy contains the most up to date
copy. It is perfectly valid to have more than one of those flags
set. One must be set at least (except at init, when no content is in
the surface yet). When one copy is modified, the flags for the others
are removed.
The method is removed because it does not really help with
anything. It should not be exported from wined3d, there is no need for
the other libs to call it. It does not help abstraction and code
simplification in any way because it is very specific and the code
calling it has to know what is happening in the surface to use this
method.
Stefan Dösinger