On 13 October 2013 11:13, Marcus Meissner wrote:
> 1104553 Resource leak
>
Fixing the memory leak is fine of course, but I think it would be
better to handle the array initialization in
d3drm_visual_array_create() etc. instead, so that those functions
actually return an object that's properly init
On 11 October 2013 22:51, Frédéric Delanoy wrote:
> -DWORD onesided_enable = FALSE;
> -DWORD twosided_enable = FALSE;
> +DWORD onesided_enable = 0;
> +DWORD twosided_enable = 0;
Actually, all of those initializations are redundant.
On 10 October 2013 16:59, Frédéric Delanoy wrote:
> Basically cleanup/clarity. Using boolean values when expressing
> logical expressions results does make sense (and it makes the intent
> clearer) IMHO.
I just think it would have been nice if we could have used the C99
bool type, but clearly C99
On 9 October 2013 11:26, Dmitry Timoshkov wrote:
> Henri Verbeet wrote:
>
>> +static HRESULT WINAPI
>> IDirect3DRMVisualArrayImpl_QueryInterface(IDirect3DRMVisualArray *iface,
>> REFIID riid, void **out)
>> {
>> -TRACE("(%p)->(%s, %
On 8 October 2013 13:44, Stefan Dösinger wrote:
> Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode
> is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If
> the application later calls PreLoad manually, texture2d_preload is
> called with SRGB_ANY. Because of the
On 8 October 2013 00:27, Stefan Dösinger wrote:
> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
> index 52eac16..eb8ca7e 100644
> --- a/dlls/wined3d/surface.c
> +++ b/dlls/wined3d/surface.c
> @@ -5608,8 +5608,6 @@ HRESULT surface_load_location(struct wined3d_surface
> *surface, DWO
On 7 October 2013 12:06, xantares 09 wrote:
> ... I don't see a reason why to not include it at the wine level instead of
> every linux distros, see:
> https://github.com/xantares/wine/commit/76ebd5d29effaf4b6b39ceecb689f7008bf6b376
>
> What do you think ?
>
Ignoring the discussion if we want this
On 6 October 2013 20:32, Frédéric Delanoy wrote:
> On Sun, Oct 6, 2013 at 12:45 AM, morphiend wrote:
>> This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s.
>> This was tested on Ubuntu 12.10 using IDA 6.4 as a test application. Without
>> the implementation of _chsize_s(), ce
On 4 October 2013 15:51, Stefan Dösinger wrote:
> No codepath in wined3d_surface_blt will attempt to load a sysmem surface into
> a texture. fbo_blit_supported returns FALSE if src or destination are in
> sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills
> will go to a
On 4 October 2013 15:02, Stefan Dösinger wrote:
> Client storage only applies to GL textures, which won't be created for sysmem
> surfaces.
>
I don't think that's necessarily true at the moment. In particular,
ddraw blits can in principle cause a texture to be created for sysmem
surfaces. There m
On 4 October 2013 00:03, Stefan Dösinger wrote:
> @@ -2883,10 +2886,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
> wined3d_surface *surface, void *mem
> /* Now the surface memory is most up do date. Invalidate drawable
> and texture. */
> surface_validate_location(surface,
On 3 October 2013 21:16, Lasse Rasinen wrote:
> According to debugging output, Artemis Spaceship Bridge Simulator 2.0
> calls LockRect twice on the same texture (for whatever reason) and crashes.
>
> http://bugs.winehq.org/show_bug.cgi?id=34271
>
> This change prevents the locked_rect being overwr
On 3 October 2013 15:03, Stefan Dösinger wrote:
> Am 2013-10-03 13:45, schrieb Henri Verbeet:
>> It sounds like you have some ordering issues in that patch set.
> Correct. Patches before patch 24 shouldn't be affected by that though.
> I didn't get around to splitting and
On 3 October 2013 13:22, Stefan Dösinger wrote:
> Am 2013-10-03 13:14, schrieb Henri Verbeet:
>> On 3 October 2013 13:08, Stefan Dösinger
>> wrote:
>>> --- dlls/wined3d/volume.c | 46
>>> +-
>>> dlls/win
On 3 October 2013 13:08, Stefan Dösinger wrote:
> ---
> dlls/wined3d/volume.c | 46
> +-
> dlls/wined3d/wined3d_private.h | 6 --
> 2 files changed, 27 insertions(+), 25 deletions(-)
>
What about surfaces and buffers?
Please split this.
On 28 September 2013 09:35, Marcus Meissner wrote:
> rest looks ok, but you really only should submit:
>
I don't think it does, it still has e.g. the modified copyright
headers I pointed out when this was still at try 1.
On 27 September 2013 15:23, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-27 14:19, schrieb Henri Verbeet:
>> Perhaps, I'm not sure. For that kind of comment to be useful it
>> should have a clear set of implications, and I&#x
On 27 September 2013 13:05, Stefan Dösinger wrote:
> I think we should place comments like "This function is called through
> the command stream" for all functions that are called through the CS,
> similar to what we do for context activation.
>
Perhaps, I'm not sure. For that kind of comment to b
On 25 September 2013 15:32, Rico Schüller wrote:
> Yes. Depending on the use case we may create it on the Begin/BeginPass when
> the shader is needed the first time (this may also be something like
> isParameterUsed or GetVertexShader). We don't need the shaders for cases
> like GetPassDesc, where
On 23 September 2013 21:05, Alexandre Julliard wrote:
> Henri Verbeet writes:
>
>> ---
>> dlls/wined3d/device.c | 51
>> +
>> dlls/wined3d/stateblock.c |5 +
>> 2 files changed, 20 insertions(+), 36 d
On 23 September 2013 13:29, Stefan Dösinger wrote:
> Note that Windows drivers disagree on which format they support. Nvidia
> has V16U16, AMD supports Q8W8V8U8, at least on r200. I am working on a
> more comprehensive converted format test that tests all supported signed
> formats with surfaces.
On 20 September 2013 13:04, Stefan Dösinger wrote:
> +static BOOL wined3d_volume_can_evict(const struct wined3d_volume *volume)
> +{
> +if (volume->resource.pool != WINED3D_POOL_MANAGED)
> +return FALSE;
> +if (volume->download_count < 10)
> +return FALSE;
That doesn't look
On 20 September 2013 13:04, Stefan Dösinger wrote:
> -volume->flags &= ~(WINED3D_VFLAG_ALLOCATED |
> WINED3D_VFLAG_SRGB_ALLOCATED);
> +volume->flags &= ~(WINED3D_VFLAG_ALLOCATED | WINED3D_VFLAG_SRGB_ALLOCATED
> +| WINED3D_VFLAG_CLIENT_STORAGE);
>
Indentation looks a bit off here.
On 17 September 2013 21:07, Stefan Dösinger wrote:
> I might have misunderstood what you meant with "separate flags for
> each GL resource type". Did you mean something like this
>
> B8G8R8A8_UNORM.flags[texture2d] = RENDERTARGET | TEXTURE | ...;
> B8G8R8A8_UNORM.flags[renderbuffer] = RENDERTARGET
On 17 September 2013 16:52, Stefan Dösinger wrote:
> Am 2013-09-17 13:55, schrieb Henri Verbeet:
>> I don't like this approach much. I think we should either do the
>> right thing right away and have separate flags for each GL resource
>> type (i.e., vertex/index buffer
On 17 September 2013 14:58, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-17 13:55, schrieb Henri Verbeet:
>> On 17 September 2013 11:39, Stefan Dösinger
>> wrote:
>>&g
On 17 September 2013 11:39, Stefan Dösinger wrote:
> diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h
> index 4928f92..eabf890 100644
> --- a/dlls/wined3d/wined3d_private.h
> +++ b/dlls/wined3d/wined3d_private.h
> @@ -2927,6 +2927,7 @@ extern enum wined3d_format_id
> p
On 17 September 2013 11:39, Stefan Dösinger wrote:
> ---
> dlls/wined3d/volume.c | 95
> +++
> 1 file changed, 88 insertions(+), 7 deletions(-)
>
Can't most of this be done on the resource level instead?
On 17 September 2013 11:48, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-17 09:22, schrieb Henri Verbeet:
>> Setting render target usage on a P8 surface for example would fail
>> surface creation, while such surfaces can't be
On 15 September 2013 21:47, Forest wrote:
> I wonder if the 80%+ gains reported in other games are not to be seen in
> Guild Wars 2, or if they're heavily dependent on CPU, GPU, graphics driver,
> and screen resolution.
>
> For the record, I'm using an Intel i5-3570K (stock speeds), GeForce GTX
>
On 15 September 2013 17:50, matyapiro31 wrote:
> + * wine is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any l
On 15 September 2013 14:25, Akihiro Sagawa wrote:
>
> diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c
> index 83cdaf9..9f9e12a 100644
> --- a/dlls/d3d8/tests/device.c
> +++ b/dlls/d3d8/tests/device.c
> @@ -1308,7 +1308,7 @@ static void test_reset(void)
> D3DFMT_R5G
On 12 September 2013 13:33, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-12 12:44, schrieb Henri Verbeet:
>> On 12 September 2013 12:23, Stefan Dösinger
>> wrote:
>>> + * On the r500 driver on Windows D3DCMP_GREATE
On 12 September 2013 12:23, Stefan Dösinger wrote:
> + * On the r500 driver on Windows D3DCMP_GREATER and D3DCMP_GREATEREQUAL
> are broken for depth
> + * values > 0.5. The range appears to be distored, apparently an
> incoming value of ~0.875 is
"distorted"?
On 11 September 2013 12:09, Jacek Caban wrote:
> +typedef enum D3D11_RESOURCE_MISC_FLAG
> +{
> +D3D11_RESOURCE_MISC_GENERATE_MIPS= 0x0001,
> +D3D11_RESOURCE_MISC_SHARED = 0x0002,
> +D3D11_RESOURCE_MISC_TEXTURECUBE
On 11 September 2013 13:37, Stefan Dösinger wrote:
> The next element is a BYTE. The 8 bits padding were stupid considering
> that, it just generates a hole. Now I am removing one bit, which
> leaves one bit of padding left.
>
It doesn't really work like that, the layout is like this:
UINT (4)
WO
On 11 September 2013 11:31, Stefan Dösinger wrote:
> -/* Reading the declaration makes only sense if the stateblock is
> finalized and the buffer bound to a stream */
> -if (device->isInDraw && buffer->resource.bind_count > 0)
> +/* Reading the declaration makes only sense if we have
On 11 September 2013 11:31, Stefan Dösinger wrote:
> @@ -330,7 +331,7 @@ static BOOL buffer_find_decl(struct wined3d_buffer *This)
> if(This->resource.usage & WINED3DUSAGE_STATICDECL) return FALSE;
> }
>
> -if (use_vs(state))
> +if (fixup_flags & WINED3D_BUFFER_FIXUP_USE_SHAD
On 11 September 2013 11:31, Stefan Dösinger wrote:
> @@ -1880,9 +1888,8 @@ struct wined3d_device
> WORD d3d_initialized : 1;
> WORD inScene : 1; /* A flag to check for proper
> BeginScene / EndScene call pairs */
> WORD softwareVertexProcessing : 1; /* process ve
On 9 September 2013 13:49, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-09 13:42, schrieb Henri Verbeet:
>> I think that's an unfortunate place to insert the field, and you
>> should update the padding.
>>
>>>&
On 9 September 2013 12:56, Stefan Dösinger wrote:
> -static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct
> wined3d_context *context)
> +static BOOL buffer_find_decl(struct wined3d_buffer *This, const struct
> wined3d_context *context,
> +const struct wined3d_state *sta
On 9 September 2013 12:56, Stefan Dösinger wrote:
> ---
I think this patch does a couple of things at once, and would probably
benefit from being broken up.
> static struct arb_vs_compiled_shader *find_arb_vshader(struct wined3d_shader
> *shader,
> -const struct arb_vs_compile_args *arg
On 9 September 2013 12:56, Stefan Dösinger wrote:
> @@ -148,7 +149,7 @@ static void buffer_create_buffer_object(struct
> wined3d_buffer *This, const struc
> }
>
> if (This->buffer_type_hint == GL_ELEMENT_ARRAY_BUFFER_ARB)
> -device_invalidate_state(This->resource.device, STATE_I
On 5 September 2013 10:42, Stefan Dösinger wrote:
> Yes, we don't actually support those, but that's wined3d's problem, not
> ddraw's.
We do. The difference between DXT2/DXT3 and DXT4/DXT5 is just a
convention wrt. storing pre-multiplied alpha or not, there's no
difference in the actual encoding.
On 5 September 2013 10:42, Stefan Dösinger wrote:
> +if(DDSD->ddsCaps.dwCaps2 & DDSCAPS2_TEXTUREMANAGE)
Minor formatting error here.
On 4 September 2013 23:18, Stefan Dösinger wrote:
> We set the frontbuffer as render target in wined3d_device_init_3d if
> there's no backbuffer, i.e., when ddraw is used. In theory this
> doesn't matter because we're not rendering to it, just blitting.
>
> Similarly, dlls/ddraw/device.c calls set
On 3 September 2013 14:07, Stefan Dösinger wrote:
> I'm checking this in d3d9/d3d8/ddraw because we create textures for
> everything nowadays, even stand-alone surfaces.
For ddraw that's not true yet, but I think my preferred way to handle
this would be to introduce a WINED3DUSAGE_TEXTURE usage fl
On 3 September 2013 17:45, Stefan Dösinger wrote:
> My main issue with a WINED3DUSAGE_TEXTURE flag is that
> create_texture(USAGE_TEXTURE) seems a bit weird - we might as well
> call it create_texture(USAGE_I_REALLY_MEAN_IT).
>
If that's the main issue, I could tell you that it will most likely
en
On 3 September 2013 13:31, Stefan Dösinger wrote:
> The idea behind the clamps is that the fixed function pipeline is
> generally limited to the [0.0;1.0] range. bbf313e7 added a test for
> that, and there was e.g. 14706 (which doesn't contain much info tbh).
>
Yes, but that's for stage operations
On 2 September 2013 23:04, Matteo Bruni wrote:
> +float quad1[] = {
> +-1.0, -1.0, 0.1, 0.0,0.0,1.0,
> + 0.0, -1.0, 0.1, 1.0,0.0,1.0,
> +-1.0,0.0, 0.1, 0.0,1.0,0.0,
> + 0.0,0.0, 0.1, 1.0,1.0,0.0
On 30 August 2013 17:09, Michael Müller wrote:
>
> +/* Get the implicit swapchain */
> +hr = IDirect3DDevice9_GetSwapChain(device, 0, &swapchain);
> +ok(SUCCEEDED(hr), "Failed to get the implicit swapchain (%08x)\n", hr);
> +if (SUCCEEDED(hr))
> +{
> +hr = IDirect3DSwap
On 30 August 2013 17:09, Michael Müller wrote:
> +static HRESULT WINAPI
> d3d9_swapchain_GetLastPresentCount(IDirect3DSwapChain9Ex *iface,
> +UINT *pLastPresentCount)
> +{
> +FIXME("iface %p, pLastPresentCount %p, stub!\n", iface,
> pLastPresentCount);
> +
> +if(pLastPresentCount
On 30 August 2013 00:19, Stefan Dösinger wrote:
> +if (format->flags & WINED3DFMT_FLAG_BLOCKS)
> +{
> +UINT width_mask = format->block_width - 1;
> +UINT height_mask = format->block_height - 1;
> +if (desc->width & width_mask || desc->height & height_mask)
> +
On 30 August 2013 00:19, Stefan Dösinger wrote:
> +/* A 8x4x2 texture consisting of 4 4x4 blocks. The colors of the
> blocks are red, green, blue and white. */
> +0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF8, 0x00,
> 0xF8, 0x00, 0x00, 0x00, 0x00,
> +0xff, 0x
On 30 August 2013 17:35, Stefan Dösinger wrote:
> Am 2013-08-30 17:31, schrieb Henri Verbeet:
>> Is this different from surfaces? IIRC surfaces are padded up to
>> the next multiple of the block size, although I may have that
>> wrong. Not a fan of the "(%p) : &qu
On 29 August 2013 11:14, Stefan Dösinger wrote:
> +BOOL activateapp_received;
> +IDirectDraw *activateapp_ddraw;
> +HWND activateapp_window;
> +DWORD activateapp_coop_level;
> +
I think those should be static, and you'll probably want to put them
in a structure.
On 23 August 2013 13:54, Stefan Dösinger wrote:
> The rules for surfaces and volumes aren't applicable to buffers
> anyway. A default pool buffer without D3DUSAGE_DYNAMIC is mappable for
> example.
>
I don't think the differences are insurmountable, but the main point
is still that I think this is
On 23 August 2013 12:04, Stefan Dösinger wrote:
>
> Am 23.08.2013 um 11:34 schrieb Henri Verbeet :
>> Why does loading into a PBO require CPU access?
> The only reason why we want to store a volume in a PBO is to map it, which
> requires CPU access. If the volume doesn't a
On 22 August 2013 23:22, Stefan Dösinger wrote:
> @@ -145,6 +158,9 @@ static DWORD volume_access_from_location(DWORD location)
> case WINED3D_LOCATION_TEXTURE_RGB:
> return WINED3D_RESOURCE_ACCESS_GPU;
>
> +case WINED3D_LOCATION_BUFFER:
> +return WINED3D_R
On 22 August 2013 03:31, Gediminas Jakutis wrote:
> +{"GTX 770", CARD_NVIDIA_GEFORCE_GTX770},/* Geforce 700 -
> highend */
> {"GTX 770M",CARD_NVIDIA_GEFORCE_GTX770M}, /* Geforce 700 -
> midend high mobile */
That doesn't work, it will always match "GTX 770
On 22 August 2013 14:57, Stefan Dösinger wrote:
> +if (volume->locations & WINED3D_LOCATION_DISCARDED)
> +{
> +TRACE("Volume previously discarded, nothing to do.\n");
> +wined3d_volume_invalidate_location(volume,
> WINED3D_LOCATION_DISCARDED
On 22 August 2013 13:32, Stefan Dösinger wrote:
> Is it ok to worry about this later and just remove
> WINED3D_RESOURCE_ACCESS_SCRATCH for now?
>
Sure.
On 22 August 2013 13:07, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-08-22 12:58, schrieb Henri Verbeet:
>> Yes, but if "pool" goes away we need some other way to check for
>> scratch resources. It's just that in
On 22 August 2013 11:53, Stefan Dösinger wrote:
> I think it's best to check the pool in operations that accept a
> resource as parameter. We already do that in most places.
Yes, but if "pool" goes away we need some other way to check for
scratch resources. It's just that in retrospect the access
On 22 August 2013 09:58, Stefan Dösinger wrote:
> What I'm not quite happy with is WINED3D_RESOURCE_ACCESS_SCRATCH.
> Scratch resources are mappable. Having the extra location just
> complicates things and I see no gain from it.
>
Yeah, I'm not particularly happy about it either. The issue is that
On 22 August 2013 00:30, Stefan Dösinger wrote:
> +const char *wined3d_debug_location(DWORD location)
> +{
> +char buf[238];
That number looks a bit arbitrary, although I suppose it's at least
large enough.
> +if (volume->resource.pool == WINED3D_POOL_SYSTEM_MEM
> +|| volume->
On 20 August 2013 13:16, Stefan Dösinger wrote:
> Am 2013-08-20 13:12, schrieb Henri Verbeet:
>> Somewhat related, I don't think there's really a reason to have
>> both "allocatedMemory" and "heap_memory" anymore. It should
>> probably jus
On 20 August 2013 12:07, Stefan Dösinger wrote:
> +void *wined3d_alloc_resource_mem(SIZE_T size)
> +{
> +void **p;
> +SIZE_T align = RESOURCE_ALIGNMENT - 1 + sizeof(*p);
> +void *mem;
> +
> +if (!(mem = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size + align)))
> +return
On 19 August 2013 14:20, Stefan Dösinger wrote:
> Am 2013-08-19 13:53, schrieb Henri Verbeet:
>> That's actually a bug in what I posted.
> What's your suggested fix? Allocating size + align + alignment, and
> adding alignment to mem if mem happens to be already aligned?
On 19 August 2013 13:51, Stefan Dösinger wrote:
> Am 2013-08-19 12:39, schrieb Henri Verbeet:
>> On 19 August 2013 10:52, Stefan Dösinger
>> wrote:
>>> +void wined3d_volume_set_texture_level(struct wined3d_volume
>>> *volume, GLint level) +{ +volume->text
On 19 August 2013 13:38, Stefan Dösinger wrote:
> I guess in theory any kind of payload could be added to your
> implementation, but growing this larger than RESOURCE_ALIGNMENT(=16)
> bytes moots the point I guess.
The point is mostly that I don't think we want the wined3d_heap_memory
structure to
On 19 August 2013 10:52, Stefan Dösinger wrote:
> +void wined3d_volume_set_texture_level(struct wined3d_volume *volume, GLint
> level)
> +{
> +volume->texture_level = level;
> +}
>
I think that's a step in the wrong direction. I think this should be
set on volume creation. We do have a constr
On 19 August 2013 10:52, Stefan Dösinger wrote:
> +volume->flags |= WINED3D_VFLAG_LOCKABLE; /* FIXME */
You'll probably want to fix that :-) I think you can just leave the
flag out until you rename it to WINED3D_VFLAG_MAPPABLE in one of the
later patches.
On 19 August 2013 10:52, Stefan Dösinger wrote:
> @@ -184,7 +184,16 @@ HRESULT CDECL wined3d_volume_map(struct wined3d_volume
> *volume,
> volume, map_desc, box, flags);
>
> if (!volume->resource.allocatedMemory)
> -volume->resource.allocatedMemory = HeapAlloc(GetProcess
On 19 August 2013 10:52, Stefan Dösinger wrote:
> +struct wined3d_heap_memory *wined3d_alloc_resource_mem(UINT size)
> +{
> +struct wined3d_heap_memory *ret;
> +
> +ret = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*ret));
> +if (!ret)
> +return NULL;
> +
> +ret->a
On 18 August 2013 11:16, Francois Gouget wrote:
> On Fri, 16 Aug 2013, Ken Sharp wrote:
> [...]
>> It takes longer to create a bug report than it does to link it to the
>> database. It really isn't that hard.
>
> But adding a link requires going and logging into a separate web site.
> That's reall
On 13 August 2013 17:23, Bruno Jesus <00cp...@gmail.com> wrote:
> My filters are still working fine, probably they are configured the
> same as yours:
>
> Matches: to:(wine-devel@winehq.org)
> Do this: Skip Inbox, Apply label "WineDevel", Never send it to Spam
>
> Matches: from:(wine-b...@winehq.or
On 13 August 2013 12:28, Jacek Caban wrote:
> The question is, where should it go?
>
> - Github seems to be the choice for most project currently and it's
> already used by Wine Mono.
> - Reconsider source.winehq.org. This was not chosen due to account
> management overhead, but that's the only wa
On 1 August 2013 12:25, Stefan Dösinger wrote:
> diff --git a/dlls/ddraw/executebuffer.c b/dlls/ddraw/executebuffer.c
> index 2925cfa..5c12272 100644
> --- a/dlls/ddraw/executebuffer.c
> +++ b/dlls/ddraw/executebuffer.c
> @@ -382,10 +382,10 @@ HRESULT d3d_execute_buffer_execute(struct
> d3d_execu
On 22 July 2013 20:24, Matteo Bruni wrote:
> @@ -3614,10 +3614,19 @@ void wined3d_ffp_get_vs_settings(const struct
> wined3d_state *state, const struct
> & WINED3D_FFP_LIGHT_TYPE_MASK) <<
> WINED3D_FFP_LIGHT_TYPE_SHIFT(i);
> }
>
> +settings->ortho_fog = 0;
> if
On 19 July 2013 15:34, Qian Hong wrote:
> Further tests show that the simplest hack to avoid crashing is
> replacing line 71 to:
> FIXME("anything %x\n", 0xdeadbeef);
>
> I have no idea what the real fix is, any suggestion what is the next
> step to debug?
>
Well, it sounds a bit like some form of
On 30 June 2013 09:36, Frédéric Delanoy wrote:
> On Sun, Jun 30, 2013 at 6:08 AM, 中川祥 wrote:
>>
> Hi, please resubmit this patch with your full name transliterated in English.
>
I may just be missing something, but is there actually a good reason for that?
On 26 June 2013 03:53, Austin English wrote:
> My understanding was that using the _WIN64 macro was preferred. I can
> certainly do that instead. How's this?
>
I could probably live with that, though perhaps make it a helper
function, and I'm not entirely sure this will print something
meaningful
On 25 June 2013 18:26, Stefan Dösinger wrote:
> While I agree with Henri's statement to some extend - patch reviewing
> is a terribly exhausting task - I think the statement was a bit harsh
> to say to someone who donates his personal time to the project.
>
Well, I could try to sugarcoat it a bit,
On 25 June 2013 11:05, Christian Costa wrote:
> 2013/6/25 Henri Verbeet
>> At least try to pretend you put
>> some effort into making sure the patch is as good as it can be before
>> submitting it.
>
>
> I could have send the patch to wine-devel first but would
On 24 June 2013 16:44, Matteo Bruni wrote:
> @@ -1673,6 +1673,8 @@ struct texture_stage_op
> unsignedaarg2 : 8;
> unsignedaarg0 : 8;
>
> +DWORD constant;
> +
> struct color_fixup_desc color_fixup;
> unsignedt
On 23 June 2013 21:57, Christian Costa wrote:
> When D3DTA_CONSTANT is use in a texture stage, the generated shader uses
> variables that are not defined making thus the compilation to fail.
> This patch declare these variables with the value from the related texture
> stage state D3D_TSS_CONSTA
On 23 June 2013 07:10, Austin English wrote:
> Please consider applying before the release of 1.6. It has no
> functional changes, but would really help when diagnosing user
> problems.
>
This is not really a wined3d patch. That said, while I agree that
printing the architecture would be useful he
On 21 June 2013 12:06, Stefan Dösinger wrote:
> This also works for fog_start == fog_end on drivers that don't handle
> this situation correctly with fixed function fog. Tested on nvidia,
> r300g, r600g.
What does this fix?
On 20 June 2013 13:18, Stefan Dösinger wrote:
> I don't know any application that depends on this. It just seemed like
> an interesting thing to test to see how far the interaction between
> the different APIs goes.
>
> Just to make sure I understand you correctly: You're saying that the
> test sh
On 20 June 2013 12:17, Stefan Dösinger wrote:
> /* Light state */
> DWORD material;
> +DWORD dummy_rs_lighting;
>
Considering the render state doesn't exist in early ddraw versions, do
we really care that its value is preserved? It seems unlikely that
anything except our tests would
On 20 June 2013 12:17, Stefan Dösinger wrote:
> -return IDirect3DDevice7_DrawPrimitive(&device->IDirect3DDevice7_iface,
> device->primitive_type,
> +return IDirect3DDevice3_DrawPrimitive(&device->IDirect3DDevice3_iface,
> device->primitive_type,
> device->vertex_type, device
On 20 June 2013 12:17, Stefan Dösinger wrote:
> @@ -4250,7 +4250,12 @@ static HRESULT WINAPI d3d2_CreateDevice(IDirect3D2
> *iface, REFCLSID riid,
> wined3d_mutex_lock();
> hr = d3d_device_create(ddraw, surface_impl, 2, &device_impl, NULL);
> if (SUCCEEDED(hr))
> +{
>
On 19 June 2013 21:59, Matteo Bruni wrote:
> While it doesn't really matter for the test results (it only affects the
> alpha component of the following test but that isn't checked anyway) I feel
> it's a good idea to properly cleanup and avoid dependencies between
> tests.
Yeah, though ideally we
On 18 June 2013 16:52, Stefan Dösinger wrote:
> It's needed to switch between the different handling of fogstart and fogend
> in vertex and table fog. The ddraw test shows this. The d3d8 and d3d9 tests
> succeed without it because they're also switching vertex and pixel shaders
> when the test
On 18 June 2013 16:17, Stefan Dösinger wrote:
> diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c
> index e14d7ab..ad9be6a 100644
> --- a/dlls/wined3d/glsl_shader.c
> +++ b/dlls/wined3d/glsl_shader.c
> @@ -7107,7 +7109,7 @@ static void glsl_fragment_pipe_fog(struct
> wined3d_co
On 18 June 2013 14:19, Stefan Dösinger wrote:
> Am 2013-06-18 09:12, schrieb Henri Verbeet:
>> Which of those is affected by the quirk? I think all of those
>> except r200 should be able to do GLSL, but you say r200 is the only
>> one that doesn't pass the tests.
&g
On 18 June 2013 09:12, Henri Verbeet wrote:
> On 17 June 2013 22:53, Stefan Dösinger wrote:
>> +if (isnan(fogstart) || isinf(fogstart) ||
>> isinf(-fogstart))
> You should only need one isinf() here, it's not supposed to care about the
> sig
We probably want this regardless of the next patch, but I'd prefer for
this kind of thing to go in after the release.
1 - 100 of 1497 matches
Mail list logo
