Re: msi 2: Remove redundant NULL checks before x_Release
James Hawkins wrote: Changelog: * Remove redundant NULL checks before x_Release. obj->Release() will read the vtable pointer from the object, and that will crash if obj is NULL, so these checks are needed. The following code will crash: IUnknown *obj = NULL; IUnknown_Release(obj); You can see this looking at the definition of the IUnknown_Release macro: include/unknwn.h:#define IUnknown_Release(p) (p)->lpVtbl->Release(p) Mike
Wined3d State management again
Hi, I've done some more work on my state management, and I uploaded an updated patch to http://stud4.tuwien.ac.at/~e0526822/wined3d-statemgmt-2.tar.bz2 . Ok, so what's updated: * Pixel shaders: Should work now * GLSL shaders: Working too. Henris shader backend stuff is integrated in a messy way. * Offscreen rendering: Works with back buffer and pbuffer rendering, fbos not yet. * Stateblocks: Brute force integration by just scheduling all modified states for a reset. No display list yet * Blitting, render target unlocking: Enabled again, sets new gl states and schedules a reapplication of the modified states. Not a nice solution yet What is still missing: * Nv register combiners. I haven't found a way yet to build a texture stage -> texture unit mapping which I like. All the ways I could think of could potentially cause lots of unneccessary state changes. One nice thing I have noticed is that this changes give a huge performance gain in Half-Life 2(dxlevel 80, and 90). Dxlevel 80 is accelerated to approximately 150-200% of the former performance, and especially slow parts are faster now. This makes a really huge playability difference :-) There are some regressions too, especially related to texture loading(3Dmark2000), and some glsl crashes. The good part about this change is that I can send it in in very small patches, making regression testing much easier, contrary to the huge ddraw rewrite. Where to go from here? As long as nobody screams I'd start sending patches now. Its easier to catch regressions while sending small patches instead of hunting them on the blob I have here(and my messy patch history in my git tree). I'm also afraid that I get too far away from the main wined3d code(See the shader backend integration). We can discuss the code based on the small changes I'll send. Stefan pgpca9doRRbdl.pgp Description: PGP signature
Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch
From: Alexandre Julliard <[EMAIL PROTECTED]> To: "Nick Burns" <[EMAIL PROTECTED]> CC: wine-devel@winehq.org Subject: Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch Date: Fri, 01 Dec 2006 13:49:52 +0100 "Nick Burns" <[EMAIL PROTECTED]> writes: > Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE > I would like to have a choice. Why? What does it do that you cannot do with the CoreAudio driver? True the coreaudio driver can be made awesome -- but as it stands it has problems with many games on my machine (currently hard for me to test due to fullscreen detection changes in ogl) Problems range from deadlocking -- to crackling sound There are a few games that run flawlessly under coreaudio My openal driver also has crackling sound in some games (but i have not yet seen deadlocking -- its possible it could) Also the coreaudio driver is not testable and wont help linux ppl -- just Mac ppl An openal driver would be multi-platform -- testable under windows/mac/linux, would add a 2nd built-in driver to Mac OSX. > Yes my wineopenal patch is not perfect (based on broken code does not > help) -- I know that -- but thats why i want to get it into wine -- so > other people who know more about audio can add to it and make it > better Judging from past experience, people for whom it doesn't work right will simply go out and implement yet another driver, with yet another set of bugs... True -- it has its own set of bugs -- but I cannot iron them out myself -- I would need help from people to do so -- thats why I would like to give it as an option to you wine people (who can test it on linux) (its possible i could try and start a side project in sf.net or something -- no clue what other options there are) In a perfect world we could make an awesome cross-platform openal driver that does ... everything (winmm/dsound/dsound3d/...) everywhere (Linux/Windows/MacOSX) -- So, thats all the good stuff about it... The bad stuff is that its another driver in the tree another option to confuse people another point of failure ... (there is more badness here probably) -- Alexandre Julliard [EMAIL PROTECTED] - Nick
Re: Concerning the separate OpenAL32.dll thunk patch andOpenALwinmm driver patch
Sorry I should have reiterated more clearly... Yes you can dl jack -- but it has never worked correctly for me...(I could try Jack again -- it has been a while) esd -- but it too did not work so well (very laggy sound) liboss -- but i dont think that the alpha version compiles under osx... (did not really try to hard there i must admit hehe) alsa -- it could be ported -- but .. I dont wish that on anyone I am referring to builtin sound drivers for Mac OSX -- We have CoreAudio and OpenAL builtin (no alsa, no oss, no esd, no jack, ...) And coreaudio cannot be tested by anyone except for Mac people... (There seems to be much fewer mac people here...) An OpenAL driver can be tested by linux people with openal (ok those #s i dont know) So, the openal driver is one that CAN work and be multi platform Coreaudio can be made to be the most awesome as well -- but that does not help linux - Nick From: Pierre d'Herbemont <[EMAIL PROTECTED]> To: Nick Burns <[EMAIL PROTECTED]> CC: wine-devel@winehq.org Subject: Re: Concerning the separate OpenAL32.dll thunk patch andOpenALwinmm driver patch Date: Fri, 1 Dec 2006 17:15:30 +0100 On 1 déc. 06, at 00:54, Nick Burns wrote: Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice. In fact there is at least two working sound driver: you can also use the Jack driver on Mac OS X if you've downloaded [1] at compile time which by the way seems to have a working audio input. [1] http://www.jackosx.com/ Pierre.
Re: Video problems with FC6
On Fri, 01 Dec 2006 09:13:31 -0500 gslink <[EMAIL PROTECTED]> wrote: > There is currently a bug in FC6 that affects Wine. If, with any Nvidia > driver from any source, a program attempts to use accelerated video and > the attached monitor uses digital feed the program will often crash the > user session. This has been reported and is not a problem in Wine but a > good many games that used to run under Wine now crash. Other cards were > not tested but may be affected. It is hoped RH will fix this rather > quickly. > > Could you be a bit more specific. I don't have any problems with this combination at all. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB [EMAIL PROTECTED] | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043| mail preferred signature.asc Description: PGP signature
Re: [PATCH 1/9] dinput: Move acquired flag to the base device class.
Peter Oberndorfer wrote: > On Friday 01 December 2006 07:23, Vitaliy Margolen wrote: >> >> --- >> dlls/dinput/device.c | 28 >> dlls/dinput/device_private.h |3 +++ >> dlls/dinput/joystick_linux.c | 23 --- >> dlls/dinput/keyboard.c | 36 >> dlls/dinput/mouse.c | 23 --- >> 5 files changed, 63 insertions(+), 50 deletions(-) >> > Hi, > some questions/notices about this patch: Thank you for spending time and looking over my craft :) > Previously when the device was not acquired inside JoystickAImpl_Unacquire > DIERR_NOTACQUIRED was returned. > now you call IDirectInputDevice2AImpl_Unacquire, which returns DI_NOEFFECT > when not acquired. That is correct. I should have added small tests to show that it should work that way. I will add it next time around. > but DI_NOEFFECT does not have high bit set so it won't trigger the FAILED > macro. Oops I didn't check that one. More reasons for some tests. > Do you know if the Acquire/Unacquire functions return value the same for all > device types? Tests and msdn indicate that return values are identical for all devices. > In JoystickAImpl_Acquire you don't use your new > IDirectInputDevice2AImpl_Acquire function but set This->base.acquired = 1; > Is there a reason for this? > In SysKeyboardAImpl_Unacquire you seem to call > IDirectInputDevice2AImpl_Acquire? Because there are few other things that's being checked before joystick can be acquired. Mouse and keyboard just acquire the device without any additional checking. There are lots of other inconsistencies all over dinput. This is one of the reasons I'm trying to unify all the common code in one place. Vitaliy
Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch
On 1 déc. 06, at 00:54, Nick Burns wrote: Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice. In fact there is at least two working sound driver: you can also use the Jack driver on Mac OS X if you've downloaded [1] at compile time which by the way seems to have a working audio input. [1] http://www.jackosx.com/ Pierre.
Video problems with FC6
There is currently a bug in FC6 that affects Wine. If, with any Nvidia driver from any source, a program attempts to use accelerated video and the attached monitor uses digital feed the program will often crash the user session. This has been reported and is not a problem in Wine but a good many games that used to run under Wine now crash. Other cards were not tested but may be affected. It is hoped RH will fix this rather quickly.
Re: user32: Factorize graphics driver's WindowCreate and ShowWindowin user32.
On 1 déc. 06, at 08:38, Dmitry Timoshkov wrote: The problem is that for top level windows we need to route ShowWindow actions to a Window Manager/Host Windowing System, so that actions like minimize/maximize/restore would be properly handled. We don't do this at the moment, but we need to. ok thanks, I got your point. Pierre.
Re: oleaut32: add VarBstrCmp binary comparison for LCID==0
"Charles Blacklock" <[EMAIL PROTECTED]> wrote: Cool, the attached patch does this now. Is this any better? Yes (although I'd personally move local variables under the "if (lcid == 0)" case), please send it to wine-patches. -- Dmitry.
Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch
"Nick Burns" <[EMAIL PROTECTED]> writes: > Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE > I would like to have a choice. Why? What does it do that you cannot do with the CoreAudio driver? > Yes my wineopenal patch is not perfect (based on broken code does not > help) -- I know that -- but thats why i want to get it into wine -- so > other people who know more about audio can add to it and make it > better Judging from past experience, people for whom it doesn't work right will simply go out and implement yet another driver, with yet another set of bugs... -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH 1/9] dinput: Move acquired flag to the base device class.
On Friday 01 December 2006 07:23, Vitaliy Margolen wrote: > Sorry ignore my previous patches. I didn't send them in the proper order. > > --- > dlls/dinput/device.c | 28 > dlls/dinput/device_private.h |3 +++ > dlls/dinput/joystick_linux.c | 23 --- > dlls/dinput/keyboard.c | 36 > dlls/dinput/mouse.c | 23 --- > 5 files changed, 63 insertions(+), 50 deletions(-) > Hi, some questions/notices about this patch: Previously when the device was not acquired inside JoystickAImpl_Unacquire DIERR_NOTACQUIRED was returned. now you call IDirectInputDevice2AImpl_Unacquire, which returns DI_NOEFFECT when not acquired. but DI_NOEFFECT does not have high bit set so it won't trigger the FAILED macro. Do you know if the Acquire/Unacquire functions return value the same for all device types? In JoystickAImpl_Acquire you don't use your new IDirectInputDevice2AImpl_Acquire function but set This->base.acquired = 1; Is there a reason for this? In SysKeyboardAImpl_Unacquire you seem to call IDirectInputDevice2AImpl_Acquire? Greetings Peter
Re: oleaut32: add VarBstrCmp binary comparison for LCID==0
"Charles Blacklock" <[EMAIL PROTECTED]> wrote:
+if (lcid == 0)
+{
+ ret = memcmp(pbstrLeft, pbstrRight, min(SysStringByteLen(pbstrLeft),
SysStringByteLen(pbstrRight)));
+ if (ret < 0)
+return VARCMP_LT;
+ if (ret > 0)
+return VARCMP_GT;
+ if (SysStringByteLen(pbstrLeft) < SysStringByteLen(pbstrRight))
+return VARCMP_LT;
+ if (SysStringByteLen(pbstrLeft) > SysStringByteLen(pbstrRight))
+return VARCMP_GT;
+ return VARCMP_EQ;
+}
It would be much more effective to call SysStringByteLen only once for each
string instead of calling it again and again after a failing comparison.
--
Dmitry.
