Re: winex11.drv: Fix buffer overflow bug in X11DRV_KeyEvent() andX11DRV_ToUnicodeEx()
"Muneyuki Noguchi" <[EMAIL PROTECTED]> wrote:
> winex11.drv: Fix buffer overflow bug in X11DRV_KeyEvent() and
> X11DRV_ToUnicodeEx()
> +Str = (char *)malloc(64);
> +if (Str == NULL)
> +ERR("Failed to allocate memory!\n");
Please don't use malloc() in Wine, use win32 Heap*** APIs instead.
Also, you need to properly handle memory allocation errors, not just
print an ERR.
--
Dmitry.
Re: kernel32/winerr: Add Russian translation
"Vladimir Pankratov" <[EMAIL PROTECTED]> wrote: > Added Russian translation. > > Changed files: > dlls/kernel32/nls/winerr_rus.mc > dlls/kernel32/kernel.rc > dlls/kernel32/Makefile.in Is there a reason you've used cp866 encoding instead of cp1251? Also, this doesn't look like a translation, messages don't match their english counterparts, how did you do that? -- Dmitry.
RE: [10/10] WineD3D: Sort out some limit confusion
> 2008/8/22 Stefan Dösinger <[EMAIL PROTECTED]>:
> > +glGetIntegerv(GL_MAX_TEXTURE_COORDS, &gl_max);
> > +gl_info->max_texture_coords = min(MAX_TEXTURES, gl_max);
> > +TRACE_(d3d_caps)("Max texture coords: %d\n", gl_info-
> >max_texture_coords);
> I don't know if this is intentional or not, but did you mean to use
> gl_info->max_textures here?
No, I meant to clamp it by the constant MAX_TEXTURES(=8). gl_info->max_textures
is wrong here because gl_info->max_textures could be 4, GL_MAX_TEXTURE_COORDS
could be 8. If the application uses fixed function vertex processing and pixel
shaders it can make use of all 8 texture coords in the vertex pipeline even
though the fixed function fragment pipeline supports only 4 textures. Or we
could use the arbfp code which isn't limited by gl_info->max_textures.
> > @@ -3172,7 +3172,7 @@ static void
> loadTexCoords(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertex
> > return;
> > }
> >
> > -for (textureNo = 0; textureNo < GL_LIMITS(texture_stages);
> ++textureNo) {
> > +for (textureNo = 0; textureNo < GL_LIMITS(texture_coords);
> ++textureNo) {
> > int coordIdx = stateblock-
> >textureState[textureNo][WINED3DTSS_TEXCOORDINDEX];
> >
> > mapped_stage = stateblock->wineD3DDevice-
> >texUnitMap[textureNo];
> Shouldn't that be testing mapped_stage against
> GL_LIMITS(texture_coords) instead?
You mean instead of textureNo? I don't think so. A stage is always mapped to a
lower one, so I think we cannot trigger an error here. Dealing with all
supported texture units here spares the loop below.
> > -if (GL_SUPPORT(NV_REGISTER_COMBINERS)) {
> > -/* The number of the mapped stages increases monotonically,
> so it's fine to use the last used one */
> > -for (textureNo = mapped_stage + 1; textureNo <
> GL_LIMITS(textures); ++textureNo) {
> > -GL_EXTCALL(glMultiTexCoord4fARB(GL_TEXTURE0_ARB +
> textureNo, 0, 0, 0, 1));
> > -}
> > -}
> I'm probably missing something here, but why is it safe to remove that?
Because we have handled all supported texture units in the loop above. and
supplied it with default coordinates if needed.
> In the bigger picture, these various limits are pretty tricky to get
> right, I wonder if it might make more sense to handle most of this
> stuff in the tex unit map instead. That way we could be sure that if a
> stage is mapped to a sampler that sampler is safe to use.
While this sounds nice I am afraid it won't work too well. Beyond specifying
the new settings we have to do other things like unsetting unneeded states,
etc, so I don't think we can keep the state mappings all in one place. My other
concern is that different pipeline implementations need different limits.
RE: Using wine directdraw dll on windows?
> Intel's windows vista graphics drivers are pretty terrible, and some > older directdraw games won't run at all with them. I know that there > was > talk before about using wine's opengl-based direct3d implementation on > windows, so I was curious if it was at all possible to do the same with > directdraw. Ironically Worms Armageddon runs better on my laptop under > wine than it does on my gf's under Vista. Our d3d implementation works pretty well on Windows(well, as good as it does on Wine), with the exception of directdraw. The problem with ddraw is that ddraw.dll needs wined3d.dll, which loads opengl32.dll, and Microsoft's opengl32.dll loads ddraw.dll. Oops. Currently we have no real attacking point to this issue.
Re: About patchwatcher
On Sat, Aug 23, 2008 at 2:14 PM, Nikolay Sivov <[EMAIL PROTECTED]> wrote: > Dan, am I right that Patchwatcher now runs a whole test suite for every > patch? Yes. > I know that this situation is rather rare but still I think it make sense to > run only tests changed by patch if this patch contains only > test changes. I could save some time without any side effect. That's a fine idea. It could come in handy when we start valgrinding everything. As you say, though, it's rare, so it might be a while before it's a high priority. - Dan
Re: [1/2] wined3d: Support clipplanes with GLSL shaders
> @@ -248,11 +248,12 @@ typedef struct {
> void (*shader_generate_vshader)(IWineD3DVertexShader *iface,
> SHADER_BUFFER *buffer);
> void (*shader_get_caps)(WINED3DDEVTYPE devtype, WineD3D_GL_Info
> *gl_info, struct shader_caps *caps);
> BOOL (*shader_conv_supported)(WINED3DFORMAT conv);
> +DWORD shader_supported_clipplanes; /* bitmask of supported clipplanes */
> } shader_backend_t;
You shouldn't abuse the call table like that, you should store that
flag in the private data instead.
About patchwatcher
Dan, am I right that Patchwatcher now runs a whole test suite for every patch? I know that this situation is rather rare but still I think it make sense to run only tests changed by patch if this patch contains only test changes. I could save some time without any side effect. Since all test stored in 'tests' directory for each module it's very easy to determine that a patch brings changes only to this directory without affecting module itself. What you think about this?
Re: Patchwatcher: failed regression tests: d3dx8: replace loops with explicit computations to make them faster [PATCH] d3dx8: replace loops by explicit computations
You can't just declare a patch series for the last patch, as you seem to have done here: d3dx8, test [patch 3/3] test the relative error instead of the absolute one to avoid rounded errors That confuses patchwatcher (and maybe even humans). That patch should have come first, to avoid having the tree in broken state. - Dan On Sat, Aug 23, 2008 at 5:05 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > Patchwatcher notes that the conformance test fails here: > > ../../../tools/runtest -q -P wine -M d3dx8.dll -T ../../.. -p > d3dx8_test.exe.so math.c && touch math.ok > math.c:442: Test failed: Expected matrix= > (-0.214800,1.311600,0.475200,0.00 > 0.950400,-0.883600,0.924400,0.00 > 1.021200,0.193600,-1.358800,0.00 > 18.298500,-29.624001,15.683499,1.00 > ) > > Got matrix= > (-0.214800,1.311600,0.475200,0.00 > 0.950401,-0.883601,0.924400,0.00 > 1.021204,0.193593,-1.358803,0.00 > 18.298538,-29.624159,15.683425,1.00) > > Looks like rounding errors, but one way or another, you have to take > care of that. > > Also: did you benchmark this change to verify it actually made > things faster? Unrolling loops is no longer as sure-fire a win as > it used to be. I'm inclined to prefer the more compact, clear > loop unless there's hard evidence it's > 1% slower. > - Dan > > > -- Forwarded message -- > From: <[EMAIL PROTECTED]> > Date: Fri, Aug 22, 2008 at 8:35 PM > Subject: Patchwatcher: failed regression tests: d3dx8: replace loops > with explicit computations to make them faster [PATCH] d3dx8: replace > loops by explicit computations > To: [EMAIL PROTECTED] > > > Hi! This is the experimental automated wine patchwatcher thingy. > The latest git sources were built and tested with your patch > "d3dx8: replace loops with explicit computations to make them faster > [PATCH] d3dx8: replace loops by explicit computations" > Result: the patch failed regression tests. > > You can retrieve the full build results at > http://kegel.com/wine/patchwatcher/results/264.log > and see the patch as parsed at > http://kegel.com/wine/patchwatcher/results/264.txt > See > http://kegel.com/wine/patchwatcher/results > for more info. >
Re: wined3d/d3d9: Set the initial scissor rect to the window size
2008/8/23 Stefan Dösinger <[EMAIL PROTECTED]>:
> Does "WINED3DSURFACE_DESC desc = {0};" set all the pointers in
> WINED3DSURFACEDESC to NULL? I am not sure about this. (At some point we may
> also want to de-pointerize WINED3DSURFACEDESC like we've done with the other
> structures)
>
It initializes the struct with zeroes.
RE: wined3d/d3d9: Set the initial scissor rect to the window size
I think you don't have to test a 2nd swapchain here. The initial scissor
rectangle is set in CreateDevice, so an extra call to CreateAdditionalSwapchain
afterwards shouldn't have any effect on this. I am mainly concerned by the open
source drivers here which do not always like messing with OpenGL contexts too
much. I am afraid we'll get complaints that the test crashes or even causes a
kernel panic :-/.
Does "WINED3DSURFACE_DESC desc = {0};" set all the pointers in
WINED3DSURFACEDESC to NULL? I am not sure about this. (At some point we may
also want to de-pointerize WINED3DSURFACEDESC like we've done with the other
structures)
ddraw_test crashes on windows xp sp3 (blue screen)
Hi, the attached patch solves a hard crash on my ati mobility 9600/9700 card. The code behind the c style comments let the application crash. The code between /* */ crash the hole system. Probably there have to be another check for supported cards/extensions. Cheers Rico diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c index 221a95b..436a49c 100644 --- a/dlls/ddraw/tests/d3d.c +++ b/dlls/ddraw/tests/d3d.c @@ -2089,9 +2089,9 @@ static void DeviceLoadTest() ddsd.ddsCaps.dwCaps2 = DDSCAPS2_CUBEMAP | DDSCAPS2_CUBEMAP_POSITIVEX; ddsd.dwWidth = 128; ddsd.dwHeight = 128; -hr = IDirectDraw7_CreateSurface(lpDD, &ddsd, &cube_face_levels[0][0][0], NULL); -ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); -if (FAILED(hr)) goto out; +//hr = IDirectDraw7_CreateSurface(lpDD, &ddsd, &cube_face_levels[0][0][0], NULL); +//ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); +//if (FAILED(hr)) goto out; memset(&ddsd, 0, sizeof(DDSURFACEDESC2)); ddsd.dwSize = sizeof(ddsd); @@ -2100,13 +2100,13 @@ static void DeviceLoadTest() ddsd.ddsCaps.dwCaps2 = DDSCAPS2_CUBEMAP | DDSCAPS2_CUBEMAP_POSITIVEX | DDSCAPS2_CUBEMAP_POSITIVEY; ddsd.dwWidth = 128; ddsd.dwHeight = 128; -hr = IDirectDraw7_CreateSurface(lpDD, &ddsd, &cube_face_levels[1][0][0], NULL); -ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); -if (FAILED(hr)) goto out; +//hr = IDirectDraw7_CreateSurface(lpDD, &ddsd, &cube_face_levels[1][0][0], NULL); +//ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); +//if (FAILED(hr)) goto out; /* INVALIDPARAMS tests currently would fail because wine doesn't support partial cube faces (the above created cubemaps will have all faces. */ -hr = IDirect3DDevice7_Load(lpD3DDevice, cube_face_levels[0][0][0], NULL, cube_face_levels[1][0][0], NULL, +/*hr = IDirect3DDevice7_Load(lpD3DDevice, cube_face_levels[0][0][0], NULL, cube_face_levels[1][0][0], NULL, DDSCAPS2_CUBEMAP_ALLFACES); todo_wine ok(hr==DDERR_INVALIDPARAMS, "IDirect3DDevice7_Load returned: %x\n",hr); @@ -2132,6 +2132,7 @@ static void DeviceLoadTest() IDirectDrawSurface7_Release(cube_face_levels[0][0][0]); IDirectDrawSurface7_Release(cube_face_levels[1][0][0]); +*/ memset(cube_face_levels, 0, sizeof(cube_face_levels)); }
Using wine directdraw dll on windows?
Intel's windows vista graphics drivers are pretty terrible, and some older directdraw games won't run at all with them. I know that there was talk before about using wine's opengl-based direct3d implementation on windows, so I was curious if it was at all possible to do the same with directdraw. Ironically Worms Armageddon runs better on my laptop under wine than it does on my gf's under Vista. Thanks, Joe
Re: [Patch] 0001-Support-for-winscard.dll.patch
Am Samstag, 23. August 2008 18:06:20 schrieb Dan Kegel: [snip] > > Okay. Shall I offer a new patch? How to do this then? Is this the only > > problem with the patch (syntactically)? To mention ... I am a git rookie > > ... > > The subject line should have said something like > winscard: implement first few functions > When you repost after improving a patch, append (try 2) to the subject, > e.g. winscard: implement first few functions (try 2) > > but I would include a couple tests when you resend; mark > them with todo_wine if they don't pass yet on Wine. > - Dan That will take some time since I just had a look at the pcsc-lite stuff ... and its completely missing the information I need in the CCID driver code. So for the special USB smartcard reader in use by me I have to ask the vendor how to retrieve the information ... or otherwise reverse engineer it by sniffing USB while getting these information. Heiko
Re: [Patch] 0001-Support-for-winscard.dll.patch
On Sat, Aug 23, 2008 at 8:45 AM, frechdachs69 <[EMAIL PROTECTED]> > I am trying to prepare the winscard.dll stuff for an application written by > me. Probably I can extract some smartcard-using code (after my application > works) as a conformance test. It's a common misconception that tests should be written after the code. In Wine, it's best to write them *before* the code, and get the tests working on Windows. You can even submit the tests first before even starting on the code. Incremental development - improve the tests a bit, then fix the code to pass the tests - is a good way to go. Initial tests can be really trivial, just checking superficial error behavior. See also http://en.wikipedia.org/wiki/Test-driven_development Believe it or not, this makes development go faster! > The first task to make my application run is being able to list the smartcard > readers attached to the system. So far I only get the name of the smartcard > reader. But I also need vendor, user friendly name, serial number, model and > whether a smartcard is present. Still missing ... > This may be due to my patch or to things missing in or not understood in > pcsc-lite - not clear so far. That's good to know. Next time you submit the patch, include a three-line summary of the above, say. Also mention which functions you're improving, and how complete they are. > Okay. Shall I offer a new patch? How to do this then? Is this the only problem > with the patch (syntactically)? To mention ... I am a git rookie ... The subject line should have said something like winscard: implement first few functions When you repost after improving a patch, append (try 2) to the subject, e.g. winscard: implement first few functions (try 2) but I would include a couple tests when you resend; mark them with todo_wine if they don't pass yet on Wine. - Dan
Re: [Patch] 0001-Support-for-winscard.dll.patch
Am Samstag, 23. August 2008 16:50:46 schrieb Dan Kegel: > Heiko wrote: > > This is my first patch using git and also for wine. > > > > Please check it and let me know which things can be made better. > > Hi! Welcome to Wine! > > You probably need to include a better description, > and some conformance tests would help, too. As a first description: I am starting with winscard.dll support. I started with this change about two months ago but got distracted from further studying it so I have thought it might be better to offer the so far done stuff - to avoid getting it lost in the flow of time. I am trying to prepare the winscard.dll stuff for an application written by me. Probably I can extract some smartcard-using code (after my application works) as a conformance test. The first task to make my application run is being able to list the smartcard readers attached to the system. So far I only get the name of the smartcard reader. But I also need vendor, user friendly name, serial number, model and whether a smartcard is present. Still missing ... This may be due to my patch or to things missing in or not understood in pcsc-lite - not clear so far. > (They should do basic error checking at least, > and should skip checks that really need hardware > if the required hardware isn't present.) > > Also, your patch failed to apply; see > http://kegel.com/wine/patchwatcher/results/ > > You can avoid the particular problem by not including a diff for > 'configure' in the patch; the diff for configure.ac suffices. Okay. Shall I offer a new patch? How to do this then? Is this the only problem with the patch (syntactically)? To mention ... I am a git rookie ... > > We have lots of pages (way too many) of advice for how to send > patches at winehq.org, but that bit of advice doesn't seem to > be in any of them yet :-( > http://www.winehq.org/site/sending_patches > http://wiki.winehq.org/DeveloperFaq > http://winehq.org/site/docs/winedev-guide/codingpractice > > It does show up in > http://wiki.jswindle.com/index.php/Coding_Hints:Using_Diff > I am going to have a more thorough look into the links. > - Dan Thanks for your feedback. Heiko
Re: Patchwatcher: failed regression tests: d3dx8: replace loops with explicit computations to make them faster [PATCH] d3dx8: replace loops by explicit computations
On Sat, Aug 23, 2008 at 8:05 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > Patchwatcher notes that the conformance test fails here: > Also: did you benchmark this change to verify it actually made > things faster? Unrolling loops is no longer as sure-fire a win as > it used to be. I'm inclined to prefer the more compact, clear > loop unless there's hard evidence it's > 1% slower. > - Dan > I'de bet good money that GCC already unrolled those loops with -O2 and greater. I do agree with Dan though that doing a test on a standard intel core machine and a k8 machine to see what reality looks like is best.
Re: [Patch] 0001-Support-for-winscard.dll.patch
On Sat, Aug 23, 2008 at 7:50 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: > You can avoid the particular problem by not including a diff for 'configure' > in the patch; the diff for configure.ac suffices. > > We have lots of pages (way too many) of advice for how to send > patches at winehq.org, but that bit of advice doesn't seem to > be in any of them yet :-( > http://www.winehq.org/site/sending_patches > http://wiki.winehq.org/DeveloperFaq > http://winehq.org/site/docs/winedev-guide/codingpractice > > It does show up in > http://wiki.jswindle.com/index.php/Coding_Hints:Using_Diff and somewhat in http://wiki.winehq.org/Developers-Hints#head-30a7f7f51ce0e42b4141749c9832bae9f7957260
Re: winetricks: add ie6 verb
On Mo, 2008-08-18 at 13:11 -0400, Steven Edwards wrote:
> +load_ie6() {
Nice Idea.
> +# Installing Core Fonts"
> +load_corefonts
Which Font is required (please fill bug reports)
Which Font is optional?
> +# Installing Richedit 2.0 Library"
> +load_riched20
What is needed in the builtin version?
Please fill bug reports.
> +# Installing Richedit 3.0 Library"
> +load_riched30
> +# Installing Microsoft Line Services"
> +load_msls31
Hm. Not present in Wine yet.
> +
> +# Change the override to the native so we are sure we use and
> register them
> +override_dlls native,builtin
> itircl itss mlang msimtf riched20 riched32 shdoclc shlwapi urlmon
Do you need the override for Installation or for running IE6?
What is needed in the builtin versions?
Please fill bug reports.
> +# Remove the fake dlls from the existing WINEPREFIX
> +mv $WINEPREFIX/drive_c/"Program Files"/"Internet
> Explorer"/iexplore.exe $WINEPREFIX/drive_c/"Program Files"/"Internet
> Explorer"/iexplore.exe.bak
That's wrong for every Language != english.
What you need is already there: "$programfilesdir_unix"
> +# Work around DLL registration bug
> +cd $WINEPREFIX/drive_c/windows/system32/
> +for i in *.dll *.ocx; do regsvr32 /i $i; done
Which dll/ocx need this?
Is this a Wine bug (please fill bug reports) or an IE bug?
For most files in this directory, your code is wrong.
Your code depends on the case of the extensions.
--
By by ... Detlef
re: [Patch] 0001-Support-for-winscard.dll.patch
Heiko wrote: > This is my first patch using git and also for wine. > > Please check it and let me know which things can be made better. Hi! Welcome to Wine! You probably need to include a better description, and some conformance tests would help, too. (They should do basic error checking at least, and should skip checks that really need hardware if the required hardware isn't present.) Also, your patch failed to apply; see http://kegel.com/wine/patchwatcher/results/ You can avoid the particular problem by not including a diff for 'configure' in the patch; the diff for configure.ac suffices. We have lots of pages (way too many) of advice for how to send patches at winehq.org, but that bit of advice doesn't seem to be in any of them yet :-( http://www.winehq.org/site/sending_patches http://wiki.winehq.org/DeveloperFaq http://winehq.org/site/docs/winedev-guide/codingpractice It does show up in http://wiki.jswindle.com/index.php/Coding_Hints:Using_Diff - Dan
Re: Spore patch to fix UI and Part descriptions
Andrew Fenn schrieb:
> I'm alittle confused, are you suggesting that if SetScissorRect
> receives a null value that if should default to the window size? or do
> you mean that perhaps GetScissorRect should call SetScissorRect and
> return a correct value instead of null?
>
No. {0,0,0,0} is a valid scissorrect. You could set it and get it. It is
valid. Wines default scissorect is wrong, it has to be the size of the
first swapchains backbuffer. I have a patch for this one. I'll send it
later today.
> If I understand you correctly it sounds like another problem and I
> think that checking should still be done on SetScissorRect as
> currently there is no checking being done where as the documentation
> states that D3DERR_INVALIDCALL is returned if SetScissorRect gets an
> invalid or null rectangle.
>
Probably, checking should be done for invalid scissorrect values.
> I'm currently rewriting the tests and patch so I'll let you know when I am
> done.
>
> PS: I just looked at wine's implementation of GetScissorRect and it
> looks wrong as well. It should be returning D3DERR_INVALIDCALL if
> there is no value and perhaps maybe if scissor test hasn't been
> enabled.
There is always a scissorrect value! I don't know if there is a chance
to get a D3DERR_INVALIDCALL from the GetScissorRect-function.
Cheers
Rico
New winetricks 20080823: add non-activex-plugin for flash, work around indeo installer bug; updated divx, liberation, kdewin, directx9, ffdshow.
Just a bunch of little updates and fixes. Thanks to everyone who pointed out the issues. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com Changes since 20080710: r164: divx updated, change path and sha1sum to match. Thanks to Graham Inggs for the nudge. r163: Update liberation to 1.04. Thanks to Graham Inggs for the nudge. Uses the probably-gnu-specific --strip option to tar to get the fonts in the right place... but everybody's using gnu tar 1.15 or later, right? r162: Update kdewin to 0.9.3-1. Thanks to Graham Inggs for the nudge. r161: Register indeo codec harder; thanks to 414N for the tip. r112: Update directx9 to june 2008 release; thanks to Paul Drain for the tip. r111: Add non-activex flash plugin r110: Update ffdshow. Update version. r107: Add a little error checking, and missing quotes in one spot.
Re: Crosstest building question
Stefan Leichter wrote: > Am Saturday 23 August 2008 15:28 schrieb Nikolay Sivov: > >> I have a problem building crosstest for GDI+ call GdipFillClosedCurve2. >> >> I've got the following: >> >> graphics.cross.o: In function >> `func_graphics':/home/mrlarch/wine/dlls/gdiplus/tests/graphics.c:593: >> undefined reference to [EMAIL PROTECTED]' >> collect2: ld returned 1 exit status >> make[2]: *** [gdiplus_crosstest.exe] Error 1 >> make[2]: Leaving directory `/home/mrlarch/wine/dlls/gdiplus/tests' >> make[1]: *** [gdiplus/tests/__crosstest__] Error 2 >> make[1]: Leaving directory `/home/mrlarch/wine/dlls' >> make: *** [dlls/__crosstest__] Error 2 >> >> This never happened with other calls yet. >> >> Before this I've done 'make && make install' for library and make clean >> for 'tests' directory. >> Actually in definition file I have now -- [EMAIL PROTECTED] @216. >> I'm able to build ordinary (not cross) tests without any errors. >> >> I think the question is why reference name differs from .def file? >> > > Looks like there is an error in dlls/gdiplus/gdiplus.spec > You have to change the two line like listed below. > > @ stdcall GdipFillClosedCurve2(ptr ptr ptr long long long) > @ stdcall GdipFillClosedCurve2I(ptr ptr ptr long long long) > > Bye Stefan > > Thanks. Of course it is. I've looked twice at it and didn't spot. Thanks again.
Re: Crosstest building question
Am Saturday 23 August 2008 15:28 schrieb Nikolay Sivov: > I have a problem building crosstest for GDI+ call GdipFillClosedCurve2. > > I've got the following: > > graphics.cross.o: In function > `func_graphics':/home/mrlarch/wine/dlls/gdiplus/tests/graphics.c:593: > undefined reference to [EMAIL PROTECTED]' > collect2: ld returned 1 exit status > make[2]: *** [gdiplus_crosstest.exe] Error 1 > make[2]: Leaving directory `/home/mrlarch/wine/dlls/gdiplus/tests' > make[1]: *** [gdiplus/tests/__crosstest__] Error 2 > make[1]: Leaving directory `/home/mrlarch/wine/dlls' > make: *** [dlls/__crosstest__] Error 2 > > This never happened with other calls yet. > > Before this I've done 'make && make install' for library and make clean > for 'tests' directory. > Actually in definition file I have now -- [EMAIL PROTECTED] @216. > I'm able to build ordinary (not cross) tests without any errors. > > I think the question is why reference name differs from .def file? Looks like there is an error in dlls/gdiplus/gdiplus.spec You have to change the two line like listed below. @ stdcall GdipFillClosedCurve2(ptr ptr ptr long long long) @ stdcall GdipFillClosedCurve2I(ptr ptr ptr long long long) Bye Stefan
Crosstest building question
I have a problem building crosstest for GDI+ call GdipFillClosedCurve2. I've got the following: graphics.cross.o: In function `func_graphics':/home/mrlarch/wine/dlls/gdiplus/tests/graphics.c:593: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [gdiplus_crosstest.exe] Error 1 make[2]: Leaving directory `/home/mrlarch/wine/dlls/gdiplus/tests' make[1]: *** [gdiplus/tests/__crosstest__] Error 2 make[1]: Leaving directory `/home/mrlarch/wine/dlls' make: *** [dlls/__crosstest__] Error 2 This never happened with other calls yet. Before this I've done 'make && make install' for library and make clean for 'tests' directory. Actually in definition file I have now -- [EMAIL PROTECTED] @216. I'm able to build ordinary (not cross) tests without any errors. I think the question is why reference name differs from .def file?
Re: Spore patch to fix UI and Part descriptions
I'm alittle confused, are you suggesting that if SetScissorRect
receives a null value that if should default to the window size? or do
you mean that perhaps GetScissorRect should call SetScissorRect and
return a correct value instead of null?
If I understand you correctly it sounds like another problem and I
think that checking should still be done on SetScissorRect as
currently there is no checking being done where as the documentation
states that D3DERR_INVALIDCALL is returned if SetScissorRect gets an
invalid or null rectangle.
I'm currently rewriting the tests and patch so I'll let you know when I am done.
PS: I just looked at wine's implementation of GetScissorRect and it
looks wrong as well. It should be returning D3DERR_INVALIDCALL if
there is no value and perhaps maybe if scissor test hasn't been
enabled.
On Sat, Aug 23, 2008 at 1:46 AM, Rico Schüller <[EMAIL PROTECTED]> wrote:
> Andrew Fenn schrieb:
>> I made a new patch this time including a test.
>>
>> I put in some extra checking in SetScissorRect making sure that if
>> rect was null or it was an invalid rectangle that it was returned as
>> invalid as it should be.
>>
>> I'm not able to do a test on windows so if anyone does one please let
>> me know if there are any problems. Also please tell me if you spot any
>> problems with this patch.
>>
>> Thanks,
>> Andrew
>>
>>
>>
>> +RECT rect = {0, 0, 0, 0};
>> +hr = IDirect3DDevice9_SetScissorRect(device, &rect);
>> +ok(hr == D3DERR_INVALIDCALL, "Expected D3DERR_INVALIDCALL, got %08x\n",
>> hr);
> Sorry that I led you in the wrong direction but these tests didn't pass
> on windows! Also please read the comment to the bug, where I attached my
> patch. My suggestion which I made there isn't true! The real background
> is that wine sets the default scissor rect to {0,0,0,0} but on windows
> it is set to another size, I have written a patch for that, but it looks
> like there is something incomplete (see
> http://www.winehq.org/pipermail/wine-patches/2008-August/059891.html ).
> When the game is starting it retrieves the initial value with
> GetScissorRect which is in wine the null-rect. And so nothing is
> rendered to the screen.
>
> Cheers
> Rico
>
>
>
Re: wined3d/d3d9: Set the initial scissor rect to the window size
Henri Verbeet schrieb: > 2008/8/23 Rico Schüller <[EMAIL PROTECTED]>: > >> Here is the patch which checks the default scissorrect. I don't know if the >> resolutions are to big (1024x768). And I don't know if the stuff with the >> second swapchain (swapchain1) is correct. It produces this error in wine: >> "err:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow (0x1e7370): Want to change >> the window parameters of HWND 0x20034, but another style is stored for >> restoration afterwards". >> >> > Devices like the Eee PC only support up to 800x480, but in that case > creating the device should simply fail, and skip the test, so in that > regard the test should be fine. The error that gets printed in > probably a flaw in our handling of multiple swapchains. As long as the > test doesn't fail because of it it's probably not a concern for now. > You should check the return values for CreateAdditionallSwapChain and > GetScissorRect though. > Thanks for the answer. I'll add a check for the return values.
Fwd: Patchwatcher: failed regression tests: d3dx8: replace loops with explicit computations to make them faster [PATCH] d3dx8: replace loops by explicit computations
Patchwatcher notes that the conformance test fails here: ../../../tools/runtest -q -P wine -M d3dx8.dll -T ../../.. -p d3dx8_test.exe.so math.c && touch math.ok math.c:442: Test failed: Expected matrix= (-0.214800,1.311600,0.475200,0.00 0.950400,-0.883600,0.924400,0.00 1.021200,0.193600,-1.358800,0.00 18.298500,-29.624001,15.683499,1.00 ) Got matrix= (-0.214800,1.311600,0.475200,0.00 0.950401,-0.883601,0.924400,0.00 1.021204,0.193593,-1.358803,0.00 18.298538,-29.624159,15.683425,1.00) Looks like rounding errors, but one way or another, you have to take care of that. Also: did you benchmark this change to verify it actually made things faster? Unrolling loops is no longer as sure-fire a win as it used to be. I'm inclined to prefer the more compact, clear loop unless there's hard evidence it's > 1% slower. - Dan -- Forwarded message -- From: <[EMAIL PROTECTED]> Date: Fri, Aug 22, 2008 at 8:35 PM Subject: Patchwatcher: failed regression tests: d3dx8: replace loops with explicit computations to make them faster [PATCH] d3dx8: replace loops by explicit computations To: [EMAIL PROTECTED] Hi! This is the experimental automated wine patchwatcher thingy. The latest git sources were built and tested with your patch "d3dx8: replace loops with explicit computations to make them faster [PATCH] d3dx8: replace loops by explicit computations" Result: the patch failed regression tests. You can retrieve the full build results at http://kegel.com/wine/patchwatcher/results/264.log and see the patch as parsed at http://kegel.com/wine/patchwatcher/results/264.txt See http://kegel.com/wine/patchwatcher/results for more info.
Re: wined3d/d3d9: Set the initial scissor rect to the window size
2008/8/23 Rico Schüller <[EMAIL PROTECTED]>: > Here is the patch which checks the default scissorrect. I don't know if the > resolutions are to big (1024x768). And I don't know if the stuff with the > second swapchain (swapchain1) is correct. It produces this error in wine: > "err:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow (0x1e7370): Want to change > the window parameters of HWND 0x20034, but another style is stored for > restoration afterwards". > Devices like the Eee PC only support up to 800x480, but in that case creating the device should simply fail, and skip the test, so in that regard the test should be fine. The error that gets printed in probably a flaw in our handling of multiple swapchains. As long as the test doesn't fail because of it it's probably not a concern for now. You should check the return values for CreateAdditionallSwapChain and GetScissorRect though.
Re: [10/10] WineD3D: Sort out some limit confusion
2008/8/23 Henri Verbeet <[EMAIL PROTECTED]>:
> 2008/8/22 Stefan Dösinger <[EMAIL PROTECTED]>:
>> +glGetIntegerv(GL_MAX_TEXTURE_COORDS, &gl_max);
>> +gl_info->max_texture_coords = min(MAX_TEXTURES, gl_max);
>> +TRACE_(d3d_caps)("Max texture coords: %d\n",
>> gl_info->max_texture_coords);
> I don't know if this is intentional or not, but did you mean to use
> gl_info->max_textures here?
Just to clarify, "instead of MAX_TEXTURES".
Re: [10/10] WineD3D: Sort out some limit confusion
2008/8/22 Stefan Dösinger <[EMAIL PROTECTED]>:
> +glGetIntegerv(GL_MAX_TEXTURE_COORDS, &gl_max);
> +gl_info->max_texture_coords = min(MAX_TEXTURES, gl_max);
> +TRACE_(d3d_caps)("Max texture coords: %d\n",
> gl_info->max_texture_coords);
I don't know if this is intentional or not, but did you mean to use
gl_info->max_textures here?
> @@ -3172,7 +3172,7 @@ static void loadTexCoords(IWineD3DStateBlockImpl
> *stateblock, WineDirect3DVertex
> return;
> }
>
> -for (textureNo = 0; textureNo < GL_LIMITS(texture_stages); ++textureNo) {
> +for (textureNo = 0; textureNo < GL_LIMITS(texture_coords); ++textureNo) {
> int coordIdx =
> stateblock->textureState[textureNo][WINED3DTSS_TEXCOORDINDEX];
>
> mapped_stage = stateblock->wineD3DDevice->texUnitMap[textureNo];
Shouldn't that be testing mapped_stage against
GL_LIMITS(texture_coords) instead?
> -if (GL_SUPPORT(NV_REGISTER_COMBINERS)) {
> -/* The number of the mapped stages increases monotonically, so it's
> fine to use the last used one */
> -for (textureNo = mapped_stage + 1; textureNo < GL_LIMITS(textures);
> ++textureNo) {
> -GL_EXTCALL(glMultiTexCoord4fARB(GL_TEXTURE0_ARB + textureNo, 0,
> 0, 0, 1));
> -}
> -}
I'm probably missing something here, but why is it safe to remove that?
> @@ -420,7 +420,7 @@ static void drawStridedSlow(IWineD3DDevice *iface,
> WineDirect3DVertexStridedData
> }
>
> /* Texture coords --- */
> -for (textureNo = 0; textureNo < GL_LIMITS(texture_stages);
> ++textureNo) {
> +for (textureNo = 0; textureNo < GL_LIMITS(texture_coords);
> ++textureNo) {
>
> if (!GL_SUPPORT(ARB_MULTITEXTURE) && textureNo > 0) {
> FIXME("Program using multiple concurrent textures which this
> opengl implementation doesn't support\n");
Similar to above, shouldn't this test texture_idx against
GL_LIMITS(texture_coords) instead of textureNo?
In the bigger picture, these various limits are pretty tricky to get
right, I wonder if it might make more sense to handle most of this
stuff in the tex unit map instead. That way we could be sure that if a
stage is mapped to a sampler that sampler is safe to use.
Re: wined3d/d3d9: Set the initial scissor rect to the window size
Stefan Dösinger schrieb:
Are you sure you shouldn't be using the primary swapchain's
backbuffer
dimensions?
I'm not sure what exactly you mean.
Something like this:
IWineD3DSwapChain *swapchain;
IWineD3DSurface *backbuffer;
D3DSURFACE_DESC desc;
IWineD3DDevice_GetSwapChain(device, 0, &swapchain)
IWineD3DSwapChain_GetBackBuffer(swapchain, &backbuffer);
IWineD3DSurface_GetSurfaceDesc(backbuffer, &desc);
IWineD3DSurface_Release(backbuffer);
IWineD3DSwapChain_Release(swapchain);
scissorrect = {0, 0, desc.Width, desc.Height};
Just pseudocode, please look up the exact names of the methods and members.
Maybe there's a IWineD3DDevice_GetBackBuffer method which spares you the
extra GetSwapChain call. Don't forget the release calls.
The difference between your original patch and this can be seen in Windowed
mode. I recommend to put the appropriate test into dlls/d3d9/tests/device.c
and create a Windowed device.
Here is the patch which checks the default scissorrect. I don't know if
the resolutions are to big (1024x768). And I don't know if the stuff
with the second swapchain (swapchain1) is correct. It produces this
error in wine: "err:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow
(0x1e7370): Want to change the window parameters of HWND 0x20034, but
another style is stored for restoration afterwards".
So comments are welcome.
Cheers
Rico
diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c
index 3a56298..4e7a305 100644
--- a/dlls/d3d9/tests/device.c
+++ b/dlls/d3d9/tests/device.c
@@ -2051,6 +2051,103 @@ static void test_set_material(void)
if(d3d9) IDirect3D9_Release(d3d9);
}
+static void test_scissor_size(void)
+{
+IDirect3D9 *d3d9_ptr = 0;
+int i;
+static const struct {
+int winx; int winy; int backx; int backy; int backswap1x; int
backswap1y; BOOL window;
+} scts[] = { /* scissor tests */
+{800, 600, 640, 480, 1024, 768, TRUE},
+{800, 600, 640, 480, 1024, 768, FALSE},
+{640, 480, 800, 600, 1024, 768, TRUE},
+{640, 480, 800, 600, 1024, 768, FALSE},
+
+{1024, 768, 640, 480, 800, 600, TRUE},
+{1024, 768, 640, 480, 800, 600, FALSE},
+{640, 480, 1024, 768, 800, 600, TRUE},
+{640, 480, 1024, 768, 800, 600, FALSE},
+
+{1024, 768, 800, 600, 640, 480, TRUE},
+{1024, 768, 800, 600, 640, 480, FALSE},
+{800, 600, 1024, 768, 640, 480, TRUE},
+{800, 600, 1024, 768, 640, 480, FALSE},
+};
+
+d3d9_ptr = pDirect3DCreate9(D3D_SDK_VERSION);
+ok(d3d9_ptr != NULL, "Failed to create IDirect3D9 object\n");
+if (!d3d9_ptr){
+skip("Failed to create IDirect3D9 object\n");
+return;
+}
+
+for(i=0; itextures[i] = NULL;
}
+/* Set the default scissor rect values */
+desc.Width = &width;
+desc.Height = &height;
+
+IWineD3DDevice_GetSwapChain(device, 0, &swapchain);
+IWineD3DSwapChain_GetBackBuffer(swapchain, 0, WINED3DBACKBUFFER_TYPE_MONO,
&backbuffer);
+IWineD3DSurface_GetDesc(backbuffer, &desc);
+IWineD3DSurface_Release(backbuffer);
+IWineD3DSwapChain_Release(swapchain);
+
+scissorrect.left = 0;
+scissorrect.right = width;
+scissorrect.top = 0;
+scissorrect.bottom = height;
+IWineD3DDevice_SetScissorRect(device, &scissorrect);
+
TRACE("---> Device defaults now set up...\n");
return WINED3D_OK;
}
