On 07/05/2010 07:38 PM, Ken Sharp wrote:
>
>
Hi Ken,
This is what I get when applying the patch:
patching file dlls/mapi32/Ga.rc
patching file dlls/mapi32/Makefile.in
Hunk #1 FAILED at 19.
1 out of 1 hunk FAILED -- saving rejects to file dlls/mapi32/Makefile.in.rej
Is your Git up-to-date (I'm not seeing Hu.rc in your patchfile for
example and that was added 2 weeks ago).
--
Cheers,
Paul.
On 5 July 2010 20:47, Bjørnar Hansen <tilbjornar(a)gmail.com> wrote:
> This adds a test of the surface format conversion implemented in
> wined3d/surface_base.c.
>
You're supposed to call IDirect3D9_CheckDeviceFormatConversion() to
determine which conversions are supported.
Misha wrote:
> This assumes that one downloads the DirectX SDK June 2010 version from:
> http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=302…
I have a winetricks verb dxsdk_nov2006 (I wanted to get a pure directx
9 version),
does that do as well for you? If not, send a patch for winetricks to
add the new sdk...
Yeah, this is the correct fix for this horribly broken API (did quite
a bit of xinput hacking recently). There is no call to query what
joysticks are available since the API was designed to allow you to
plug in a joystick while you are playing a game. Games just use
XInputGetState (which retrieves the state of axis/buttons) all the
time to poll whether a user plugged in a joystick.
We might want to have something similar in XInputGetKeystroke /
XInputGetCapabilities later on if games still use them (not all calls
are exported in all xinput versions).
Roderick
On Mon, Jul 5, 2010 at 3:42 PM, Louis Lenders
<xerox_xerox2000(a)yahoo.co.uk> wrote:
> this one gets spawned a few times per second thus flooding the console, running the Resident Evil BenchMark
>
>
>
>
>
>
>
I tried a lot of things, and I couldn't get these tests working on this box(gf9600,win7 x86). d3drs_clipping doesn't do what the test expects, in either d3d version. If anyone knows what's wrong feel free to bring up a better solution.
I also can't get pop3d working on this system to see if the game that needed the original clipping hack. renders properly.
If I had to guess the Nv driver probably runs things through some d3d9->d3d10 mapper provided by ms. That could explain why nv d3d10 setups fail but d3d9 ones work.
Wrt ddraw/d3d8, I'd prefer to get the d3d9 testsuite working on my box first. Currently I get thousands of test failures, making development of new bugfixes pretty much impossible. I'll take care of ddraw/d3d8 too, but first i want to regain the ability to write new tests.
Henri Verbeet <hverbeet(a)gmail.com> schrieb:
>I'm not sure blindly marking these as broken is the way to go. Either
>way, ddraw and d3d8 have the same failure.
>
I'd love to have yagmark be more internationalized.
I did try to use button codes rather than english
strings in wisotool, but sometimes it wasn't possible, and
sometimes I didn't try hard enough. Not sure if I
tried at all in yagmark yet.
According to
http://www.autohotkey.com/docs/commands/SetTitleMatchMode.htm
Autohotkey supports regular expressions, so for the matching
strings that can't be changed to button codes,
we could list a bunch of alternatives, e.g. Save As|Enregistrer Sous
Then the remaining mess is when we have to send a
keystroke, we might need a switch statement to decide
which keystroke to send based on the language.
For the purposes of benchmarking wine, just setting
LANG=en_US.UTF-8 solves the problem, but that
doesn't help when you're trying to benchmark Windows.
- Dan
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=3159
Your paranoid android.
=== W98SE (32 bit ordinal) ===
Timeout
=== W2KPROSP4 (32 bit ordinal) ===
ordinal.c:594: Test failed: GetShellSecurityDescriptor should fail
ordinal.c:617: Test failed: returned value is not valid SD
No test summary line found
=== W7PRO (32 bit ordinal) ===
ordinal.c:1760: Test failed: got 12
ordinal.c:1781: Test failed: got 9
ordinal.c:1794: Test failed: got 12
ordinal.c:1802: Test failed: got 12
ordinal.c:1832: Test failed: got 36, length 37
ordinal.c:1843: Test failed: got 39
ordinal.c:1854: Test failed: got 21
ordinal.c:1865: Test failed: got 24
=== W7PROX64 (64 bit ordinal) ===
ordinal.c:1760: Test failed: got 10
ordinal.c:1766: Test failed: got 23
ordinal.c:1781: Test failed: got 7
ordinal.c:1794: Test failed: got 10
ordinal.c:1802: Test failed: got 10
ordinal.c:1816: Test failed: got 23
ordinal.c:1824: Test failed: got 23
ordinal.c:1854: Test failed: got 19
ordinal.c:1865: Test failed: got 22
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=3158
Your paranoid android.
=== W98SE (32 bit ordinal) ===
ordinal.c:2391: Test failed: got 00000000
ordinal.c:2395: Test failed: got 1010
ordinal.c:2396: Test failed: got 00000000
Timeout
=== W2KPROSP4 (32 bit ordinal) ===
ordinal.c:594: Test failed: GetShellSecurityDescriptor should fail
ordinal.c:617: Test failed: returned value is not valid SD
No test summary line found
=== W2K8SE (32 bit ordinal) ===
ordinal.c:2391: Test failed: got 00000000
ordinal.c:2395: Test failed: got 6
ordinal.c:2396: Test failed: got 00000000
=== W7PRO (32 bit ordinal) ===
ordinal.c:1760: Test failed: got 12
ordinal.c:1781: Test failed: got 9
ordinal.c:1794: Test failed: got 12
ordinal.c:1802: Test failed: got 12
ordinal.c:1832: Test failed: got 36, length 37
ordinal.c:1843: Test failed: got 39
ordinal.c:1854: Test failed: got 21
ordinal.c:1865: Test failed: got 24
ordinal.c:2391: Test failed: got 00000000
ordinal.c:2395: Test failed: got 6
ordinal.c:2396: Test failed: got 00000000
=== W7PROX64 (32 bit ordinal) ===
ordinal.c:2391: Test failed: got 00000000
ordinal.c:2395: Test failed: got 6
ordinal.c:2396: Test failed: got 00000000
=== W7PROX64 (64 bit ordinal) ===
ordinal.c:1760: Test failed: got 10
ordinal.c:1766: Test failed: got 23
ordinal.c:1781: Test failed: got 7
ordinal.c:1794: Test failed: got 10
ordinal.c:1802: Test failed: got 10
ordinal.c:1816: Test failed: got 23
ordinal.c:1824: Test failed: got 23
ordinal.c:1854: Test failed: got 19
ordinal.c:1865: Test failed: got 22
ordinal.c:2391: Test failed: got 0000000000000000
ordinal.c:2395: Test failed: got 6
ordinal.c:2396: Test failed: got 0000000000000000
> I don't know about the 'respectability' of SF, but I'm more concerned with the content and who gets to change it. There are folks that may decide to enter incorrect or even bogus information. I would like it if all added information that is not already present in the Wine API be vetted. That means one person enters it and another disassociated person verifies before it goes live. Code already in the API should be considered automatically vetted.
I think the speed and freedom provided by wiki is more important than
vetting. Most problems would be due to vandalism (easily reverted),
people will keep an eye on Recent Changes. If the problem is
overwhelming, we will make editing privileges require a grant by an
admin on a shall issue basis. Bogus information is a non-issue, people
with sufficient knowledge to enter convincing information are not
going to be the sort to enter bogus information. Wikipedia has a high
level of accuracy despite its openness.
Peter