Updating a texture while it is attached to the currently bound FBO is
something GL implementations tend to get wrong. NVIDIA fails at
glTexSubImage2D(), fglrx and Mesa with glTexImage2D(). I'm afraid to try what
happens on OS X. Fortunately we never use glTexImage2D() while a texture is
attached to an FBO, so we only need to care about glTexSubImage2D().
Just make sure the texture is allocated, so we have something to attach. Note
also that context_apply_attachment_filter_states() runs under the GL lock, so
preloading resources is actually unsafe there.
Similar to surface_prepare_system_memory(). In the long term we'll probably
want to move the whole location management to resource.c and unify buffers and
textures there.
Casting the container to "IWineD3DSwapChainImpl *" is always safe when
SFLAG_SWAPCHAIN is set on the surface. Most callers don't have a real
need for the swapchain, and end up calling GetContainer() just to pass
it to surface_get_gl_buffer().
The idea here is that we can restore the thread's current GL context on
context_release() if it doesn't correspond to the current wined3d context on
context_acquire().
The old condition happened to work, because SFLAG_INTEXTURE was not
set(we're loading it), and neither was SFLAG_INDRAWABLE(otherwise
INTEXTURE would be set too). If the fbo INDRAWABLE == INTEXTURE is
replaced by INDRAWABLE == INSRGBTEX this doesn't hold true any longer
because SFLAG_INDRAWABLE is set, but not used because the drawable
readback is never used for fbos.
FBO stretchrect marks SFLAG_INDRAWABLE up to date, which currently
also marks SFLAG_INTEXTURE up to date. However, this will change when
we enable rendering to the srgb copy, in which case the drawable could
be equal to the srgb copy, not the rgb copy.
This prevents for example a d3d9 depth stencil from being destroyed when it
has no external references but is still in use by the device/stateblock. A
nice side effect is that it simplifies handling of "implicit" surfaces like
the frontbuffer and backbuffers, as well as the forwarding of reference counts
for surfaces that are part of a texture.
The MSDN is not totally correct: A8R8G8B8 and A1R5G5B5 also allow GetDC. The
main differences that have to be filtered out in d3d9.dll are GetDC on
A8B8G8R8, X8B8G8R8 and P8.
Passing NULL to glCompressedTexImage2DARB() doesn't work particularly well
when both client storage and PBOs are enabled. Also, two years is long enough
to give driver developers a chance to fix the bug this was supposed to work
around.
On ATI cards we use the driver's GL_ARB_texture_non_power_of_two emulation to
support conditional NP2 textures without having to deal with the denormalized
coordinates. The default GL_TEXTURE_2D address mode is incompatible with
GL_ARB_texture_rectangle however.
In general it might not be a bad idea to group GL specific data into a
separate struct, but IWineD3DSurfaceImpl is currently the only thing that
bothers. It doesn't get it quite right either, since e.g. the PBO isn't in
glDescriptor either.
Although these formats aren't lockable, we still explicitly set the initial
surface data when creating the texture. Unfortunately that means we'll need
the conversion functions, even though all they'll ever convert will be zeroes.
For most conversions the internal format is irrelevant. Color key conversions
are an exception, because they need to ensure an alpha channel is present.
Nvidia doesn't offer it on geforce 7 and earlier cards, but some games need
it. This is surprising because the extension was made specifically for
compatibility purposes for older cards.
These surfaces won't be attached to an FBO anyway, so avoid the cost of a
potential format conversion when blitting from a non-RT surface. This is
mostly an issue for ddraw applications with 16 bit render targets.
Add a new wined3d-internal PreLoad function to textures and surfaces
that takes a parameter specifying wether the rgb or srgb texture
should be loaded.
This reduces the number of srgb switching reloads quite a lot. The only
situation in which a reload is needed is if the rgb copy is modified on the GL
side and the srgb copy is needed.
We cannot remove this because we still have to load the surface as
RGB. The shader may take care of setting the blue channel to 1.0 now,
but we still get the red and green channels loaded incorrectly if we
don't insert a blue channel before loading.
This allows us to drop the load time conversion and the clear
readback hack and replaces it with a color fixup in the fixed
function pipeline replacement.
Based on a patch by Stefan Dösinger. This is more flexible, and allows
the shader backend implementation to be simpler, since it doesn't have
to know about specific formats. The next patch makes use of this.
Note that minMipLookup and magLookup aren't particularly safe to use,
they're global arrays initialized from IWineD3DImpl_FillGLCaps(). The same
goes for the other global dynamic lookup tables.
GL_ATI_envmap_bumpmap provides two things: Signed V8U8 pixel formats,
and bump mapping. The extension is only supported on fglrx, and this
driver also supports GL_ARB_fragment_program. Thus the bump mapping
code is never used on any driver out there. Furthermore, if it is
used, it tends to crash the driver
The signed pixel format is used, as it can be used by pixel shaders or
the ARBfp replacement. However, the format is broken in fglrx, and
negative values are clamped to 0.0. This results in test
failures. WineD3D has an alternative codepath using scale+bias to
enable V8U8 using a standard signed RGB which works correctly on
fglrx.
This creates a function for setting the texture name and one for
setting the texture target. The idea is that the texture target should
get set right after the surface is created, and won't change, while
generating a texture name can wait.
Note that using GL_DEPTH_COMPONENT instead of eg. GL_DEPTH_COMPONENT24
will work, but will create a renderbuffer with the format of the
onscreen depth buffer.
This prevents shader path from being entered for an offscreen surface
when there is p8 render target and fixes failures in ddraw visual test
(with opengl rendering and RTL_READDRAW mode) and visual glitches in
Red Alert.
This is the prefered format of many codecs, and for some codecs this
is the only supported output format. As usual I try to handle all the
conversion in the GPU and keep the CPU involvement minimal to gain the
full performance of PBO transfers.
Although sharing FBOs across contexts is allowed by EXT_framebuffer_object
(issue 76), it causes issues with nVidia drivers. Considering the GL 3 spec
explicitly disallows sharing of FBOs accross contexts (Appendix D), this
patch is probably the right thing to do.
If a format is not supported natively by opengl, a shader may be able
to convert it. Up to now, CheckDeviceFormat had magic knowldge which
GL extensions lead to which supported format. This patch adds
functions that allow CheckDeviceFormat to ask the actual
implementation for its capabilities.
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.
This is an ATI specific format designed for compressed normal maps,
and quite a few games check for its existence. While it is an
ATI-specific "extension" in d3d9, it is a core part of
D3D10(DXGI_FORMAT_BC5), and supported on Geforce 8 cards.
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.
This gets rid of depth_copy_state in the device, and instead tracks
the most up to date location per-surface. This makes things a lot
easier to follow, and allows us to make a copy when switching depth
stencils in SetDepthStencilSurface().
Just unsetting SFLAG_INTEXTURE doesn't work for FBOs because the
drawable and texture are the same there (and ModifyLocation() is the
correct way to do this anyway). Fixes another ddraw test failure with
FBO ORM.