Re: winex11.drv: Transmit WM_DEADCHAR messages to applications
Simon Lipp wrote: > + * Moreover, let dead chars be processed or we will never have > + * WM_DEADCHAR events That's how it's supposed to work. Wine should never generate WM_DEADCHAR message, it relies in the driver to handle dead keys and generate final events. X11 even has an ability to support user defined key sequences which are handled by XFilterEvent and which will be broken by your patch. -- Dmitry.
Re: Fun with GCC 4.8
On Mon, Apr 15, 2013 at 02:37:27PM -0600, James Eder wrote: > As many of you no doubt know, GCC recently released 4.8.0. This new > version introduces a new optimization level enabled by -Og with the > following description (from the man page): > > "Optimize debugging experience. -Og enables optimizations that do not > interfere with debugging. It should be the optimization level of choice for > the standard edit-compile-debug cycle, offering a reasonable level of > optimization while maintaining fast compilation and a good debugging > experience." > > Of course I had to try it out. I found that building Wine lead to GCC > dieing with > > ... dlls/kernel32/console.c:1691:1: internal compiler error: Segmentation > fault > > I also found > > ... dlls/kernel32/computername.c:701:1: internal compiler error: > Segmentation fault > > I eventually stumbled my way into the enclosed patch which lets GCC build > Wine with -Og. > > I'm not sure if this change (or something similar) makes sense for Wine. > I'm fairly certain some changes make sense for GCC (I suspect that GCC > should not segfault). > > I haven't submitted a bug for GCC because I suspect they'll want me to > provide something simpler to compile than the Wine source tree. I > certainly won't be upset if someone beats me too it. I'm not sure how much > time in the near future I'll spend on it. "Eventually" is probably the > word that fits. > > At any rate, I wanted to at least share my experiences in case anyone is > interested in heading down the same path. You copy and paste the failing commandline and add --save-temps, like e.g.: gcc -c -I/home/marcus/projects/wine/dlls/kernel32 -I. -I/home/marcus/projects/wine/include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_NORMALIZE_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -gdwarf-2 -gstrict-dwarf -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -Wall -g -fstack-protector -o console.o /home/marcus/projects/wine/dlls/kernel32/console.c -Og --save-temps it will generate a console.i file in the currenct directory. The console.i file and above commandline are a start for the gcc bug. Ciao, Marcus
Fun with GCC 4.8
As many of you no doubt know, GCC recently released 4.8.0. This new version introduces a new optimization level enabled by -Og with the following description (from the man page): "Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience." Of course I had to try it out. I found that building Wine lead to GCC dieing with ... dlls/kernel32/console.c:1691:1: internal compiler error: Segmentation fault I also found ... dlls/kernel32/computername.c:701:1: internal compiler error: Segmentation fault I eventually stumbled my way into the enclosed patch which lets GCC build Wine with -Og. I'm not sure if this change (or something similar) makes sense for Wine. I'm fairly certain some changes make sense for GCC (I suspect that GCC should not segfault). I haven't submitted a bug for GCC because I suspect they'll want me to provide something simpler to compile than the Wine source tree. I certainly won't be upset if someone beats me too it. I'm not sure how much time in the near future I'll spend on it. "Eventually" is probably the word that fits. At any rate, I wanted to at least share my experiences in case anyone is interested in heading down the same path. -- Jim 0001-Fix-internal-compiler-error-Segmentation-fault-with-.patch Description: Binary data
Re: d3dx9: Implement D3DXSHMultilpy5
On Mon, Apr 15, 2013 at 10:24:28AM +0200, Rico Sch?ller wrote: > You are right. I'm not really sure why the code should be slower though. > The #defines shouldn't have an impact on the performance, but it might > be because it is translated to: > > ta = 0.28209479f * a[0] + -0.12615662f * a[6] + -0.21850968f * a[8]; > tb = 0.28209479f * b[0] + -0.12615662f * b[6] + -0.21850968f * b[8]; > out[1] = 0.0f + ta * b[1] + tb * a[1]; > t = a[1] * b[1]; > out[0] = out[0] + 0.28209479f * t; > out[6] = 0.0f + -0.12615662f * t; > out[8] = 0.0f + -0.21850968f * t; > > instead of: > ta = 0.28209479f * a[0] - 0.12615662f * a[6] - 0.21850968f * a[8]; > tb = 0.28209479f * b[0] - 0.12615662f * b[6] - 0.21850968f * b[8]; > out[1] = ta * b[1] + tb * a[1]; > t = a[1] * b[1]; > out[0] += 0.28209479f * t; > out[6] = -0.12615662f * t; > out[8] = -0.21850968f * t; If everything is 'float' (no doubles anywhere) then I can't see why the above would compile to different code at any sane optimisation level - best to look at the object code. Unless the compiler knows that out[] can't overlap a[] or b[] the generated code is likely to be better if 't' is evaluated before the write to out[1]. David -- David Laight: da...@l8s.co.uk
Re: [PATCH 5/6] ieframe: Return document as IHTMLDocument2 iface from get_document.
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=25085 Your paranoid android. === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2615: Test failed: expected GetOverridesKeyPath webbrowser.c:2620: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2621: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3060: Test failed: doc_disp == NULL webbrowser: unhandled exception c005 at 00402F21
Re: [PATCH 6/6] ieframe: Added DISPID_WINDOWCLOSING tests.
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=25086 Your paranoid android. === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2631: Test failed: expected GetOverridesKeyPath webbrowser.c:2636: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2637: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3076: Test failed: doc_disp == NULL webbrowser: unhandled exception c005 at 00402F21 === WVISTAX64 (64 bit webbrowser) === webbrowser.c:978: Test failed: unexpected dispIdMember 271 webbrowser.c:1604: Test failed: unexpected call TranslateUrl webbrowser.c:454: Test failed: unexpected nCmdID 14 Timeout
Re: [PATCH 1/1] d3d8: Don't assert on invalid IDirect3DBaseTexture8 interfaces.
On 15.04.2013 13:50, Stefan Dösinger wrote:
-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 in wine with uninitialized memory as we do currently,
that's why I think using NULL is the way to go.
Given the circumstances, the patch is probably the correct way to go, yes.
Does the game just do the broken SetTexture call once, or does it
repeatedly try to use the released texture?
Only once, the game does what the attached test tries to do. GetTexture
wont work and may also crash on win.
What happens when you pass an invalid pointer (e.g. (void
*)0xdeadbeef)? What happens when you pass a valid pointer that points
to memory filled with zeros or garbage? If SetTexture does not crash,
what is the return value?
Using deadbeef will crash immediately, you may have luck when deadbeef
points into something valid. The same goes for zeros or garbage values,
but it looks like SetTexture accepts them more likely than the other
approach and won't crash that often. As our internal structure layout
may be different (likely it is) it is like trowing dices to crash here
or there.
Note: The assert as is looks a way too strict, but removing it again
works only till the dsound patch, which obviously overwrites something
we depend on. The game may only work on windows by luck, since this only
happens the first run of the game at all.
Please have a look at http://bugs.winehq.org/show_bug.cgi?id=33055
. Well I think there might be some memory corruption somewhere, but
it doesn't have anything 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/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c
index 2f281d2..1c8992d 100644
--- a/dlls/d3d8/tests/device.c
+++ b/dlls/d3d8/tests/device.c
@@ -4768,6 +4768,105 @@ static void test_rtpatch(void)
DestroyWindow(window);
}
+static void test_InvalidTexture(void)
+{
+IDirect3DDevice8 *device;
+IDirect3D8 *d3d8;
+UINT refcount = 0;
+HWND window;
+HRESULT hr;
+IDirect3DTexture8 *texture = NULL;
+IDirect3DTexture8 *texture2 = NULL;
+DWORD *d;
+
+const struct {
+float x, y, z;
+} quad[] =
+{
+{-1.0f, -1.0f, -0.5f},
+{-1.0f, 1.0f, -0.5f},
+{ 1.0f, -1.0f, 1.5f},
+{ 1.0f, 1.0f, 1.5f},
+};
+
+if (!(d3d8 = pDirect3DCreate8(D3D_SDK_VERSION)))
+{
+skip("Failed to create d3d8 object, skipping tests.\n");
+return;
+}
+
+window = CreateWindowA("d3d8_test_wc", "d3d8_test", WS_OVERLAPPEDWINDOW,
+0, 0, 640, 480, 0, 0, 0, 0);
+if (!(device = create_device(d3d8, window, window, TRUE)))
+{
+skip("Failed to create a D3D device, skipping tests.\n");
+IDirect3D8_Release(d3d8);
+DestroyWindow(window);
+return;
+}
+
+hr = IDirect3DDevice8_SetVertexShader(device, D3DFVF_XYZ);
+
+hr = IDirect3DDevice8_CreateTexture(device, 32, 32, 3, 0, D3DFMT_X8R8G8B8,
D3DPOOL_DEFAULT, &texture2);
+hr = IDirect3DDevice8_CreateTexture(device, 32, 32, 3, 0, D3DFMT_X8R8G8B8,
D3DPOOL_DEFAULT, &texture);
+if (texture && texture2)
+{
+hr = IDirect3DDevice8_SetTexture(device, 0, (IDirect3DBaseTexture8 *)
texture);
+ok(hr == D3D_OK, "SetTexture returned hr %#x.\n", hr);
+
+/* HeapFree all memory */
+hr = IDirect3DDevice8_SetTexture(device, 0, NULL);
+ok(hr == D3D_OK, "SetTexture returned hr %#x.\n", hr);
+IDirect3DTexture8_Release(texture);
+
+/* Test some values - write to released memory / simulate new
heapalloc,
+ * but due to lack of getting the the same address, just write there.
+ * By accident dsound seems do overwrite some values in my system, ...
it may
+ * be also overwritten by something else, that's why the old behaviour
won't
+ * work any more.
+ * Details see bug 33055 */
+d = texture;
+d[0] = 0;
+
+hr = IDirect3DDevice8_SetTexture(device, 0, (IDirect3DBaseTexture8 *)
texture);
+ok(hr == D3D_OK, "SetTexture returned hr %#x.\n", hr);
+
+/*
+{
+IDirect3DTexture8 *texture3 = NULL;
+hr = IDirect3DDevice8_GetTexture(device, 0, (IDirect3DBaseTexture8
**) &texture3);
+ok(hr == D3D_OK, "SetTexture returned hr %#x.\n", hr);
+}*/
+
+/* depending on the value in d[] the crash happens at differen
positions below here */
+hr = IDirect3DDevice8_SetTexture(device, 0, (IDirect3DBaseTexture8 *)
texture2);
+ok(hr == D3D_OK, "SetTextur
Re: GSoC '13 - Hello!
Am 14.04.2013 04:59, schrieb Eric Zheng: > Hello everyone, > > My name is Eric Zheng, I'm a junior in Computer Engineering at the University > of Illinois Urbana-Champaign. I just wanted to introduce myself and state my > interest in the "Xinput / Xbox 360 controller compatibility" project. I hope > to be able to jump on IRC later in the week to speak with you all. Hi Eric, thanks for the interest in Wine. Remember that you can't simply copy&paste the existing patches. You are free to learn from them, but you need to write your own code. Maybe you can find some hints in the wine-devel archive what was wrong with them, so you don't make the same mistakes.
Re: [PATCH 1/1] d3d8: Don't assert on invalid IDirect3DBaseTexture8 interfaces.
-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 in wine with uninitialized memory as we do currently, > that's why I think using NULL is the way to go. Given the circumstances, the patch is probably the correct way to go, yes. Does the game just do the broken SetTexture call once, or does it repeatedly try to use the released texture? What happens when you pass an invalid pointer (e.g. (void *)0xdeadbeef)? What happens when you pass a valid pointer that points to memory filled with zeros or garbage? If SetTexture does not crash, what is the return value? > Please have a look at http://bugs.winehq.org/show_bug.cgi?id=33055 > . Well I think there might be some memory corruption somewhere, but > it doesn't have anything 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. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRa+l9AAoJEN0/YqbEcdMw9qsQAJFvdFH3jGhrVsyII++ART9J etfmFEfsFcw99m1mkPfpUsPqtlk0tiwWJ5OTI6pcoa5zAqh03e9sr83xQYvxyX/J B155EW5CepOMbTKHbedPyS2UXYcdRCFxN0w6wVcWRMap7WTLNPWLC4A7XGFNhkSZ ZIDM7IlDjOntHij74tdxEzx+xs/aZsgaTcfWaxX3IzrHsxOb2gywKI3NcrTg+TNT yQvTq9ac2jeZ4U7nHnASAfg9TYZtIdNygK1DhuHWTx9QEo+Xb+Ik09VR4zYWmCEt EFqxIcNnSqCDqVO9lDigEpUSLBqfpxTBdb6SPnQ6vJhwjO/XTYl3fKWzby3IVgEH wo8p+T7f3n+rnpNocQ7BQlVjwIqyRwsPj6B65xaB9Sxv+zd1hTiPD7diwLh4bveX VEpSXRkfESAOUgnj8HWiRczSb/9GN2m2YCdgiHIyXMDd3TcvNagncK2o5ROC9s3i cN2rdyP7nFYRZzwyn6ttN+gAeFjcK1Ryk37nCF77HkKiFCqE6cqGTYnQxDPH8D2m xaKj36vjswg1Tk6PoZ1CN/isW99psbRHaNcdimW0ExcoboiePD8qMhdFLHZ2a123 Bdbti4zUkUIhGt3VnE7MQyMZ2ivWLSXrbQplFQcViz6gmJB+hm+LJl+ONBRNky1j ADcAEILlJ8JVLXR9EDCV =QLR7 -END PGP SIGNATURE-
Re: [PATCH 1/1] d3d8: Don't assert on invalid IDirect3DBaseTexture8 interfaces.
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 *)&Direct3DCubeTexture8_Vtbl +
&& iface->lpVtbl != (const IDirect3DBaseTexture8Vtbl
*)&Direct3DVolumeTexture8_Vtbl) +{ +WARN("%p is not a
valid IDirect3DBaseTexture8 interface.\n", iface); +return
NULL; +}
A test would be a good idea.
Are you sure that the assert is the actual problem, and not some
memory corruption that changes the vtable poiner? What does e.g.
GetTexture do after a bogous SetTexture call?
Well, the app sets an already released texture. As we access some
members (in this case wined3d_texture) we may get some trouble when the
memory is reused with some other data as we have the guilty memory still
bound somewhere in the pipeline.
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 in wine
with uninitialized memory as we do currently, that's why I think using
NULL is the way to go.
Please have a look at http://bugs.winehq.org/show_bug.cgi?id=33055 .
Well I think there might be some memory corruption somewhere, but it
doesn't have anything to do with the this bug as we use already freed
memory in our implementation.
Cheers
Rico
Re: zlib's gzseek return gabbage and fails intermittently under wine.
--- On Mon, 15/4/13, Nikolay Sivov wrote:
> On 4/15/2013 02:50, Hin-Tak Leung
> wrote:
> > --- On Sun, 14/4/13, Vincent Povirk
> wrote:
> >
> >> Well, here's a simple thing you can
> >> check: Does your zlib dll link to
> >> _lseek or _lseeki64? The first one uses a 32-bit
> offset.
> >> Wine's
> >> implementation (http://source.winehq.org/source/dlls/msvcrt/file.c#L1090)
> >> expands that to 64-bit and later truncates the file
> offset
> >> to 32-bit.
> >> For a file larger than 2 GB, that could account for
> the
> >> large negative
> >> value you're seeing.
> >>
> >> And since this would only matter in cases where
> zlib uses
> >> lseek (the
> >> first time through I guess it wouldn't, as it has
> to read
> >> the whole
> >> everything up to the offset you give at least once)
> and is
> >> at least 2
> >> GB into the file, that might also explain why it
> doesn't
> >> fail
> >> initially.
> >>
> >> But without really digging into the zlib code, all
> I can do
> >> it speculate.
> >>
> >> I should probably also check coapp's build of zlib
> >> sometime.
> > It is not a dll - as you suggested and I already wrote,
> due to past experience of other's packaging of slightly
> outdated, it is being built against a private *source* copy
> of the latest zlib.
> >
> > Also the bogus offset is not large negative but large
> (larger than 2^32) positive.
> >
> > Here is an example of the debug output under wine:
> >
> > ---
> > set_filepos failed at 34307 returning 134127533721091
> > Re-opening to re-try
> > Retry successful
> > set_filepos failed at 96919 returning 146686018157207
> > Re-opening to re-try
> > Retry successful
> > set_filepos failed at 128254 returning 12103217968382
> > Re-opening to re-try
> > Retry successful
> > ...
> > ---
> >
> > This is generated by this code snipplet which is called
> inside a loop, all wrapped in the c++ class:
> >
> > ---
> > off_t offset =
> gzseek(gzvcf_in, filepos, SEEK_SET);
> > if (offset !=
> filepos) { //implicitly converted to off_t by template
> streamoff()
> >
> LOG.printLOG("set_filepos failed at " +
> LOG.streampos2str(filepos)
> >
> + " returning " + LOG.off_t2str(offset) + "\n");
> >
> LOG.printLOG("Re-opening to re-try\n");
> >
> close(); open();
> >
> off_t offset1 = gzseek(gzvcf_in, filepos, SEEK_SET);
> > if
> (offset1 == filepos)
> >
> LOG.printLOG("Retry successful\n");
> >
> else
> >
> LOG.error("Retry failed\n"); // this also aborts
> > }
> >
> > ---
> >
> > This code runs silently on linux i.e. the "if (offset
> != filepos)" condition is not triggered.
> For windows build you'll need to define _WIN32, so _lseeki64
> is used by
> zlib. After this done you could play with
> native msvcrt to see if it helps, and after that +relay will
> tell you
> everything.
$ i686-w64-mingw32-cpp -dM |grep WIN32
#define _WIN32 1
#define __WIN32 1
#define __WIN32__ 1
#define WIN32 1
I haven't explained what the application does earlier, so I'd try to add this
info now. It gzseek's to a set of previously generated offsets (some -
actually all the relevant ones, I think, are beyond 2G in
real/already-compressed data.), gzgets a few bytes, apply a user-selected
criteria on those bytes, make a records of which of those offsets are
"requested", then go back and go over those requested offsets again and gzgets
a much larger chunk. Conceptually it reads the first few columns of a very
large table, use some user defined criteria to select on those, and extract
selected rows.
In the early test (which took most of a full day to run, compared to about 20
minutes on linux), I found that the count of of matched requests was correct,
so the gzgets in the first pass was correct, but the extracted result from the
2nd pass was complete garbage. So my first idea was that the incremental
forward gzseek in the first pass were okay, but the large backward gzseek
between the first pass and the 2nd pass was wrong. Hence my code addition to
check the return value of gzseek, as well as close/re-open to gzseek forward
from the beginning if gzseek return a wrong value - I was only expecting -1 for
failure to rewine.
After the code addition, I found that the return values from even the first
pass are wrong every other time. So it looks like it is two bugs somewhere, and
on 2nd-thought, not necessarily with wine - I think I should try it on window
at some stage.
- I looked at the zlib code itself (it is in a file gzlib.c in 1.2.7 for those
who wants to have a go). It seems that it always converts a seek request into
relative one, do some actual work, then convert back return an absolute offset.
It is possible that there is a bug somewhat in that, so that a fresh gzseek -
having no where to be relative to - is correct, while a 2nd gzseek - after some
flawed conversion to relat
Re: d3dx9: Implement D3DXSHMultilpy5
On 15.04.2013 02:10, Nozomi Kodama wrote: Hello thanks for the review. I don't think that calling defines is the way to go. Indeed, I tested my patch and yours. Yours is about 12% slower than mine in my computer. And now, we try to take care of efficiency of this dll. So, it is not the time to increase latency. You are right. I'm not really sure why the code should be slower though. The #defines shouldn't have an impact on the performance, but it might be because it is translated to: ta = 0.28209479f * a[0] + -0.12615662f * a[6] + -0.21850968f * a[8]; tb = 0.28209479f * b[0] + -0.12615662f * b[6] + -0.21850968f * b[8]; out[1] = 0.0f + ta * b[1] + tb * a[1]; t = a[1] * b[1]; out[0] = out[0] + 0.28209479f * t; out[6] = 0.0f + -0.12615662f * t; out[8] = 0.0f + -0.21850968f * t; instead of: ta = 0.28209479f * a[0] - 0.12615662f * a[6] - 0.21850968f * a[8]; tb = 0.28209479f * b[0] - 0.12615662f * b[6] - 0.21850968f * b[8]; out[1] = ta * b[1] + tb * a[1]; t = a[1] * b[1]; out[0] += 0.28209479f * t; out[6] = -0.12615662f * t; out[8] = -0.21850968f * t; May be due to "out[8] = -0.21850968f * t;" vs "out[8] = 0.0f + -0.21850968f * t;": 1. the extra 0.0f - Shouldn't the 0.0f get optimized away? Imho the macro could be fixed (e.g. use an if / separate macro / don't use a macro for this cases). 2. "+ -0.21850968f * t;" should be as fast as "-0.21850968f * t" isn't it? Does anyone else have an objection about this? I just feel that the code size and the always reused constants could be written a little bit nicer. I'm not sure if the macro usage is really better, it was just a quick idea to avoid that much code duplication. Also changes like the suggested below are really error prone, because they change a lot of code mostly using copy and paste. Though I vote for the same style and precision usage in all cases. Hope this helps a bit Rico I used 10 digits since there are a lot of computation, I want to avoid as much as possible big rounding errors. If we want to uniformize, then we should uniformize d3dxshmultiply 2,3,4 with 10 digits. But that is for an another patch. Nozomi.
Re: [PATCH 1/1] d3d8: Don't assert on invalid IDirect3DBaseTexture8 interfaces.
-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 != (const IDirect3DBaseTexture8Vtbl
> *)&Direct3DVolumeTexture8_Vtbl) +{ +WARN("%p is not a
> valid IDirect3DBaseTexture8 interface.\n", iface); +return
> NULL; +}
A test would be a good idea.
Are you sure that the assert is the actual problem, and not some
memory corruption that changes the vtable poiner? What does e.g.
GetTexture do after a bogous SetTexture call?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRa7lTAAoJEN0/YqbEcdMwNjEP/RLeLk3+009+Cp2n5sWOUprn
Z5ED8iL3RXRjsCJNU5Fi2JIkCcVRmdkkn2RTBN9Q9KEkUL0qjg6B7Admy5sWtMIk
LDtYpjS6BeDIJm8e0D0HwGItv2ekxW37ggg9fsArcXUO/lKf2GrJmUiyAjQfzmT9
IDlewcLSzUiAdbzZ4WUZzkqIa9lQgDpZBAvOgvgqhY2suf+YpJi6oTMfgwzpiSyB
L2mlXx4cb0/hYaPAdWZUbc9uHvsCQ5ZwE4EhIxWpMlZM8FENMN3Gc0vrpzWAXoBo
XRifoh3n0VKaYyZ+Wi+zGRaFX40P4ouBUKuFcBdjEPq6Fhz46GEGY8KFf1MVZKwM
7pzkhv6yc8/GTr2q5wthhmnZxDLHIZNyVEoMU0AFB1M0V/k0sJQfXpCCA/6vql+g
dgUtyPggMSefwT0lc/7S/UwQdvuRYyIcdVd47alDJyRfU5NOMx091IiqkKXm9nby
nqGAfdO3GDQoOIXJpWD5E1UMPHt6AGXGsfypkuVTtTljvOx+U7S9ngBeFkjuor8+
VFwStSFGboPxAjfKqzubdFcPcp4t8E5/qqkXR+Nc2UBJV5XeC3Pg5GOZxBsDZvbz
zU4btX6kgC1Si1vIkf+D8CyZgaoPSwiVgGfVkTaqYSqnO39JZ0SpjYlv7e4yuhfa
jkXNYd+XevrLq435YYir
=TVml
-END PGP SIGNATURE-
