wine-devel April 2006

wine-devel@winehq.org

176 participants
334 discussions

Re: Alexandre Julliard : configure: Filter out garbage from arts-config --libs too.
by Marcus Meissner 05 Apr '06

05 Apr '06

On Tue, Apr 04, 2006 at 05:37:44AM -0500, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 197a7d0422b2dd60009e405bc254ca616327fbf0 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=197a7d0422b2dd60009e405… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Apr 4 12:08:30 2006 +0200 > > configure: Filter out garbage from arts-config --libs too. > > --- > > configure | 9 ++++++++- > configure.ac | 9 ++++++++- > 2 files changed, 16 insertions(+), 2 deletions(-) > > diff --git a/configure b/configure > index 9bffafd..c825171 100755 > --- a/configure > +++ b/configure > @@ -10855,7 +10855,14 @@ then > -I*) ARTSC_CFLAGS="$ARTSC_CFLAGS $i";; > esac > done > - ARTSC_LIBS=`$ARTSCCONFIG --libs` > + ARTSC_LIBS="" > + for i in `$ARTSCCONFIG --libs` > + do > + case "$i" in > + -L/usr/lib|-L/usr/lib64) ;; > + -L*|-l*) ARTSC_LIBS="$ARTSC_LIBS $i";; > + esac > + done It also adds -L/opt/kde/lib64 for me, so this will likely not fully work. I would say we just do not configure arts and esd on 64->32 compiles. :/ Ciao, Marcus

2 4

Re: [PATCH] - rewrote toolhelp implementation only on top of ntdll functions
by Alexandre Julliard 05 Apr '06

05 Apr '06

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > + l = min(ldr_mod[i].BaseDllName.Length, sizeof(mod->szModule) - sizeof(WCHAR)); > + memcpy(mod->szModule, ldr_mod[i].BaseDllName.Buffer, l); > + mod->szModule[l / sizeof(WCHAR)] = '\0'; > + l = min(ldr_mod[i].FullDllName.Length, sizeof(mod->szModule) - sizeof(WCHAR)); > + memcpy(mod->szExePath, ldr_mod[i].FullDllName.Buffer, l); This can't work, the dll name and path are in the address space of the target process. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wined3d/OpenGL question
by Jason Green 05 Apr '06

05 Apr '06

I may be barking up the wrong tree here, but I'm trying to debug the cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in drawprim.c (line 1251). This is for Civilization 4 using both hardware vertex & pixel shaders. I've only noticed this error when it is passed GL_TRIANGLES with a large number of vertices. Here's a sample output with a little extra debugging info, and cleaned up a little: trace:d3d_draw:primitiveToGl TRIANGLES trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144, number of vertices1156 trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144, number of vertices1156 ... trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader trace:d3d_draw:drawPrimitiveDrawStrided glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok drawprim.c / 1846 trace:d3d_draw:drawPrimitiveDrawStrided glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850 trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...) fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from glDrawRangeElements @ drawprim.c / 1251 Often, a series of these errors will result in an unhandled exception in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1 kernel). I read up on the glDrawElements() function and it refered to the GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES. When I call that function, it returns 4096, and the number of vertices that it's trying to pass is larger than that. I've tried doing a min() of the max and the actual # of vertices, but the results are the same. So, the question is: Could this be one of the causes of the graphical glitches I'm seeing? I can toy around with these functions all day, but I don't really understand them all that well. Does that routine need to be reworked to split up a D3DPT_TRIANGLELIST into multiple calls if the calculated number of vertices/indices is too high for the user's graphics card? Or, am I way off base thinking this has any bearing on my real issues? Thanks, Jason

3 4

d3d: unhandled texture formats
by Ivan Gyurdiev 05 Apr '06

05 Apr '06

The F.E.A.R and BF2 demos crash immediately after complaining about: fixme:d3d:D3DFmtGetBpp Unhandled fmt(36,WINED3DFMT_A16B16G16R16) fixme:d3d:debug_d3dformat Unrecognized 81 D3DFORMAT! I have some native dlls installed, d3dx9_*.dll, mscoree.dll... that have no wine implementation. According to msdn: D3DFMT_A16B16G16R16 36 64-bit pixel format using 16 bits for each component. D3DFMT_L16 81 16-bit luminance only. The second one is missing from wined3d_private.h Both are missing from D3DFmtGetBpp. Also note that there's default handling in D3DFmtGetBpp that says: /* Guess at the highest value of the above */ and selects 4 bytes per pixel, but the highest value of the above is 8 - and it's used by D3DFMT_A16B16G16R16 - maybe that's why it crashes.

3 4

XVidMode is required for Gamma Control
by Jesse Allen 05 Apr '06

05 Apr '06

I've found that XVidMode is required for gamma control, and that it defaults to off. There are two bug reports about gamma. One is Diablo 2 as it fails to run at all in D3D mode because of it (and with a cryptic error too). The other is the gamma slider fails to produce the effect. There are three ways to fix the problem: 1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this. 2) Make UseXVidMode default to "Y". 3) Tell people to set UseXVidMode manually. Let me know what any of you think is best. I'd prefer the first one so that I won't have people scratching their heads over what is going on. Though #2 might be more correct than #1. Something should be changed because it's silly that Diablo 2 cannot run by default. Jesse

7 16

Re: wine / fontforge regression
by hurtta+wine＠leija.mh.fmi.fi 05 Apr '06

05 Apr '06

[ Charset UTF-8 unsupported, converting... ] > hurtta+wine(a)leija.mh.fmi.fi wrote: > > >http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html > > > > > > > >>It's OK that most people don't have fontforge installed, that just > >>means that people who can't cope with compiling from source and can't > >>satisfy all the required dependencies to create a working binary > >>shouldn't do it. They need to use a prepackaged one from a > >>confidential source who knows what is needed and how to resolve the > >>dependencies. > >> > >> > > > > > >Perhaps because there is NO binary available on > >list of http://www.winehq.org/site/download > Then they can check their distributions source package tree (pkgsrc, > ports, etc.) or binary tree (which compliments pkgsrc, ports, etc. and > is compatable.) > > I mean, come on, can it be that hard to look in ports? If distribution is 4 years old, wine is also. Distributions works good enough, but 4 year old is little different. Or have you different opinion?

1 0

Re: richedit20: Implement EM_FORMATRANGE
by Phil Krylov 04 Apr '06

04 Apr '06

On Tue, 4 Apr 2006 11:46:18 +1000 Troy Rollo <wine(a)troy.rollo.name> wrote: > + * *** Notes on tables *** > + * > + * The CHARRANGE structure passed in the FORMATRANGE structure is not > + * sufficient to deal with tables, where we would need information on the > + * start position for text in each column of the table. > + * > + * Testing on Windows NT shows that the Microsoft Rich Edit control gives > + * pathological results when there are tables in the document - both in edit > + * mode and for EM_FORMATRANGE. The Microsoft Rich Edit control uses the > + * table solely as a hint to where the paragraph should start. The table > + * does not expand to fit its text. Long paragraphs wrap when you hit the > + * right page margin and continue at the left page margin. This is only true for RichEdit 2.0 - later versions have better table support, while our current implementation is approximately at 2.0 level. -- Ph.

2 1

wine / fontforge regression
by hurtta+wine＠leija.mh.fmi.fi 04 Apr '06

04 Apr '06

http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html > It's OK that most people don't have fontforge installed, that just > means that people who can't cope with compiling from source and can't >satisfy all the required dependencies to create a working binary > shouldn't do it. They need to use a prepackaged one from a > confidential source who knows what is needed and how to resolve the > dependencies. Perhaps because there is NO binary available on list of http://www.winehq.org/site/download / Kari Hurtta

1 0

cvs help for bug #4541, Wine > 20050725 with FreeBSD 6.0
by Lee Parsons 04 Apr '06

04 Apr '06

Hello I submitted the bug #4541 regarding running the application WinMDI on wine in FreeBSD 6.0: http://bugs.winehq.org/show_bug.cgi?id=4541 I have begun regression testing on this bug. I have determined that it seems to break on 20050921, as 0921 works and 0922 does not. However, I have been unable to cvs checkout any particular versions of wine for that day. For example, if I look at the wine-cvs archives for that day, and want to checkout for the patch submitted 05:20:20, I run the command: lparsons@r32_1600$ cvs -d $CVSROOT checkout wine "2005-09-21 05:20 CDT" which ends up returning: cvs checkout: cannot find module `2005-09-21 05:20:20 CDT' - ignored I would like to be able to determine which patch specifically is responsible. Any help with CVS would be useful here. thank you Lee Parsons

2 1

Re: wined3d: Also print the format like a fourcc if unknown in debug_d3dformat.
by Alexandre Julliard 04 Apr '06

04 Apr '06

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -94,7 +94,7 @@ const char* debug_d3dformat(WINED3DFORMA > FMT_TO_STR(WINED3DFMT_CxV8U8); > #undef FMT_TO_STR > default: > - FIXME("Unrecognized %u D3DFORMAT!\n", fmt); > + FIXME("Unrecognized %u (as fourcc: %s) D3DFORMAT!\n", fmt, debugstr_an((CHAR*)&fmt,4)); Using %c%c%c%c as format would be better than a debugstr hack. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
27
28
29
30
31
32
33
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2006