Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2318
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2292
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2269
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2270
Your paranoid andr
2013/9/3 Henri Verbeet :
> 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
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
g to do with the this bug as we use already
freed memory in our implementation.
I don't see anything in the log that would keep the texture around.
There may be some capability flag issues that trigger a broken
codepath in the game, but such an issue is really hard to find.
diff --git a/dl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-15 10:53, schrieb Rico Schüller:
> I'm not sure what GetTexture does, a test might show it (I'll have
> a look). The problem might be, that we use some members, which
> native probably doesn't do in SetTexture. You couldn't call
> GetTexture
On 15.04.2013 10:24, Stefan Dösinger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-14 16:53, schrieb Rico Schüller:
+if (iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl
*)&Direct3DTexture8_Vtbl +&& iface->lpVtbl != (const
IDirect3DBaseTexture8Vtbl *)&Direct3D
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-14 16:53, schrieb Rico Schüller:
> +if (iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl
> *)&Direct3DTexture8_Vtbl +&& iface->lpVtbl != (const
> IDirect3DBaseTexture8Vtbl *)&Direct3DCubeTexture8_Vtbl +
> && iface->lpVtbl !=
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23963
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23943
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23928
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23877
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23865
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23820
Your paranoid android
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-01-09 17:04, schrieb Alexandre Julliard:
> ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p
> d3d8_test.exe.so device.c && touch device.ok device.c:4088: Test
> failed: Got unexpected hr 0x88760867. device.c:
Henri Verbeet writes:
> ---
> dlls/d3d8/tests/Makefile.in |1 -
> dlls/d3d8/tests/device.c| 704
> ++-
> dlls/d3d8/tests/surface.c | 653 ---
> 3 files changed, 702 insertions(+), 656 dele
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=23788
Your paranoid android
On 10/30/12 12:01, Alexandre Julliard wrote:
> Henri Verbeet writes:
>
>> We can certainly generate some more d3d headers from idl, and we
>> probably should anyway, but I'm not sure how that's going to make the
>> mechanism any more generic. I suppose we could do something like
>> "DECL_WINELIB_T
Henri Verbeet writes:
> We can certainly generate some more d3d headers from idl, and we
> probably should anyway, but I'm not sure how that's going to make the
> mechanism any more generic. I suppose we could do something like
> "DECL_WINELIB_TYPE(struct IDirect3D8, *LPDIRECT3D8);", if that's mu
On 30 October 2012 10:41, Alexandre Julliard wrote:
> I don't think we want to do that sort of thing, otherwise we'll end up
> with ifdef __WINESRC__ all over the standard headers. If we really want
> to disable interface typedefs this should be done in a generic way,
> preferably when generating
Henri Verbeet writes:
> @@ -1128,6 +1105,21 @@ DECLARE_INTERFACE_(IDirect3DDevice8,IUnknown)
> #define IDirect3DDevice8_DeletePatch(p,a)
> (p)->DeletePatch(a)
> #endif
>
> +#ifndef __WINESRC__
> +typedef struct IDirect3D8 *LPDIRECT3D8;
> +typedef struct IDirect3DDevi
On 9 December 2011 12:54, Stefan Dösinger wrote:
> + d3d = pDirect3DCreate8(D3D_SDK_VERSION);
> + ok(d3d != NULL, "Direct3DCreate8 failed.\n");
> + hwnd = CreateWindow("d3d8_test_wc", "d3d8_test", WS_OVERLAPPEDWINDOW,
> 100, 100, 160, 160, NULL, NULL, NULL, NULL);
> + ok(hwnd != NULL,
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=15656
Your paranoid android
commit fd1afd24f4af20646ce0f3a7ac2064e8e49b1e7d
Author: Henri Verbeet
Date: Wed Oct 19 22:03:11 2011 +0200
d3d8/tests: Add a small test for multisampled CopyRects().
This commit causes the d3d8:visual to crash on my desktop (Debian
Testing, 9600GT, 285.05.09-1 proprietary driver):
wine
On 24 October 2011 18:58, Matteo Bruni wrote:
> + if (pCaps->VertexShaderVersion > D3DVS_VERSION(1,1))
> + pCaps->VertexShaderVersion = D3DVS_VERSION(1,1);
> + if (pCaps->PixelShaderVersion > D3DPS_VERSION(1,4))
> + pCaps->PixelShaderVersion = D3DPS_VERSION(1,4);
> +
fixup_caps
On Wed, Oct 12, 2011 at 04:39, Henri Verbeet wrote:
> On 12 October 2011 01:51, Austin English wrote:
>> Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies
>> the behavior to match the d3d9 behavior.
>>
> I seem to recall this being intentional, so t
On 12 October 2011 01:51, Austin English wrote:
> Current d3d8 does a win_skip(), while d3d9 does a skip(). This unifies
> the behavior to match the d3d9 behavior.
>
I seem to recall this being intentional, so that you get a failure if
your setup has e.g. no OpenGL.
On Monday 10 October 2011 10:20:15 Henri Verbeet wrote:
> It's not really clear to me that refusing to create P8 surfaces in
> d3d8/9 really gains us much, or that it's really a prerequisite for
> the other patches.
I guess you've got a point here, if we just allow the sur
n a way I may have missed.
>
It's not really clear to me that refusing to create P8 surfaces in
d3d8/9 really gains us much, or that it's really a prerequisite for
the other patches. If you want to go that way though, you should
probably just map D3DFORMAT_P8 to something that's no
On Sunday 09 October 2011 16:40:11 Henri Verbeet wrote:
> I thought you asked me not to look at these patches yet because you
> still had some issues to fix. Regardless, I gave this a cursory look:
Yeah, those were the ones that implemented blitting in a different way in
wined3d and had issues wit
On 9 October 2011 15:21, Stefan Dösinger wrote:
> This is the first set of my P8 patches, they remove dead code that is left
> over
> from d3d8/9 style palettized texture support. See
> http://www.winehq.org/pipermail/wine-devel/2011-October/092744.html for the
> entire patchset.
On Tuesday 26 July 2011 17:33:54 Jacek Caban wrote:
> On 07/26/11 17:22, Henri Verbeet wrote:
> > No, I disagree with the basic idea that stricter tests are necessarily
> > better. The advantage of SUCCEEDED is that it's *less* strict.
>
> We won't agree on that.
I prefer comparison against S_OK(o
On 07/26/11 17:22, Henri Verbeet wrote:
> On 26 July 2011 16:57, Jacek Caban wrote:
>> Seriously, I'm not talking about anything like that. We get to choose
>> between using two things. SUCCEDEED() has no advantages over testing
>> exact values in this context. Testing the exact value has a small,
On 26 July 2011 16:57, Jacek Caban wrote:
> Seriously, I'm not talking about anything like that. We get to choose
> between using two things. SUCCEDEED() has no advantages over testing
> exact values in this context. Testing the exact value has a small, but
> still, advantage. I believe we agree o
On 07/26/11 16:34, Henri Verbeet wrote:
> On 26 July 2011 16:08, Jacek Caban wrote:
>> If there is no cost of having tests more strict (like code
>> complication), it is a good principle IMO. In this case it's a matter of
>> choosing the right way for testing results, so it should be preferable.
>
On 26 July 2011 16:08, Jacek Caban wrote:
> If there is no cost of having tests more strict (like code
> complication), it is a good principle IMO. In this case it's a matter of
> choosing the right way for testing results, so it should be preferable.
>
We're not testing return codes here, so IMO
On 07/26/11 13:04, Henri Verbeet wrote:
> On 26 July 2011 10:57, Jacek Caban wrote:
>> It's better to test for the exact value in tests like hr == S_OK. It
>> makes tests stricter.
> I don't think that making tests more strict than necessary is a good
> principle.
If there is no cost of having te
On 26 July 2011 10:57, Jacek Caban wrote:
> It's better to test for the exact value in tests like hr == S_OK. It
> makes tests stricter.
I don't think that making tests more strict than necessary is a good
principle. (Not that it matters a lot here anyway, for most of these
D3D_OK is the only poss
Hi Austin,
ok(SUCCEEDED(hr), "GetRenderTarget failed, hr %#x.\n", hr);
hr = IDirect3DSurface8_GetDesc(surface, &surface_desc);
+ok(SUCCEEDED(hr), "GetDesc failed, hr %#x.\n", hr);
It's better to test for the exact value in tests like hr == S_OK. It
makes tests stricter. I know ther
--
-Austin
diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c
index 9a4369b..d159a52 100644
--- a/dlls/d3d8/tests/device.c
+++ b/dlls/d3d8/tests/device.c
@@ -1050,6 +1050,7 @@ static void test_reset(void)
hr = IDirect3DDevice8_GetRenderTarget(device1, &surface);
uot; is the correct level of abstraction for wined3d. I
> suspect we'll see that break down a bit as we implement more of
> d3d10/11, and perhaps also with some ddraw cleanups. (To pick a random
> example, consider d3d10/11 sampler states vs d3d8/9 sampler states.)
>
> Note that WIN
On 31 May 2011 12:50, Alexandre Julliard wrote:
> I mean using D3DPOOL in wined3d, not by including the d3d9 headers, but
> by defining it when necessary, i.e. if neither d3d8types.h nor
> d3d9types.h have been included already.
>
> This way d3d8 uses the d3d8 definition, d3d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The two patches look ok
Am 03.06.2011 um 14:23 schrieb Andrew Nguyen:
> ---
> dlls/d3d8/d3d8_private.h |5 +++--
> dlls/d3d8/device.c | 29 -
> dlls/d3d8/directx.c |2 +-
> dlls/d3d8/tests/
d lead to a mixture of WINED3D* and D3D* types. But that could be
addressed with a #define WINED3DPOOL D3DPOOL if D3DPOOL is available and
declaring the num if D3DPOOL is not available.
There are types like D3DRENDERSTATETYPE that aren't clear subsets/supersets.
For example d3d8 has D3D
? Or do you mean using the D3DPOOL type in
> wined3d by including the d3d9 headers(this works in wined3d.dll
> itself)?
I mean using D3DPOOL in wined3d, not by including the d3d9 headers, but
by defining it when necessary, i.e. if neither d3d8types.h nor
d3d9types.h have been included already.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 31.05.2011 um 12:12 schrieb Alexandre Julliard:
> Most enums are identical, or just have an extra value or two. I don't
> see why you can't pass either type to wined3d since they have the same
> name.
Do you mean the status quo? Or do you mean usin
Stefan Dösinger writes:
> Am 31.05.2011 um 11:10 schrieb Alexandre Julliard:
>> I still don't see the point of that kind of switch statement. To be
>> honest I don't see either why we even need different enum types in the
>> first place.
> Because for most e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 31.05.2011 um 11:10 schrieb Alexandre Julliard:
> I still don't see the point of that kind of switch statement. To be
> honest I don't see either why we even need different enum types in the
> first place.
Because for most
Frédéric Delanoy writes:
> +static inline D3DPOOL d3dpool_from_wined3dpool(WINED3DPOOL type)
> +{
> +switch (type)
> +{
> +case WINED3DPOOL_DEFAULT: return D3DPOOL_DEFAULT;
> +case WINED3DPOOL_MANAGED: return D3DPOOL_MANAGED;
> +case WINED3DPOOL_SYSTEMMEM: return D
On Monday 30 May 2011 13:34:25 Frédéric Delanoy wrote:
> In a similar vein, there's also
> +case WINED3DMULTISAMPLE_NONE: return D3DMULTISAMPLE_NONE;
> +case WINED3DMULTISAMPLE_NONMASKABLE: return (D3DMULTISAMPLE_TYPE)
> type;
>
> Does this also need to be moved to device.c?
Yes, t
On Mon, May 30, 2011 at 12:42, Stefan Dösinger wrote:
> On Sunday 29 May 2011 09:46:06 Frédéric Delanoy wrote:
>
>> +static inline D3DRESOURCETYPE
>> d3dresourcetype_from_wined3dresourcetype(WINED3DRESOURCETYPE type) +{
>> ...
>> + case WINED3DRTYPE_BUFFER: return D3DRTYPE_VERTEXBUFFER;
>>
On Sunday 29 May 2011 09:46:06 Frédéric Delanoy wrote:
> +static inline D3DRESOURCETYPE
> d3dresourcetype_from_wined3dresourcetype(WINED3DRESOURCETYPE type) +{
> ...
> +case WINED3DRTYPE_BUFFER: return D3DRTYPE_VERTEXBUFFER;
> ...
> +static inline WINED3DRESOURCETYPE
> wined3dresourcetype_
On Monday 30 May 2011 11:29:26 Frédéric Delanoy wrote:
> Yeah right, I changed/adapted the title in [7/8] since the conv
> function wasn't needed anymore and thought that if I used a [7/8] with
> another subject and (try 2) it wouldn't be noticed straightforwardly.
Nah, Alexandre's scripts work ve
On Mon, May 30, 2011 at 10:58, Stefan Dösinger wrote:
>
> Am 29.05.2011 um 19:35 schrieb Frédéric Delanoy:
>
>> Please skip this patch; it needs adaptation to avoid rebasing/merge
>> conflicts due to changes to be done in patch " [7/8] d3d8: Use
>> D3DRENDERSTA
Am 29.05.2011 um 19:35 schrieb Frédéric Delanoy:
> Please skip this patch; it needs adaptation to avoid rebasing/merge
> conflicts due to changes to be done in patch " [7/8] d3d8: Use
> D3DRENDERSTATETYPE -> WINED3DRENDERSTATETYPE enum conversion function
> instead of implic
is->wined3d_device, +
> wined3drenderstatetype_from_d3drenderstatetype(State), Value); }
> wined3d_mutex_unlock();
d3d8's SetRenderState and GetRenderState already have a switch-case statement
because ZBIAS doesn't exist in wined3d, so strictly speaking a direct cast is
not possible. You cannot move the switch-
Please discard this patch. An updated version follows.
On 3 May 2011 22:59, Marvin wrote:
> === WXPPROSP3 (32 bit device) ===
> TestLauncher.c:89: Test failed: Can't open test executable
> C:\winetest\d3d8_test.exe, error 32
>
I don't think this patch introduced this failure.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=10710
Your paranoid android
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=10709
Your paranoid android
On 22 April 2011 14:25, "Stefan Dösinger" wrote:
> An unrelated issue I am ignoring for now:
> void * __cdecl wined3d_buffer_get_parent(const struct wined3d_buffer *buffer);
>
> in the .idl file is compiled by Microsoft's midl to
>
> void *__cdecl wined3d_buffer_get_parent(
> struct wined3d_buf
> Yeah, I wrote that test. But please add the one for a NULL rt with
> non-NULL DS as well, it should be pretty trivial.
Working on it. I'd still consider the existing tests to be enough for this NULL
pointer regression fix to go in before the snapshot release.
The tests will take a little longer
On 22 April 2011 13:29, Stefan Dösinger wrote:
> We have a test. It didn't catch the problem because it tests setting both the
> depth stencil and RT to NULL, so the check if the depthstencil is NULL in
> SetRenderTarget prevented the crash. Well, I guess I can add a test for
> that...
>
Yeah, I w
On Friday 22 April 2011 12:40:04 Henri Verbeet wrote:
> Tests, please. Also, at least with the current code this is still
> going to fail because wined3d disallows setting RT0 to NULL.
We have a test. It didn't catch the problem because it tests setting both the
depth stencil and RT to NULL, so th
Tests, please. Also, at least with the current code this is still
going to fail because wined3d disallows setting RT0 to NULL.
Am Donnerstag 10 März 2011, 22:15:39 schrieb Henri Verbeet:
> You could just ask wined3d for the surface size.
Yes, with the overhead of two Surface::GetDesc calls per SetRenderTarget call.
signature.asc
Description: This is a digitally signed message part.
On 10 March 2011 22:58, Stefan Dösinger wrote:
> @@ -264,6 +264,8 @@ struct IDirect3DSurface8Impl
>
> /* If set forward refcounting to this object */
> IUnknown*forwardReference;
> +
> +UINTwidth, height;
> };
You could just ask wined3d fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 24.01.2011 um 13:02 schrieb
:
> - Wylda's Intel-based machine #2 passes the tests. Hurray!
> - One unknown win7 machine with Intel gfx also passes them.
> - Aurimas' machine produces one different error (also Intel gfx).
Afaik the test passes on
On 24 January 2011 13:02, wrote:
> My conclusion: the tests only prove that Wine wants to mimic Intel graphics,
> but they do not account for the variety of observed test results.
The issue is more subtle than that.
Hi,
Trying to understand bugs #10636 and #19773 , I glanced at the
d3d8 visual.ok directx test results. It appears that the green
colour on test.winehq does not mean much.
- All (any exception?) WTB machines skip the tests because
d3d8 is not installed.
- Same for Francois Gouget's vi
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=7411
Your paranoid android.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=7410
Your paranoid android.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=6785
Your paranoid android.
. The Microsoft ddraw.h/d3d8/d3d9 and other headers do the same
before declaring the IDirect3D interfaces (actually dsound and tons of
other headers also do it).
Roderick
On Wed, Sep 8, 2010 at 5:22 AM, Alexandre Julliard wrote:
> Roderick Colenbrander writes:
>
>> @@ -129,6 +129,7
Roderick Colenbrander writes:
> @@ -129,6 +129,7 @@ typedef struct IDirect3DVolumeTexture8
> *LPDIRECT3DVOLUMETEXTURE8, *PDIRECT3DVOLU
>
> /*
> * IDirect3D8 interface
> */
> +#undef INTERFACE
> #define INTERFACE I
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=2319
Your paranoid android.
On 19 March 2010 16:31, Alexandre Julliard wrote:
> Reliably testing the foreground window is pretty hard, since the window
> manager is in charge of it. The user32 tests try, but despite their best
> efforts they still fail sometimes. So if you don't absolutely need that
> test, removing it is pr
Henri Verbeet writes:
> On 19 March 2010 16:01, Alexandre Julliard wrote:
>> It doesn't work here:
>>
>> ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p
>> d3d8_test.exe.so device.c && touch device.ok
>> device.c:1616: Test failed:
On 19 March 2010 16:01, Alexandre Julliard wrote:
> It doesn't work here:
>
> ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so
> device.c && touch device.ok
> device.c:1616: Test failed: Expected focus 0x60100, got (nil).
> devic
Henri Verbeet writes:
> ---
> dlls/d3d8/tests/device.c | 22 ++
> 1 files changed, 18 insertions(+), 4 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so
device.c && touch device.ok
devi
There are not scary but uselessly noisy.
Having to much redondant messages doesn't help unless traces are enabled.
I can always display the fixme when traces are enable if it suits you.
Henri Verbeet a écrit :
On 17 February 2010 11:47, Christian Costa wrote:
I'm not much of a fan of the wh
On 17 February 2010 11:47, Christian Costa wrote:
>
I'm not much of a fan of the whole "let's disable the scary debug
output" idea, especially since now the function becomes invisible
after the first call for people doing actual debugging, unless you run
with +relay. WINEDEBUG="-all" is much more
2010/1/11 Alexandre Julliard :
> Nicolas Le Cam writes:
>
>> @@ -175,7 +175,7 @@ static DWORD d3d8_allocate_handle(struct
>> d3d8_handle_table *t, void *object, enu
>> entry = t->free_entries;
>> if (entry->type != D3D8_HANDLE_FREE)
>> {
>> - ERR("Handle %u(%
Nicolas Le Cam writes:
> @@ -175,7 +175,7 @@ static DWORD d3d8_allocate_handle(struct
> d3d8_handle_table *t, void *object, enu
> entry = t->free_entries;
> if (entry->type != D3D8_HANDLE_FREE)
> {
> -ERR("Handle %u(%p) is in the free list, but has type %#x
Am 04.12.2009 um 01:26 schrieb David Anderson:
> Thanks to James Mckenzie and Austin English for earlier hints. I've
> installed more stuff (ubuntu packages) and spent a bit more time with d3d8.
>
> I assume most people get these tests to work, so I'm a bit distressed I
Thanks to James Mckenzie and Austin English for earlier hints. I've
installed more stuff (ubuntu packages) and spent a bit more time with d3d8.
I assume most people get these tests to work, so I'm a bit distressed I
cannot seem to get
them to work properly, 100%.
The large amount of
On Mi, 2009-11-11 at 15:16 +0100, Henri Verbeet wrote:
> I.e., does the attached patch work for you?
yes, with 0 failures :-)
d3d9 has the same code (but i cant test d3d9 on my machine).
Thanks.
Do you want to send the patches yourself?
--
By by ... Detlef
tached patch work for you?
diff --git a/dlls/d3d8/tests/stateblock.c b/dlls/d3d8/tests/stateblock.c
index 30d022c..630c4de 100644
--- a/dlls/d3d8/tests/stateblock.c
+++ b/dlls/d3d8/tests/stateblock.c
@@ -1737,7 +1737,7 @@ static void resource_test_data_init(IDirect3DDevice8
*device,
data->te
I think the create flags would be more robust here.
Is 0 really special here, or should invalid handles in general just
return D3D_OK? I imagine this affects
IDirect3DDevice8Impl_CaptureStateBlock() as well.
SION(1,1)){
> > pCaps->VertexShaderVersion = D3DVS_VERSION(1,1);
> > }
> > +pCaps->MaxVertexShaderConst = min(256, pCaps->MaxVertexShaderConst);
>
> I think you should use D3D8_MAX_VERTEX_SHADER_CONSTANTF here.
Yes, indeed. I'll resend d3d8/directx.c has the same issue.
Not my preferred fix, but I suppose it works.
> @@ -359,6 +359,7 @@ static HRESULT WINAPI
> IDirect3DDevice8Impl_GetDeviceCaps(LPDIRECT3DDEVICE8 iface
> if(pCaps->VertexShaderVersion > D3DVS_VERSION(1,1)){
> pCaps->VertexShaderVersion = D3DVS_VERSION(1,1);
> }
> +pCaps->Max
Am Montag, 6. April 2009 00:30:31 schrieb Henri Verbeet:
> 2009/4/4 Stefan Dösinger :
> > +pDesc->Usage = pDesc->Usage;
> > +pDesc->Pool = pDesc->Pool;
> > +pDesc->Size = pDesc->Size;
>
> This is just silly.
Hmm Smells like copypaste
2009/4/4 Stefan Dösinger :
> +pDesc->Usage = pDesc->Usage;
> +pDesc->Pool = pDesc->Pool;
> +pDesc->Size = pDesc->Size;
This is just silly.
Henri Verbeet wrote:
Hi,
+EnterCriticalSection(&d3d8_cs);
+*pToken = d3d8_allocate_handle(&This->handle_table, object);
LeaveCriticalSection(&d3d8_cs);
Is there a need for that extra EnterCriticalSection()
FWIW, I think the right way to fix this would be to use a handle table
like for shaders.
On Mon, Feb 23, 2009 at 1:58 AM, Henri Verbeet wrote:
> 2009/2/23 Austin English :
>> +STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE;
>> +STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE;
>> +STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE;
>> +STDMETHOD
2009/2/23 Austin English :
> +STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE;
> +STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE;
> +STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE;
> +STDMETHOD(CreateStateBlock)(THIS_ D3DSTATEBLOCKTYPE Type,DWORD_PTR *
1 - 100 of 268 matches
Mail list logo
