January 2006 - Wine-Devel - list.winehq.org

Re: Direct3D 8/9 status?

by Roderick Colenbrander

I quickly checked the beta of the d3d8 rewrite. The d3d8 cleanup itself looked quite ok but some changes in wined3d were needed. Those changes aren't very clean (lots of ifdefs and hacks). I might try to port this stuff over to wine cvs and perhaps someone can then help clean it up. Roderick On Tuesday 31 January 2006 13:28, H. Verbeet wrote: > On 31/01/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > optimizations. What's the status on all this and what areas of wined3d > > are safe to touch? > > Not sure, I don't think Oliver has posted here a lot lately. I would > guess that ddraw/d3d7 and d3d8 are a bit tricky to modify at the > moment, while d3d9 should probably be ok. As for wined3d, if either > Stefan or Oliver need to make changes to that for their respective > rewrites, I would hope that they will submit those to the main tree as > soon as those changes are stable enough. Either way, I don't actually > know.

Jan. 31, 2006

Re: wined3d: Fixed render states

by H. Verbeet

On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > H. Verbeet wrote: > > On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > > > >> wined3d: Fixed up render states > >> > > You probably want to split the patch up in smaller pieces. > > > How would I do this? The changes to eg. EDGEANTIALIAS and POINTSPRITENABLE don't depend on eachother, and aren't really related, except for both of them being renderstates, so you could probably split those changes up into separate patches. > > Same problem as with your patch for d3d8, wined3d doesn't currently > > check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps). > > > Will be submitted as a separate patch. Falls back to the EXT version for > now. I think it is preferrable to check in working code as much as possible. Although it doesn't directly break stuff, it would probably be best to submit the checks for ARB_POINT_PARAMETERS support before trying to use it. > >> - /* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but then ATI drivers are buggered! */ > >> - glDisable(GL_POINT_SMOOTH); > >> > > Did you verify that this isn't required anymore? Otherwise that's a > > potential regression. > > > This seems to be a bug with (some?) ATI hardware/drivers. > Point smoothing should normally be supported I believe. Well yes, but I doubt we want to break stuff that was previously working.

Jan. 31, 2006

Re: Fix Bug#: 4396: floating MFC-ToolBars get managed and can't be re-docked

by Robert Shearman

Tobias Loew wrote: >Changelog: > dlls/x11drv/window.c > > Tobias Loew <tobi(a)die-loews.de> > Fix Bug#: 4396: floating MFC-ToolBars get managed and can't be re-docked > don't manage top-level windows having the style WS_EX_TOOLWINDOW and WS_CAPTION > >Tobias Loew > > Hi Tobias, I'm afraid this patch isn't likely to be applied. The reason is that moving around the rules for being a managed window or not is likely to cause regressions. Alexandre has stated that the only real solution is to be able to switch between managed and non-managed on the fly and add new (and better) dynamic rules to control this. -- Rob Shearman

Jan. 31, 2006

Re: keyboard: fix the keyboard problem when using UTF-8 locales

by Robert Shearman

Dmitry Timoshkov wrote: >On Tue, 2006-01-31 at 13:11 +0200, Fatih Aşıcı wrote: > > > >>When using UTF-8 locale, I can't type some Turkish characters. >>I don't know whether it works with other languages. >>But it works at least in Turkish locale. >> >> > > > >>+ have_chars = XLookupString(&e2, bufC, 2, &keysym, NULL); >>+ if(have_chars > 1){ >>+ MultiByteToWideChar(CP_UNIXCP, 0, bufC, -1, bufW, -1); >>+ WideCharToMultiByte(CP_ACP, 0, bufW, -1, &ckey[i], 1, NULL, >> >> >NULL); > > >>+ } >> >> > >Probably it works for Turkish locale but it won't work in general. >Code pages often have characters which could not be be represented >in other code pages and therefore will be lost. > > Then how should Fatih's problem be fixed? -- Rob Shearman

Jan. 31, 2006

wine and xscanimage

by Roland Kaeser

Hello I recently tried to get a sane-scanner work with wine and noticed hat the xscanimage mostly is no longer part of the shipped sane frontends by actual distributions. It becomes harder and harder to get a update to date version of xscanimge. Wouldn't it be better to choose an other sane-frontend for the wine twain/sane integration? Kind regards Roland Kaeser

Jan. 31, 2006

Re: PATCH: Wine Turkish translations

by Mike McCormack

Fatih Aşıcı wrote: > Turkish resources for wine > > Changelog: > Fatih Asici <fasici(a)linux-sevenler.org> > - Turkish translations (includes all wine resources) Thanks for translating all these. Before Alexandre applies them, it's likely you'll need to split the patch up into smaller chunks, and submit them one per email. This makes it easier for reviewers to spot problems, and for Alexandre to apply the patches. eg. The following two patches should be sent together in one email: diff -Nur oldwine/dlls/commdlg/rsrc.rc wine/dlls/commdlg/rsrc.rc diff -Nur oldwine/dlls/commdlg/cdlg_Tr.rc wine/dlls/commdlg/cdlg_Tr.rc thanks, Mike

Jan. 31, 2006

Re: keyboard: fix the keyboard problem when using UTF-8 locales

by Dmitry Timoshkov

On Tue, 2006-01-31 at 13:11 +0200, Fatih Aşıcı wrote: > When using UTF-8 locale, I can't type some Turkish characters. > I don't know whether it works with other languages. > But it works at least in Turkish locale. > + have_chars = XLookupString(&e2, bufC, 2, &keysym, NULL); > + if(have_chars > 1){ > + MultiByteToWideChar(CP_UNIXCP, 0, bufC, -1, bufW, -1); > + WideCharToMultiByte(CP_ACP, 0, bufW, -1, &ckey[i], 1, NULL, NULL); > + } Probably it works for Turkish locale but it won't work in general. Code pages often have characters which could not be be represented in other code pages and therefore will be lost. -- Dmitry.

Jan. 31, 2006

Re: wined3d: Fixed render states

by Vitaly Budovski

H. Verbeet wrote: > On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > >> wined3d: Fixed up render states POINTSCALEENABLE, POINTSPRITENABLE, >> EDGEANTIALIAS, MULTISAMPLEANTIALIAS >> > You probably want to split the patch up in smaller pieces. > How would I do this? > >> + if(This->stateBlock->renderState[D3DRS_POINTSCALEENABLE]) { >> + att[0] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_A]) / >> + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); >> + att[1] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_B]) / >> + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); >> + att[2] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_C]) / >> + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); >> + } >> > You're not supposed to use D3DRS_ stuff in wined3d, rather use the > respective WINED3DRS_ defines, as the original code did. > Typo, I'll fix that. >> + if(GL_SUPPORT(ARB_POINT_PARAMETERS)) { >> > Same problem as with your patch for d3d8, wined3d doesn't currently > check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps). > Will be submitted as a separate patch. Falls back to the EXT version for now. >> - /* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but then ATI drivers are buggered! */ >> - glDisable(GL_POINT_SMOOTH); >> > Did you verify that this isn't required anymore? Otherwise that's a > potential regression. > This seems to be a bug with (some?) ATI hardware/drivers. Point smoothing should normally be supported I believe. >> + checkGLcall("glEnable(Gl_LINE_SMOOTH)"); >> + checkGLcall("glDisable(Gl_LINE_SMOOTH)"); >> > That should probably say Gl_LINE_SMOOTH, but it's not really critical > Non-critical typo, but will be fixed when I resend the patch.

Jan. 31, 2006

Re: wined3d: Fixed render states

by H. Verbeet

On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > wined3d: Fixed up render states POINTSCALEENABLE, POINTSPRITENABLE, > EDGEANTIALIAS, MULTISAMPLEANTIALIAS You probably want to split the patch up in smaller pieces. > + if(This->stateBlock->renderState[D3DRS_POINTSCALEENABLE]) { > + att[0] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_A]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + att[1] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_B]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + att[2] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_C]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + } You're not supposed to use D3DRS_ stuff in wined3d, rather use the respective WINED3DRS_ defines, as the original code did. > + if(GL_SUPPORT(ARB_POINT_PARAMETERS)) { Same problem as with your patch for d3d8, wined3d doesn't currently check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps). > - /* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but then ATI drivers are buggered! */ > - glDisable(GL_POINT_SMOOTH); Did you verify that this isn't required anymore? Otherwise that's a potential regression. > + checkGLcall("glEnable(Gl_LINE_SMOOTH)"); > + checkGLcall("glDisable(Gl_LINE_SMOOTH)"); That should probably say Gl_LINE_SMOOTH, but it's not really critical.

Jan. 31, 2006

Re: Direct3D 8/9 status?

by H. Verbeet

On 31/01/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > optimizations. What's the status on all this and what areas of wined3d are > safe to touch? Not sure, I don't think Oliver has posted here a lot lately. I would guess that ddraw/d3d7 and d3d8 are a bit tricky to modify at the moment, while d3d9 should probably be ok. As for wined3d, if either Stefan or Oliver need to make changes to that for their respective rewrites, I would hope that they will submit those to the main tree as soon as those changes are stable enough. Either way, I don't actually know.

Jan. 31, 2006