[PATCH 5/7] wined3d: introduce a new wined3d_texture_blt function
Riccardo Bortolato
rikyz619 at gmail.com
Tue Oct 13 04:52:38 CDT 2015
For reference, here's what I intend to do to accomodate ddraw (I have
a number of patches in github):
diff --git a/dlls/wined3d/texture.c b/dlls/wined3d/texture.c
index 7b6f651..319a0a0 100644
--- a/dlls/wined3d/texture.c
+++ b/dlls/wined3d/texture.c
@@ -1436,13 +1436,16 @@ HRESULT CDECL wined3d_texture_blt(struct
wined3d_texture *dst_texture, unsigned
const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter)
{
struct wined3d_resource *dst_resource =
wined3d_texture_get_sub_resource(dst_texture, dst_idx);
- struct wined3d_resource *src_resource =
wined3d_texture_get_sub_resource(src_texture, src_idx);
+ struct wined3d_resource *src_resource = NULL;
- if (!dst_resource || !src_resource)
+ if (!dst_resource)
return WINED3DERR_INVALIDCALL;
+ if (src_texture)
+ src_resource = wined3d_texture_get_sub_resource(src_texture, src_idx);
+
return wined3d_surface_blt(surface_from_resource(dst_resource),
dst_rect_in,
- surface_from_resource(src_resource), src_rect_in, flags, fx, filter);
+ src_resource ? surface_from_resource(src_resource) : NULL,
src_rect_in, flags, fx, filter);
}
Ciao,
Riccardo
2015-10-13 11:37 GMT+02:00 Stefan Dösinger <stefandoesinger at gmail.com>:
>
>> Am 12.10.2015 um 17:23 schrieb Riccardo Bortolato <rikyz619 at gmail.com>:
>>
>> +HRESULT CDECL wined3d_texture_blt(struct wined3d_texture *dst_texture, unsigned int dst_idx, const RECT *dst_rect_in,
>> + struct wined3d_texture *src_texture, unsigned int src_idx, const RECT *src_rect_in, DWORD flags,
>> + const WINEDDBLTFX *fx, enum wined3d_texture_filter_type filter)
> I am not convinced that this is how we want blits to work. I was looking into some blit cleanups myself a few months ago, but got stuck in swapchain related sidequests, mostly to get rid of wined3d_swapchain_blit.
>
> My thinking re blitting is that we want to separate things into d3d9-style StretchRect (does color conversion, multisample resolve, stretching, color keying, ...) and CopySubresourceRegion (does sysmem<->vidmem transfers). Mapping d3d8+ methods on top of these calls is pretty simple. ddraw is trickier though and I cannot promise yet that it will work. Many things can be solved with staging resources, e.g. to split a color keyed sysmem -> vidmem blit into a copy_sub_resource_region upload and StretchRect color key blit.
>
> (StretchRect will need to be a bit more powerful than what d3d9 / d3d10 allow. At least we want sysmem<->sysmem blits supported by it).
>
> Henri was arguing for a more powerful blitter in wined3d if I understood him right, that would also be capable of handling the upload of converted surfaces (wined3d_format_texture_info.convert in utils.c). My concern is that this kind of blitter will turn into a god object that's more powerful than what we need (e.g. we don't need signed RGB -> unsigned RGB conversion while transfering from a sysmem vertex buffer to a vidmem volume texture), but I didn't get very far in proving that my alternative approach works.
>
More information about the wine-devel
mailing list