Re: [wine-devel] Troubles configuring and building wine-1.5.30 on Debian wheezy
> The idea there to install *.so symlinks manually might be a big help. > For example, Debian wheezy does allow simultaneous install of > libfreetype6:i386 and libfreetype6:amd64. (In fact, my system has > those both installed now.) It is the -dev versions of those packages > which cannot be simultaneously installed on Debian Wheezy. So the > appropriate symlink may be all I need (for quite a few packages where > the i386 library is installed, but not the -dev version with the > symlink). > > I will try this symlink idea (which takes me back to my > first Linux install in 1996) later today after I get some sleep. > > Thanks, Frédéric! I think this might work. > > Alan > __ > Alan W. Irwin If you don't care about building anything 64 bit installing pkg-config:i386 while removing pkg-config:amd64 allows for libfreetype6-dev:i386 and libfontconfig1-dev:i386 to be installed without playing with symlinks. (Though maybe 64 bit building stuff still works after this? ) REalm
Re: ddraw: Fix filtering of enumerated display modes by bits per pixel
On 05/09/2011 10:11 PM, Stefan Dösinger wrote: > On Monday 09 May 2011 20:55:21 Ričardas Barkauskas wrote: >> +modes16bpp_cnt = 0; >> +U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x; >> +U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x; >> +U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x; > Please add an additional test that passes in non-null flags that don't match > standard R5G6B5. I'm not exactly sure what you mean with this. The other test has mask of R5G5B5. The one that's missing is R5G6B5, but I don't think it's needed. >> +if ((DDSD->dwFlags & DDSD_PIXELFORMAT) && (DDSD- >> u4.ddpfPixelFormat.dwFlags & DDPF_RGB) ) >> +if(pixelformat.u1.dwRGBBitCount != DDSD- >> u4.ddpfPixelFormat.u1.dwRGBBitCount) continue; > For the fun of it you could see what happens when you pass a non-RGB > format(e.g. a DDPF_YUV or DDPF_BUMPDUDV one) to EnumPixelFormat, but that's > not really a requirement for me. Afaics the DDPF_RGB check is needed anyway > to > enumerate 8 bit palettized formats properly. > > A YUV primary format may even make sense. A BUMPDUDV one not really. My bad. Didn't think of testing this before. Now it is to strict. Ricardas Barkauskas REalm
Re: wined3d: Fix some complaints in d3d9 texture test
On 05/04/2010 10:28 AM, Henri Verbeet wrote: 2010/5/4 Ričardas Barkauskas: Fixes some GL_INVALID_ENUM fixmes in d3d9 texture tests and bug 11167. Why are you setting GL_GENERATE_MIPMAP_SGIS? Sorry for spam. Reading bug now gives completely new meaning than in a middle of the night (and also enables finding old mails about it). Will try to make it this evening to just set the hint and output fixme if app sets two different modes. Doing this nicely with glGenerateMipmapEXT will most likely be outside my ability. REalm
Re: [1/2] comctl32/propsheet: Remove trailing spaces
On Sun, Oct 11, 2009 at 12:20 PM, lats wrote: > On 11/10/09 19:29, Ričardas Barkauskas wrote: >> >> Removes trailing spaces to have it clean for next patch > > I will be interested to see how you go with this one as the word has been > that formatting only patches are not accepted. > > > > Isn't it also that patch changing something and touching trailing spaces is also no go? Should those spaces be just left alone then? REalm
