Re: Current wine and HL2 family - well done!
Am Montag 05 März 2007 06:56 schrieb Pavel Troller: > > > without an annoying graphics glitch causing parts of > > > > skies to be > > > > > replaced with some bogus contents like white, black, > > > > mirrors of a part of > > > > > ground etc. > > > > Are you finding no errors at all? In Counter-Strike: > > Source, when running in anything above DX7 mode, on > > the map "de_aztec", the screen is often completely > > black - it appears to be when looking at water. > > Hi! > We just tried it and we can't reproduce your problem. We were even going > in the water itself and the display was smooth and without any distortion. > We set the DX9 mode in the game command line (parameter -dxlevel 90). > With regards, Pavel Troller Keep in mind that for dxlevel 90 you have to enable glsl. Otherwise it is still dxlevel 80 pgpHu3CImjG0w.pgp Description: PGP signature
Re: Current wine and HL2 family - well done!
> > without an annoying graphics glitch causing parts of > skies to be > > replaced with some bogus contents like white, black, > mirrors of a part of > > ground etc. > > Are you finding no errors at all? In Counter-Strike: > Source, when running in anything above DX7 mode, on > the map "de_aztec", the screen is often completely > black - it appears to be when looking at water. > Hi! We just tried it and we can't reproduce your problem. We were even going in the water itself and the display was smooth and without any distortion. We set the DX9 mode in the game command line (parameter -dxlevel 90). With regards, Pavel Troller
Re: AppDB performance issue
From: Tony Lambregts <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: wine-devel@winehq.com, Louis Lenders <[EMAIL PROTECTED]> Subject: Re: AppDB performance issue Date: Sun, 04 Mar 2007 18:49:54 -0700 Nick Law wrote: > I still find appdb really slow 60 seconds to view some pages, post on > the forums etc It's driving me nuts to the point I've gone back to > real life for a while as it's less frustrating. BTW this problems exists > on systems separated by over 100 miles (but same login account) so it > not hardware at my end. > > I'll check back now and again to see if it's fixed. > > Apart from that, keep up the good work devs, wine's functionality is > improving all the time but appdb needs fixing. > > Cheers > Nick > I only seem to have this problem when I am logged in. When I am not logged in it seems that there is no lag at all. I tried to do some administration and just logging in took 2 minutes. I was able to confirm a bunch of bug links and things were fine for most of them but about every 10th bug link I confirmed it would just seem to hang for a minute or two. I then tried to confirm some application submissions and every time it took at least 3 minutes to process. When I am logged in I frequently will get lags of a minute or two just viewing apps. This does not happen all the time and I have not found any reason why it should slow down at all. Visiting the same page at the same time with a not logged in account shows no slow down. -- Tony Lambregts I'm experiencing the same problems. Sometimes the AppDB doesn't come up at all, but when it does it works fine, then I really don't notice a problem until I login or try to login.
Re: AppDB performance issue
Tony Lambregts wrote: Nick Law wrote: I still find appdb really slow 60 seconds to view some pages, post on the forums etc It's driving me nuts to the point I've gone back to real life for a while as it's less frustrating. BTW this problems exists on systems separated by over 100 miles (but same login account) so it not hardware at my end. I'll check back now and again to see if it's fixed. Apart from that, keep up the good work devs, wine's functionality is improving all the time but appdb needs fixing. Cheers Nick I only seem to have this problem when I am logged in. When I am not logged in it seems that there is no lag at all. I tried to do some administration and just logging in took 2 minutes. I was able to confirm a bunch of bug links and things were fine for most of them but about every 10th bug link I confirmed it would just seem to hang for a minute or two. I then tried to confirm some application submissions and every time it took at least 3 minutes to process. When I am logged in I frequently will get lags of a minute or two just viewing apps. This does not happen all the time and I have not found any reason why it should slow down at all. Visiting the same page at the same time with a not logged in account shows no slow down. -- Tony Lambregts Hi Tony, That's absolutely 100% exactly the same symptoms I get. It only appears to be a problem if I login. It appears to be getting worse as the weeks progress, I'm sure when this started happening it was only about a minute or less delay, now like you say it is 3 minutes. It's most annoying for me when I login to reply to posts on the forum. I get the feeling that not everybody suffers from this as much as we do, otherwise we'd see many more posts about the subject ? BTW the following procedure was done on a OpenSuse 9.3 system with Firefox & Opera browsers. One other thing I noticed if I login (using Firefox), reply to a message on the forum then after pressing submit it just sits there, I then open up opera but don't login just view the posts, my post is there and yet Firefox is still hanging there waiting for a page update which 3 minutes later it gets. So basically my post gets added to the database pretty quick it's the page update that is delayed. Don't know if that makes any sense ? Regards Nick
Re: AppDB performance issue
Nick Law wrote: > I still find appdb really slow 60 seconds to view some pages, post on > the forums etc It's driving me nuts to the point I've gone back to > real life for a while as it's less frustrating. BTW this problems exists > on systems separated by over 100 miles (but same login account) so it > not hardware at my end. > > I'll check back now and again to see if it's fixed. > > Apart from that, keep up the good work devs, wine's functionality is > improving all the time but appdb needs fixing. > > Cheers > Nick > I only seem to have this problem when I am logged in. When I am not logged in it seems that there is no lag at all. I tried to do some administration and just logging in took 2 minutes. I was able to confirm a bunch of bug links and things were fine for most of them but about every 10th bug link I confirmed it would just seem to hang for a minute or two. I then tried to confirm some application submissions and every time it took at least 3 minutes to process. When I am logged in I frequently will get lags of a minute or two just viewing apps. This does not happen all the time and I have not found any reason why it should slow down at all. Visiting the same page at the same time with a not logged in account shows no slow down. -- Tony Lambregts
Re: New opengl thread context selection patches for testing
Stefan Dösinger wrote: > Hi, > Here is a new patchset for testing which implements duplicating gl contexts > for new threads in wined3d. Again, it does not implement any synchronisation > measures(except ENTER_GL and glFinish), so running multithreaded games is > still kinda a lottery. Awesome job! Now several more games that didn't work start working: - Indiana Jones and emperor tomb - Prince of Persia Sands of the Time - Psychonauts All of them were crashing after playing intro video(s). The only finicky game is Psychonauts. I had to force multi-threaded d3d and even then it some times crashes. Apparently it's the case of thread safety that we don't have yet. In general it seems the good step forward allowing lots more games to work on Wine. Vitaliy.
Re: [msi, 1/5, try 5] msi: Add OLE automation conformance test.
On Sun, 2007-03-04 at 16:18 -0600, James Hawkins wrote: > On 3/4/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-03-04 at 15:50 -0600, James Hawkins wrote: > > > On 3/4/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: > > > > Changes: Ok, try 5. This time there are five patches, as this first > > > > patch is a (moderately) comprehensive conformance test for MSI OLE > > > > automation, which checks all the functions that will be implemented, and > > > > does basic checks like set a property, then get it, is the property what > > > > we set it to? I hope this helps get it into git. > > > > > > > > These patches add partial OLE automation support for MSI and then add > > > > JScript/VBScript support for MSI (as the MSI specs specifically state > > > > that applications that need this functionality must install Windows > > > > Script themselves). As a proof of concept, sufficient automation support > > > > is added to conform to the conformance test and to fix bug #7357. > > > > > > > > > > Doesn't compile: > > > > > > ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole > > > automation.o db.o format.o iface.o install.o msi.o package.o record.o > > > suminfo.otestlist.o -o msi_test.exe.so > > > ../../../libs/port/libwine_port.a -lcabinet -lmsi -lshell32 -lole32 > > > -ladvapi32 -lkernel32 -luuid > > > automation.o: In function `invoke': > > > /home/truiken/wine/dlls/msi/tests/automation.c:389: undefined > > > reference to `VariantInit' > > > /home/truiken/wine/dlls/msi/tests/automation.c:404: undefined > > > reference to `VariantClear' > > > /home/truiken/wine/dlls/msi/tests/automation.c:398: undefined > > > reference to `VariantChangeTypeEx' > > > > > > > That's really weird, because after a ./configure --prefix=/usr in the > > main wine-git directory make automation.ok works just fine for me. I > > will try doing a make clean; make; sudo make install for the whole wine > > git tree (this will probably take at least 40 minutes or more on my > > computer as it is pretty slow) and report back. > > > > You forgot to add oleaut32 to IMPORTS in Makefile.in. > Fair enough, I will resubmit, but I still don't understand why it compiles fine on my machine (and does link in oleaut32 even though I don't specify it in Makefile or Makefile.in) but not on yours. Misha
Re: Settlers II: 10th Anniversary regression?
On Sunday 04 March 2007 21:12, you wrote:
> Unlikely, dplay is rather old. Can you do a regression test? Most likely
> one of my d3d patches killed it.
I would, but unfortunately I cannot compile Wine myself under (SUSE) x86_64
even though I follow the instructions at http://wiki.winehq.org/WineOn64bit
{standard input}: Assembler messages:
{standard input}:38: Error: suffix or operands invalid for `push'
[...]
--
Markus
HtmlHelp status, winecfg and SoC proposal
Hello. As you may have noticed, I've been working on HtmlHelp lately. Currently it should generally work, but still there is a lot to do. HTML should be correctly displayed and content tab should work. I was thinking about making more use of it in Wine. I think winecfg could benefit from it. We could easily add context help to winecfg using HtmlHelp API. Even just integrating a part of Wine User's Guide would be a good start. The main problem is building chm file (that is the file format of HtmlHelp). Microsoft has a HtmlHelp compiler (hhc) for it. We'd need something similar in Wine. AFAIK there is no good open source replacement. HtmlHelp maker (hhc, see [1]) doesn't create internal files (parts of chm that describes stuff like index or default topic) and it's GPLed so it's useless for Wine (unless author would relicense it for us). I think it would be a good project for Google Summer of Code. The task would be to write a hhc replacement and add a help option to winecfg. hhc replacement (say whhc) would have to be a plain UNIX tool (it means a bit of code duplication with itss.dll, just like we do in widl) so we could use it during compilation. I think its difficulty is good for SoC. Compressing code may be integrated from some other project. The remaining parts are code of parser of files describing chm and a little winecfg hacking. What do you think? Jacek [1] http://savannah.nongnu.org/projects/hhm
Re: [msi, 1/5, try 5] msi: Add OLE automation conformance test.
On 3/4/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: On Sun, 2007-03-04 at 15:50 -0600, James Hawkins wrote: > On 3/4/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: > > Changes: Ok, try 5. This time there are five patches, as this first > > patch is a (moderately) comprehensive conformance test for MSI OLE > > automation, which checks all the functions that will be implemented, and > > does basic checks like set a property, then get it, is the property what > > we set it to? I hope this helps get it into git. > > > > These patches add partial OLE automation support for MSI and then add > > JScript/VBScript support for MSI (as the MSI specs specifically state > > that applications that need this functionality must install Windows > > Script themselves). As a proof of concept, sufficient automation support > > is added to conform to the conformance test and to fix bug #7357. > > > > Doesn't compile: > > ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole > automation.o db.o format.o iface.o install.o msi.o package.o record.o > suminfo.otestlist.o -o msi_test.exe.so > ../../../libs/port/libwine_port.a -lcabinet -lmsi -lshell32 -lole32 > -ladvapi32 -lkernel32 -luuid > automation.o: In function `invoke': > /home/truiken/wine/dlls/msi/tests/automation.c:389: undefined > reference to `VariantInit' > /home/truiken/wine/dlls/msi/tests/automation.c:404: undefined > reference to `VariantClear' > /home/truiken/wine/dlls/msi/tests/automation.c:398: undefined > reference to `VariantChangeTypeEx' > That's really weird, because after a ./configure --prefix=/usr in the main wine-git directory make automation.ok works just fine for me. I will try doing a make clean; make; sudo make install for the whole wine git tree (this will probably take at least 40 minutes or more on my computer as it is pretty slow) and report back. You forgot to add oleaut32 to IMPORTS in Makefile.in. -- James Hawkins
Re: [msi, 1/5, try 5] msi: Add OLE automation conformance test.
On Sun, 2007-03-04 at 15:50 -0600, James Hawkins wrote: > On 3/4/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: > > Changes: Ok, try 5. This time there are five patches, as this first > > patch is a (moderately) comprehensive conformance test for MSI OLE > > automation, which checks all the functions that will be implemented, and > > does basic checks like set a property, then get it, is the property what > > we set it to? I hope this helps get it into git. > > > > These patches add partial OLE automation support for MSI and then add > > JScript/VBScript support for MSI (as the MSI specs specifically state > > that applications that need this functionality must install Windows > > Script themselves). As a proof of concept, sufficient automation support > > is added to conform to the conformance test and to fix bug #7357. > > > > Doesn't compile: > > ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole > automation.o db.o format.o iface.o install.o msi.o package.o record.o > suminfo.otestlist.o -o msi_test.exe.so > ../../../libs/port/libwine_port.a -lcabinet -lmsi -lshell32 -lole32 > -ladvapi32 -lkernel32 -luuid > automation.o: In function `invoke': > /home/truiken/wine/dlls/msi/tests/automation.c:389: undefined > reference to `VariantInit' > /home/truiken/wine/dlls/msi/tests/automation.c:404: undefined > reference to `VariantClear' > /home/truiken/wine/dlls/msi/tests/automation.c:398: undefined > reference to `VariantChangeTypeEx' > That's really weird, because after a ./configure --prefix=/usr in the main wine-git directory make automation.ok works just fine for me. I will try doing a make clean; make; sudo make install for the whole wine git tree (this will probably take at least 40 minutes or more on my computer as it is pretty slow) and report back. Misha
Re: New opengl thread context selection patches for testing
Ok, i tried it with current CVS. + There are many improvments in some games like Tomb Raider Legends, GTA San Andreas, HalfLife Episode One and 3DMark 2005 or 2006 + Oblivion is still broken (same as with previous patchset) + With your previous Thread patchset Rainbow Six Vegas can even run into menu, but now it hang while loading menu. + I can't find any other regressions :) Tested with: - 3DMark 2003 - 3DMark 2005 - 3DMark 2006 - Alpine Sky Racing 2007 - Battlefield 2142 Demo - Call of Duty 2 - Flatout 2 - GTA San Andreas - Half-Life 2 EO - NFS: MW - NFS: Carbon (can't run it before and after) - All NVidia SDK Direct3D Demos - Neverwinter Nights 2 (can't run it before and after) - Polda 5 (czech game) - Rayman 3 - Rayman Raving Rabbids (can't run it before and after) - Rainbow Six: Vegas - TES IV: Oblivion - Titan Quest (still hangs in menu) - Tomb Raider: Legend Mirek Stefan Dösinger napsal(a): Hi, Here is a new patchset for testing which implements duplicating gl contexts for new threads in wined3d. Again, it does not implement any synchronisation measures(except ENTER_GL and glFinish), so running multithreaded games is still kinda a lottery. This patchset also contains a patch for offscreen rendering, which may fix the problems introduced with TES: Oblivion before. This is just a format-patch of my git tree, the first 3 patches are unrelated. One of them is a clone of Henri's already sent patch, and the other 2 patches were sent by me already. Happy testing, Stefan
Re: [msi, 1/5, try 5] msi: Add OLE automation conformance test.
On 3/4/07, Misha Koshelev <[EMAIL PROTECTED]> wrote: Changes: Ok, try 5. This time there are five patches, as this first patch is a (moderately) comprehensive conformance test for MSI OLE automation, which checks all the functions that will be implemented, and does basic checks like set a property, then get it, is the property what we set it to? I hope this helps get it into git. These patches add partial OLE automation support for MSI and then add JScript/VBScript support for MSI (as the MSI specs specifically state that applications that need this functionality must install Windows Script themselves). As a proof of concept, sufficient automation support is added to conform to the conformance test and to fix bug #7357. Doesn't compile: ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole automation.o db.o format.o iface.o install.o msi.o package.o record.o suminfo.otestlist.o -o msi_test.exe.so ../../../libs/port/libwine_port.a -lcabinet -lmsi -lshell32 -lole32 -ladvapi32 -lkernel32 -luuid automation.o: In function `invoke': /home/truiken/wine/dlls/msi/tests/automation.c:389: undefined reference to `VariantInit' /home/truiken/wine/dlls/msi/tests/automation.c:404: undefined reference to `VariantClear' /home/truiken/wine/dlls/msi/tests/automation.c:398: undefined reference to `VariantChangeTypeEx' -- James Hawkins
Current wine and HL2 family - well done!
> without an annoying graphics glitch causing parts of skies to be > replaced with some bogus contents like white, black, mirrors of a part of > ground etc. Are you finding no errors at all? In Counter-Strike: Source, when running in anything above DX7 mode, on the map "de_aztec", the screen is often completely black - it appears to be when looking at water. ___ Inbox full of unwanted email? Get leading protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Re: Settlers II: 10th Anniversary regression?
On Sunday 04 March 2007 20:41, Markus wrote: > when trying the demo of the above game [... it quits ...] with the following > messages: > fixme:wininet:InternetSetOptionExA Flags 0400 ignored > fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT > (1000): STUB > fixme:wininet:InternetSetOptionExA Flags 0400 ignored > fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT not > supported on protocol 1 > err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process > heap section" wait timed out in thread 0009, blocked by 000d, retrying (60 > sec) > > Could this be a regression in DirectPlay? No, I really doubt that. dplay will not call wininet at all. Is there a bug report in bugzilla for this? Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpDX6Yske0gL.pgp Description: PGP signature
Re: Settlers II: 10th Anniversary regression?
Am Sonntag 04 März 2007 20:41 schrieb Markus: > Hi, > > when trying the demo of the above game ( > http://appdb.winehq.org/appview.php?iVersionId=5346 ) with 0.9.30, it loads > the main menu and allows you to enter a game. > In 0.9.32, it does not start anymore at all (it hangs after opening a > window) with the following messages: > fixme:wininet:InternetSetOptionExA Flags 0400 ignored > fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT > (1000): STUB > fixme:wininet:InternetSetOptionExA Flags 0400 ignored > fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT not > supported on protocol 1 > err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process > heap section" wait timed out in thread 0009, blocked by 000d, retrying (60 > sec) Unlikely, dplay is rather old. Can you do a regression test? Most likely one of my d3d patches killed it.
New opengl thread context selection patches for testing
Hi, Here is a new patchset for testing which implements duplicating gl contexts for new threads in wined3d. Again, it does not implement any synchronisation measures(except ENTER_GL and glFinish), so running multithreaded games is still kinda a lottery. This patchset also contains a patch for offscreen rendering, which may fix the problems introduced with TES: Oblivion before. This is just a format-patch of my git tree, the first 3 patches are unrelated. One of them is a clone of Henri's already sent patch, and the other 2 patches were sent by me already. Happy testing, Stefan threadsafetypatches.tar.bz2 Description: application/tbz
Settlers II: 10th Anniversary regression?
Hi, when trying the demo of the above game ( http://appdb.winehq.org/appview.php?iVersionId=5346 ) with 0.9.30, it loads the main menu and allows you to enter a game. In 0.9.32, it does not start anymore at all (it hangs after opening a window) with the following messages: fixme:wininet:InternetSetOptionExA Flags 0400 ignored fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (1000): STUB fixme:wininet:InternetSetOptionExA Flags 0400 ignored fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT not supported on protocol 1 err:ntdll:RtlpWaitForCriticalSection section 0x110020 "heap.c: main process heap section" wait timed out in thread 0009, blocked by 000d, retrying (60 sec) Could this be a regression in DirectPlay? Regards, -- Markus
Re: [PATCH 1/2] comctl32: Added getter-setter tests for the tab control (second attempt)
Lei Zhang wrote:
> On 3/3/07, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
>> The_Hagop wrote:
>> > +static void test_getters_setters(INT nTabs)
>> > +{
>> > +}
>> All your small functions should go inside this function. There is no
>> need to create 100 small functions that do 1-3 tests.
>
> I suggested breaking up the test into smaller functions to help
> improve readability. If he rolls all the code into this function,
> after applying part 2 of this patch, it would have created a 200 line
> function that's harder to understand and maintain.
I don't see nothing wrong with 200 lines function that does exactly the
same things over and over again. But creating 10 functions that do 5
checks each is pointless. That really makes it hard to read the test.
Also don't forget that all the tests run on the same control. So if you
change state of the control in one place, it will affect all the rest.
If you doing that, then they all should either create their own control
to test, or be all in one place.
Vitaliy
Re: [PATCH 1/2] comctl32: Added getter-setter tests for the tab control (second attempt)
On 3/3/07, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
The_Hagop wrote:
> +static void test_getters_setters(INT nTabs)
> +{
> +RECT rTab;
> +INT nTabsRetrieved;
> +INT rowCount;
> +
> +hTab = createFilledTabControl(TCS_FIXEDWIDTH, TCIF_TEXT|TCIF_IMAGE,
nTabs);
> +ok(hTab != NULL, "Failed to create tab control\n");
> +
> +SendMessage(hTab, TCM_SETMINTABWIDTH, 0, -1);
> +
> +/* Testing GetItemCount */
> +nTabsRetrieved = SendMessage(hTab, TCM_GETITEMCOUNT, 0, 0);
> +expect(nTabs, nTabsRetrieved);
> +
> +/* Testing GetRowCount */
> +rowCount = SendMessage(hTab, TCM_GETROWCOUNT, 0, 0);
> +expect(1, rowCount);
> +
> +/* Testing GetItemRect */
> +SendMessage(hTab, TCM_GETITEMRECT, 0 , (LPARAM) &rTab );
> +CheckSize(hTab, TAB_DEFAULT_WIDTH, -1 , "Default Width");
> +
> +test_getset_curFocus(hTab, nTabs);
> +test_getset_curSel(hTab, nTabs);
> +
> +test_getset_extendedStyle(hTab);
> +test_getset_unicodeFormat(hTab);
> +test_getset_item(hTab);
> +test_getset_tooltip(hTab);
> +
> +DestroyWindow(hTab);
> +}
All your small functions should go inside this function. There is no
need to create 100 small functions that do 1-3 tests.
I suggested breaking up the test into smaller functions to help
improve readability. If he rolls all the code into this function,
after applying part 2 of this patch, it would have created a 200 line
function that's harder to understand and maintain.
- Lei
Re: Current wine and HL2 family - well done!
Am Sonntag 04 März 2007 14:21 schrieb Pavel Troller: > Hi! > Normally I'm writing complaints here, so for a bit of compensation, I > would like to inform that yesterday's wine runs HL2 family of games for the > first time without an annoying graphics glitch causing parts of skies to be > replaced with some bogus contents like white, black, mirrors of a part of > ground etc. > So, many thanks to all the DirectX developers especially from my sons, > they are very pleased and wish you all the best, especially continuous > progress in wine development (a bit egocentric from them, but nice :-)) ). >With regards, Pavel Troller Yeah, finally no new regressions :-) The bug you describe used to happen because wine, by default, renders offscreen textures on the back buffer and then reads them back. Those parts of the back buffer touched by offscreen rendering that aren't redrawn will show the contents of the texture. It was possible to fix that by switching to pbuffer offscreen rendering before using a registry key. I modified the back buffer offscreen rendering to use GL_AUX0 if it is available, mainly to get better offscreen rendering on macos, which does not support glx pbuffers. The end idea is to use frame buffer objects. Support for that is there already, but it doesn't work with hl2 yet. pgpamuiM7sAM2.pgp Description: PGP signature
Current wine and HL2 family - well done!
Hi! Normally I'm writing complaints here, so for a bit of compensation, I would like to inform that yesterday's wine runs HL2 family of games for the first time without an annoying graphics glitch causing parts of skies to be replaced with some bogus contents like white, black, mirrors of a part of ground etc. So, many thanks to all the DirectX developers especially from my sons, they are very pleased and wish you all the best, especially continuous progress in wine development (a bit egocentric from them, but nice :-)) ). With regards, Pavel Troller
Re: gdi32: Add a EnumFontFamilies test, make it pass under Wine. Try 2
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote: this patch should fix the problem reported in the bug #7571. This version of the patch adds a test for the case of enumerating "Symbol"-like fonts (pointed out by Huw), and makes it pass under Wine as well. Changelog: gdi32: Add a EnumFontFamilies test, make it pass under Wine. Please do not commit this patch, according to the comments in the bug above it needs more work. -- Dmitry.
