Re: Current wine and HL2 family - well done!
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). To say even more - with this new version all the random buffers that were displayed are finaly gone, so there's no more strange looking side effects on this map (especially at the bomb spot over at the ramp near the watter). I've also made a test using UseGLSL=enabled, and the water looks perfect, tho the barrels seem overly shiny - same goes for the weapons the player is holding. I think there may be a texture stage missisng, tho everything else seems almost perfect (and with 16xAA looks amazingly well, with not much of a speed impact at 800x600). -- Best regards Wojciech Arabczyk
Writing IDL and other definition files
I am looking at writing a piece of IDL and a header file I am wrestling with how to do it without infringing copyright. IDL looks particularly hard to write from first principles and is probably hard to write in a different way as the functions being implemented are defined and require IDL similar code. Is there any advice as to what type of code can be copied and what constitutes a rewrite to avoid copyright? Jeff
Re: Current wine and HL2 family - well done!
Could any of you test again with: OffscreenRenderingMode=fbo turned on? fbos are broken with half life 2. It is broken because it uses a different depth stencil buffer size than the color buffer size. I just turned that off (so it defaulted to backbuffer), and the problem actually went away. I had this turned on because it seemed to with problems with other games though. Which offscreenrenderingmode should be giving the best performance/compatibility? For half-life 2 I'd suggest back buffer for now because nowadays it renders on AUX buffers which is faster than the context switch for pbuffers. Once fbos work with that game they should be used. pgpjEjK7tdnjU.pgp Description: PGP signature
Visualizing skip on test.winehq.org (and getting rid of visible desktop border)
Hi, currently all tests on test.winehq.org show the blue border to indicate the test is running on a visible desktop. I think we can get rid of this one as winetest will not run if we don't have a visible desktop. My idea is to visualize the skipped tests by using the blue border at the single test level to indicate tests are skipped (see attached picture). Comments, idea's, thoughts? Cheers, Paul.
Re: Writing IDL and other definition files
Jeff L wrote: I am looking at writing a piece of IDL and a header file I am wrestling with how to do it without infringing copyright. IDL looks particularly hard to write from first principles and is probably hard to write in a different way as the functions being implemented are defined and require IDL similar code. Is there any advice as to what type of code can be copied and what constitutes a rewrite to avoid copyright? Obviously, the function names and parameter order and types have to be the same. The function attributes also have to be the same. However, the order of attributes, indentation and the parameter names can be different. -- Rob Shearman
Re: Writing IDL and other definition files
Robert Shearman wrote: Jeff L wrote: I am looking at writing a piece of IDL and a header file I am wrestling with how to do it without infringing copyright. IDL looks particularly hard to write from first principles and is probably hard to write in a different way as the functions being implemented are defined and require IDL similar code. Is there any advice as to what type of code can be copied and what constitutes a rewrite to avoid copyright? Obviously, the function names and parameter order and types have to be the same. The function attributes also have to be the same. However, the order of attributes, indentation and the parameter names can be different. Seems too simple but I will give it a whirl.
Re: Settlers II: 10th Anniversary regression?
On Sunday 04 March 2007 23:24, Markus wrote:
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'
[...]
Ok, got compiling to work. The Wiki was quite far off as to which settings are
needed for compiling under 64bit SUSE.
Anyway, the patch that stopped the demo from starting seems to be this one (I
only checked dlls/wined3d patches):
---
401110538aa39214280367725f2d8cb80abbc3da is first bad commit
commit 401110538aa39214280367725f2d8cb80abbc3da
Author: Stefan Dösinger [EMAIL PROTECTED]
Date: Mon Feb 19 15:18:45 2007 +0100
wined3d: Check volume texture creation errors.
Volumetexture::Release checks for NULL pointers, so releasing a partially
created texture works.
:04 04 f7e20f7cadd15cfd36f8d997615d5c24f5a2e921
2a25e3f59b0cbff4adcce0b372326da6e7389dcd M dlls
---
Apparently there is another patch that went in between 0.9.30 and .31 that
causes an Invalid call error message to show after the start screen. I'll
do a test for that later.
Regards,
--
Markus
Re: secur32: NTLM's AcquireCredentialHandleA/W should accept domains and usernames with lengths of 0.
On Monday 05 March 2007 13:02, Robert Shearman wrote:
+ if(pQuerySecurityPackageInfoA(sec_pkg_name, pkg_info) != SEC_E_OK)
+ {
+ trace(NTLM package not installed, skipping test\n);
+ return;
+ }
I've just started using skip() for skipping tests.
Cheers,
Kai
--
Kai Blin, kai Dot blin At gmail Dot com
WorldForge developerhttp://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin/
--
Will code for cotton.
pgpYQNq1blTEZ.pgp
Description: PGP signature
Re: secur32: NTLM's AcquireCredentialHandleA/W should accept domains and usernames with lengths of 0.
Kai Blin wrote:
On Monday 05 March 2007 13:02, Robert Shearman wrote:
+if(pQuerySecurityPackageInfoA(sec_pkg_name, pkg_info) != SEC_E_OK)
+{
+trace(NTLM package not installed, skipping test\n);
+return;
+}
I've just started using skip() for skipping tests.
Ok. I'll fix this and send this patch again. I'm going to send previous
patch again anyway because I've just spotted a bug in it.
--
Rob Shearman
Re: Settlers II: 10th Anniversary regression?
On Monday 05 March 2007 15:23, Markus wrote: Ok, got compiling to work. The Wiki was quite far off as to which settings are needed for compiling under 64bit SUSE. The X libraries moved elsewhere in openSUSE 10.2. Fixes to the Wiki welcome. Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpXjkG4jZuLH.pgp Description: PGP signature
Re: Settlers II: 10th Anniversary regression?
On Mon, Mar 05, 2007 at 03:23:39PM +0100, Markus wrote:
On Sunday 04 March 2007 23:24, Markus wrote:
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'
[...]
Ok, got compiling to work. The Wiki was quite far off as to which settings
are
needed for compiling under 64bit SUSE.
I reviewed and adjusted the page a bit.
Ciao, Marcus
Re: Settlers II: 10th Anniversary regression?
Marcus Meissner [EMAIL PROTECTED] wrote: Ok, got compiling to work. The Wiki was quite far off as to which settings are needed for compiling under 64bit SUSE. I reviewed and adjusted the page a bit. Marcus, you seem to be a knowledgeable person how to set up X11 in a 64-bit environment. Perhaps you have a clue what might be needed to properly setup locale support in that case? See for instance the bug http://bugs.winehq.org/show_bug.cgi?id=4704 -- Dmitry.
Re: Settlers II: 10th Anniversary regression?
On Mon, Mar 05, 2007 at 11:53:07PM +0800, Dmitry Timoshkov wrote: Marcus Meissner [EMAIL PROTECTED] wrote: Ok, got compiling to work. The Wiki was quite far off as to which settings are needed for compiling under 64bit SUSE. I reviewed and adjusted the page a bit. Marcus, you seem to be a knowledgeable person how to set up X11 in a 64-bit environment. Perhaps you have a clue what might be needed to properly setup locale support in that case? See for instance the bug http://bugs.winehq.org/show_bug.cgi?id=4704 I never had any problems setting it up, in fact it just worked all the time :( So I am likely not of much help. Ciao, Marcus
Re: Current wine and HL2 family - well done!
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). To say even more - with this new version all the random buffers that were displayed are finaly gone, so there's no more strange looking side effects on this map (especially at the bomb spot over at the ramp near the watter). I've also made a test using UseGLSL=enabled, and the water looks perfect, tho the barrels seem overly shiny - same goes for the weapons the player is holding. I think there may be a texture stage missisng, tho everything else seems almost perfect (and with 16xAA looks amazingly well, with not much of a speed impact at 800x600). Hi! I've made also the glsl test. The same problem is here - there is too much shine all over the game. Not only barrels and weapons, but also faces, dresses, walls.. It looks like covered by the oil film. There are also some strange shadow effects - like that the top of the hand is dark and the bottom is bright, like if the light would come from the ground. And all this is of course much slower, doing about 8 - 10 fps on 1024x768. But yes, the water is really perfect. So we turned glsl off again, it seems that it really still needs some work. With regards, Pavel Troller
Re: Settlers II: 10th Anniversary regression?
On Monday 05 March 2007 15:55, Kai Blin wrote: Ok, got compiling to work. The Wiki was quite far off as to which settings are needed for compiling under 64bit SUSE. The X libraries moved elsewhere in openSUSE 10.2. Fixes to the Wiki welcome. I already updated the Wiki to reflect the settings I had to use under 10.2. -- Markus
Re: Settlers II: 10th Anniversary regression?
Marcus Meissner [EMAIL PROTECTED] wrote: Marcus, you seem to be a knowledgeable person how to set up X11 in a 64-bit environment. Perhaps you have a clue what might be needed to properly setup locale support in that case? See for instance the bug http://bugs.winehq.org/show_bug.cgi?id=4704 I never had any problems setting it up, in fact it just worked all the time :( So I am likely not of much help. Well, at least you could just describe how it's set up in your system. It appears that some systems don't provide locale support in an emulated 32-bit environment at all. -- Dmitry.
Re: Settlers II: 10th Anniversary regression?
On Mon, Mar 05, 2007 at 05:11:10PM +0100, Markus wrote: On Monday 05 March 2007 15:55, Kai Blin wrote: Ok, got compiling to work. The Wiki was quite far off as to which settings are needed for compiling under 64bit SUSE. The X libraries moved elsewhere in openSUSE 10.2. Fixes to the Wiki welcome. I already updated the Wiki to reflect the settings I had to use under 10.2. -m32 is fully automatic detected in configure, it is not necessary to mention. Ciao, Marcus
Re: Settlers II: 10th Anniversary regression?
Dmitry Timoshkov [EMAIL PROTECTED] wrote: Marcus, you seem to be a knowledgeable person how to set up X11 in a 64-bit environment. Perhaps you have a clue what might be needed to properly setup locale support in that case? See for instance the bug http://bugs.winehq.org/show_bug.cgi?id=4704 I never had any problems setting it up, in fact it just worked all the time :( So I am likely not of much help. Well, at least you could just describe how it's set up in your system. It appears that some systems don't provide locale support in an emulated 32-bit environment at all. A follow up: a working solution for a 64-bit system was posted in the bug above: quote Eventually I found the suitable hint here http://ubuntuforums.org/showpost.php?p=2160001postcount=11 : For whatever reason the respective environment variable is no longer being called XLOCALEDIR but instead XLOCALELIBDIR... :-( When setting export XLOCALELIBDIR=/usr/lib32/X11/locale everything works. /quote -- Dmitry.
Re: Current wine and HL2 family - well done!
Hello 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). To say even more - with this new version all the random buffers that were displayed are finaly gone, so there's no more strange looking side effects on this map (especially at the bomb spot over at the ramp near the watter). I've also made a test using UseGLSL=enabled, and the water looks perfect, tho the barrels seem overly shiny - same goes for the weapons the player is holding. I think there may be a texture stage missisng, tho everything else seems almost perfect (and with 16xAA looks amazingly well, with not much of a speed impact at 800x600). -- Best regards Wojciech Arabczyk
Re: Current wine and HL2 family - well done!
--- Stefan Dösinger [EMAIL PROTECTED] wrote: 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 Could any of you test again with: OffscreenRenderingMode=fbo turned on? I just turned that off (so it defaulted to backbuffer), and the problem actually went away. I had this turned on because it seemed to with problems with other games though. Which offscreenrenderingmode should be giving the best performance/compatibility? ___ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
Re: HtmlHelp status, winecfg and SoC proposal
* On Sun, 4 Mar 2007, Jacek Caban wrote: 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). Quoting Paul Wise resume from the [1]: | Started off hacking on frhed (a windows hex editor) | Made some lame/unfinished patches for POV-Ray | Wrote some tiny windows software | Wrote chmdeco/hhm/chmspec | Been hacking on activismo for a while | Looking forward to getting ADSL contributing to xCHM, possibly WINE, GNOME, random projects. | I'd also like to become a debian developer at some stage. Paul seems to be excited about Wine, so hhm relicensing should sound OK for him, IMHO. But only if proved it isn't breaking M$ licences [2], right? 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? Nice idea. Maybe even Paul himself would join that, as he states in his blog [3] he needs Employment, bux, moolah, work. (I've Bcc-ed Paul in his message) [1] http://savannah.nongnu.org/projects/hhm [2] http://msdn.microsoft.com/library/en-us/htmlhelp/html/hwhtmlhelpend-userlicenseagreement.asp [3] http://bonedaddy.net/pabs3/
Re: 0001-server-main.c-fixed-command-line-parsing-using-GNU-getopt
Srivatsa Kanchi, R [EMAIL PROTECTED] wrote: replaced the custom 'parse_args' function with GNU getopt And what's wrong with current parser, except it being custom? applied some coding style to limit code 80 characters /line Please leave existing style alone, even if you don't like it. -- Dmitry.
Re: Current wine and HL2 family - well done!
Hi! I've made also the glsl test. The same problem is here - there is too much shine all over the game. Not only barrels and weapons, but also faces, dresses, walls.. It looks like covered by the oil film. There are also some strange shadow effects - like that the top of the hand is dark and the bottom is bright, like if the light would come from the ground. And all this is of course much slower, doing about 8 - 10 fps on 1024x768. But yes, the water is really perfect. So we turned glsl off again, it seems that it really still needs some work. With regards, Pavel Troller Well, the thing with glsl is that hl2 switches to dxlevel 90, and uses some more advanced d3d features. The main problem are sRGB read and write support(sort of gamma correction). The missing read support causes the overbright stuff, and the write support makes everything a bit darker. In Episode one and Lost coast high dynamic range rendering is turned on too. This doesn't look correct either, and is much slower(on windows too). If changing the fsaa setting in hl2 changes anything that is just imagination - it doesn't do anything yet, the multisample setting is just ignored right now. pgpx2KPbAohwp.pgp Description: PGP signature
Re: Problems with Alice
After considerable digging the problems with sound in Alice were traced to a bad software load. While digging another thing came to our attention that may be of interest to others. When we put in the latest fixes to FC6 Wine quit running. This was traced to the fact that the latest fixes contain a set of fixes for the X server and replace the open GL library. The drivers posted by Nvidia, which were installed, have their own GL library and will not work with the RH GL library. If you install an update to FC and are using the Nvidia drivers reinstall the drivers if things in the X server quit working. This is true even if the kernel version is not changed.
Re: fc4 rpms
В сообщении от 28 февраля 2007 05:17 Bill Medland написал(a): Is there any chance that someone with the ability can create the fedora core 4 wine rpms for version 0.9.30? http://ftp.freesource.info/etersoft/WINE%40Etersoft-1.0/WINE/FedoraCore/4/ Bill Medland -- Lav Виталий Липатов Россия, Санкт-Петербург. www.etersoft.ru GNU! ALT Linux Team! WINE! WIKI! LaTeX! LyX!
Re: Visualizing skip on test.winehq.org (and getting rid of visible desktop border)
Paul Vriens [EMAIL PROTECTED] writes: My idea is to visualize the skipped tests by using the blue border at the single test level to indicate tests are skipped. Hey, I like it! That blue border was already obsolete when I last touched the code, but I found it so neat that I couldn't kill it off. ;) -- Feri.
Re: Current wine and HL2 family - well done!
On Mar 5, 2007, at 12:00 PM, Stefan Dösinger wrote: Hi! I've made also the glsl test. The same problem is here - there is too much shine all over the game. Not only barrels and weapons, but also faces, dresses, walls.. It looks like covered by the oil film. There are also some strange shadow effects - like that the top of the hand is dark and the bottom is bright, like if the light would come from the ground. And all this is of course much slower, doing about 8 - 10 fps on 1024x768. But yes, the water is really perfect. So we turned glsl off again, it seems that it really still needs some work. With regards, Pavel Troller Well, the thing with glsl is that hl2 switches to dxlevel 90, and uses some more advanced d3d features. The main problem are sRGB read and write support(sort of gamma correction). The missing read support causes the overbright stuff, and the write support makes everything a bit darker. Is UseGLSL=enabled and -dxlevel 80 a meaningful combination that produces better results? -Ken
Re: Current wine and HL2 family - well done!
Hello If changing the fsaa setting in hl2 changes anything that is just imagination - it doesn't do anything yet, the multisample setting is just ignored right now. I've not changed the FSAA setting trough the game options. I've forced it on a lower level, that is on the graphics card driver level (using nvidia-settings). So it's not _just_ my imagination. The main problem are sRGB read and write support(sort of gamma correction). I suppose it's the last real thing to make Source-engine based games look perfect on Wine. Could i be of any help? I cannot program (a complete lack of C/C++ skills, bumer :( ), but i can do some extensive patch testing. -- Best regards Wojciech Arabczyk
Re: Visualizing skip on test.winehq.org (and getting rid of visible desktop border)
On Mo, 2007-03-05 at 12:07 +0100, Paul Vriens wrote: My idea is to visualize the skipped tests by using the blue border at the single test level to indicate tests are skipped (see attached picture). Comments, idea's, thoughts? Nice Idea. -- By by ... Detlef
Working on DIBEngine for SOC
Hello everyone. I'm thinking about participating in the Google SOC 2007. Given that Wine in one of my favorite Open Source projects I find interesting the idea of implementing the DIBEngine. In the past I've worked in some Open Source projects, one of them QT-Win32 and also I did little contributions to the OFC (Open Foundation Class). I've experience with C coding, mostly from working on Educational OS like GeekOS and PintOS. From what I understood the hard part of this project is INTEGRATION. I mean integrating the new code into the Wine repository without breaking everything? Am I right? About the drawing code, I read that is possible to use the X11 code, also the ReactOS code and the old Transgaming DIBEngine (incomplete). Is that correct? Waiting for your comments and ideas. Regards, Ivan
Re: Current wine and HL2 family - well done!
Wojciech 'arab' Arabczyk wrote: Hello If changing the fsaa setting in hl2 changes anything that is just imagination - it doesn't do anything yet, the multisample setting is just ignored right now. I've not changed the FSAA setting trough the game options. I've forced it on a lower level, that is on the graphics card driver level (using nvidia-settings). So it's not _just_ my imagination. The main problem are sRGB read and write support(sort of gamma correction). I suppose it's the last real thing to make Source-engine based games look perfect on Wine. Could i be of any help? I cannot program (a complete lack of C/C++ skills, bumer :( ), but i can do some extensive patch testing. Don't worry, I'm working on sRGB read and write support right now :D I'm not sure when it will be completed but you'll see something soon (next few days / weeks) Regards, Phil.
Re: Current wine and HL2 family - well done!
Am Montag 05 März 2007 20:14 schrieb Ken Thomases: Is UseGLSL=enabled and -dxlevel 80 a meaningful combination that produces better results? It should produce the same results as ARB and 80. (I know it doesn't work on the mac though. The mac falls back to sw rendering) pgpAhouItZvX0.pgp Description: PGP signature
Re: mingw linking problem
Am Tuesday 27 February 2007 19:43 schrieb Paul Millar: Hi Stefan, On Sunday 25 February 2007 18:13, Stefan Leichter wrote: This fail for some dlls at the linking, eg. comdlg32.dll misses the imports _IID_IContextMenu, _IID_IShellFolder, _IID_IPersistFolder2, _IID_IShellBrowser, _IID_ICommDlgBrowser, _IID_IShellView, These are part of the MinGW's W32api v3.8. I don't know how long they've been in W32api, so you may need to upgrade to this version. _SID_STopLevelBrowser This was a stupid error in my hand edited patch The set of patches I have includes a definition for this GUID (as well as many, many others). The complete set of patches (against w32api v3.8) is available from: http://www.astro.gla.ac.uk/users/paulm/Cross/mingw-w32api-patches-2007-02-2 7.tar.gz Using a MinGW tool-chain (that has these patches) I was able to build comdlg32.dll Hello Paul, can you build comdlg32.dll if you have shell32.dll? If i run make clean in shell32 directory comdlg32.dll builds fine for me. If shell32 is there from a previous build, comdlg32.dll fails for me with the problems described above. In short it can be said this way: comdlg32.dll needs to be build shell32.dll and libuuid.a from mingw or from wine, but the two files must be used from one source either wine or mingw. It is not possible to use one file from wine and one file from mingw. But this happend for me currently When i build wine with mingw the Makefile uses shell32.dll from wine and libuuid from mingw. This gives me the uinresolved symbols. Bye Stefan
Re: mingw linking problem
Stefan Leichter wrote: Am Tuesday 27 February 2007 19:43 schrieb Paul Millar: On Sunday 25 February 2007 18:13, Stefan Leichter wrote: The set of patches I have includes a definition for this GUID (as well as many, many others). The complete set of patches (against w32api v3.8) is available from: http://www.astro.gla.ac.uk/users/paulm/Cross/mingw-w32api-patches-2007-02-2 7.tar.gz Using a MinGW tool-chain (that has these patches) I was able to build comdlg32.dll can you build comdlg32.dll if you have shell32.dll? If i run make clean in shell32 directory comdlg32.dll builds fine for me. If shell32 is there from a previous build, comdlg32.dll fails for me with the problems described above. In short it can be said this way: comdlg32.dll needs to be build shell32.dll and libuuid.a from mingw or from wine, but the two files must be used from one source either wine or mingw. It is not possible to use one file from wine and one file from mingw. But this happend for me currently When i build wine with mingw the Makefile uses shell32.dll from wine and libuuid from mingw. This gives me the uinresolved symbols. dumpbin shows that the shell32 import library in the PSDK includes a number of GUID symbols, which we don't currently include in the one generated by Wine. It would appear that at least some of these are also included in the uuid library too, but I don't know why they would be missing from MinGW. -- Rob Shearman
Re: Current wine and HL2 family - well done!
Hello Don't worry, I'm working on sRGB read and write support right now :D I'm not sure when it will be completed but you'll see something soon (next few days / weeks) That's great news! Keep 'em comming ;-) -- Best regards Wojciech Arabczyk
Re: Working on DIBEngine for SOC
Am Montag 05 März 2007 21:35 schrieb Ivan de Jesus Deras Tabora: Hello everyone. I'm thinking about participating in the Google SOC 2007. Given that Wine in one of my favorite Open Source projects I find interesting the idea of implementing the DIBEngine. In the past I've worked in some Open Source projects, one of them QT-Win32 and also I did little contributions to the OFC (Open Foundation Class). I've experience with C coding, mostly from working on Educational OS like GeekOS and PintOS. Great! About the drawing code, I read that is possible to use the X11 code, also the ReactOS code and the old Transgaming DIBEngine (incomplete). Is that correct? I think ReactOS is not legally safe, but IANAL. pgpz6if0WtdaN.pgp Description: PGP signature
RE: Working on DIBEngine for SOC
Ivan de Jesus Deras Tabora [mailto:[EMAIL PROTECTED] wrote: Welcome here, Ivan! From what I understood the hard part of this project is INTEGRATION. I mean integrating the new code into the Wine repository without breaking everything? Am I right? Yes this will be a challenge and it is not about not breaking EVERYTHING but actually ANYTHING! :-) The best person to mentor that would be probably Alexander but I think he said he found this not a good SoC project. About the drawing code, I read that is possible to use the X11 code, also the ReactOS code and the old Transgaming DIBEngine (incomplete). X11 is certainly possible but would need quite some love as it is not exactly known for readibility. ReactOS you better don't mention here in Wine. As long as ReactOS has not been fully audited from an independent organization to not contain any copied code not under a compatible open source license, Wine will not accept any code that looks or even has the slightest suspicion that it might be from ReactOS. That would IMO only explicitedly exclude the code for the automatically code generated files for the optimalized DIB operations from Ge van Geldorp, which he states he did develop all on his own and can't be copied since Microsoft does not do it in such a way. And then you would need to get them from him and not the ReactOS tree. He said he was ok with them being used in Wine. The Transgaming DIB engine is a start but is still far from complete. And I personally don't think it should be done in the X11 driver as that will require to do the same work in the quartz driver again and any other graphics display driver that may come up in the future. Basically it will be unmaintainable once there is more than one possible display driver in Wine. Rolf Kalbermatter
Re: AppDB performance issue
Mandag 05 mars 2007 03:27, skrev Nick Law: 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 ? I am also suffering from the problem. If no one except for the administrators are seeing this issue, then it has to be the administration bar that is causing the problems, otherwise it could also be a problem with sessions. So my questions is Is anyone except for the administrators seeing this issue? Regards, Alexander N. Sørnes 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: Current wine and HL2 family - well done!
--- Stefan Dösinger [EMAIL PROTECTED] wrote: For half-life 2 I'd suggest back buffer for now because nowadays it renders on AUX buffers which is faster than the context switch for pbuffers. Once fbos work with that game they should be used. Thanks - backbuffer indeed works fine with HL2/CSS, and is faster than pbuffers. Setting hl2.exe to use that, but leaving fbo as the global setting seems to work nicely. ___ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
Re: AppDB performance issue
On 3/5/07, Alexander Nicolaysen Sørnes [EMAIL PROTECTED] wrote: Mandag 05 mars 2007 03:27, skrev Nick Law: 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 ? I am also suffering from the problem. If no one except for the administrators are seeing this issue, then it has to be the administration bar that is causing the problems, otherwise it could also be a problem with sessions. So my questions is Is anyone except for the administrators seeing this issue? I may be seeing this issues on my local test setup as well. A great tool that I would recommend is xdebug. http://www.xdebug.org/docs-profiling.php This produces profiling output that is parsed by kcachegrind. I'll see if I can get xdebug setup on my local install tonight, it should be easy to spot once that is working. Chris
Code audit (was: Re: Working on DIBEngine for SOC)
On 05.03.2007 22:57, Rolf Kalbermatter wrote: ReactOS you better don't mention here in Wine. As long as ReactOS has not been fully audited from an independent organization to not contain any copied code not under a compatible open source license, Wine will not accept any code that looks or even has the slightest suspicion that it might be from ReactOS. BTW, has the Wine code audit ever been finished or was it just aborted when media attention faded? The last statement I found was from Alexandre in March 2006 where he stated that 50% of the code were covered. Regards, Carl-Daniel
Re: Code audit
BTW, has the Wine code audit ever been finished or was it just aborted when media attention faded? The last statement I found was from Alexandre in March 2006 where he stated that 50% of the code were covered. The code audit continues. However, the SFLC has turned its attention to building a set of tools to make it easier to automate the audit, and to drive for 100% coverage. The first prototypes are done, now it's just a matter of setting up web servers and infrastructure and getting the kinks out. So, in short, it is ongoing, if slowly. Cheers, Jeremy
Re: Settlers II: 10th Anniversary regression?
On Monday 05 March 2007 17:30, you wrote: I already updated the Wiki to reflect the settings I had to use under 10.2. -m32 is fully automatic detected in configure, it is not necessary to mention. I cannot confirm this. When not setting -m32 manually, I am getting the previously posted assembler message errors. In fact, when specifying it under CFLAGS only, the linker would try to create a 64bit library out of the 32bit object files. Thus LDFLAGS needed -m32 as well. -- Markus
Re: HtmlHelp status, winecfg and SoC proposal
[please CC me on replies, I'm not subscribed to wine-devel] On Mon, 2007-03-05 at 19:30 +0200, Saulius Krasuckas wrote: * On Sun, 4 Mar 2007, Jacek Caban wrote: 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). Quoting Paul Wise resume from the [1]: Eeep, haven't updated that in years. Just deleted it and replaced with a link to my homepage. Paul seems to be excited about Wine, so hhm relicensing should sound OK for him, IMHO. I've previously offered to relicence the hhm code for inclusion in both chmlib and libmspack, but it seems neither project took up this offer. I don't think the hhm code belongs anywhere other than in one of them. The current version was more of a proof-of-concept, I wanted to push the code into a chm reading/writing library. IIRC, wine's itss.dll uses libmspack, so perhaps it should go there? Also, if it does get included, I'd *STRONGLY* request/suggest that the code be modified to also include a README.hhm.txt (or similar) file saying something like This file was not produced by Microsoft's HtmlHelp compiler, it may have incompatibilities preventing it from being used on Windows. I think this is an important inclusion in any non-MS compiler, one which I haven't got around to adding to hhm yet. I've also previously (2003) pointed wine-devel at chmspec and offered to relicence chmdeco code for use in a wine version of hh.exe. No-one was interested though, saying that a CHM viewer was already implemented and then deteriorating into a thread about which browser to embed and forking KHTML and Mozilla and so on. But only if proved it isn't breaking M$ licences [2], right? The licence says this: * Limitations on Reverse-Engineering, Decompilation, and Disassembly. You may not reverse- engineer, decompile, or disassemble the SOFTWARE PRODUCT, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation. As written in the chmspec colophon, I didn't do any disassembly of Microsoft stuff, only black-box format discovery. Mainly this was by sending different inputs to Microsoft's hhc and observing the output, as well as looking at existing samples of CHM files. I imagine that is probably reverse-engineering according to Microsoft (although they haven't contacted me at all, so maybe not). http://chmspec.nongnu.org/latest/Colophon.html Nice idea. Maybe even Paul himself would join that, as he states in his blog [3] he needs Employment, bux, moolah, work. (I've Bcc-ed Paul in his message) I'm not a student, so I'm not eligible to implement that project as part of the SoC. If people want to pay me privately, that would be great since I'm in need of work at the moment. I'm happy to answer questions that come up in the SoC in relation to chmspec though. Frankly I haven't done anywhere near enough reverse engineering of the internal CHM formats to even be close to thinking about implementing a full-blown CHM compiler that would create correct CHMs. There is enough info for CHM readers like chmdeco, xCHM and so on to be written, but not for compilers. Patches to chmspec are welcome though :) Why does wine want a CHM compiler anyway? Can't Microsoft's one be used? Microsoft's one isn't distributed with the OS anyway. Also, Matthew's ITSF (the container format built and read by itss.dll) spec has a few bugs that I did a bit of work on while I was sailing, haven't done anything recently on them though, I'm hoping to get to that soon. Also, there is some bug in the chmlib/hhm/lzx_comp combination that causes xCHM and other chmlib based CHM viewers to crash when accessing CHMs created using hhm (linked against lzx_comp), this needs investigating and hhm/lzx_comp should not be used until it is. -- bye, pabs http://pabs.zip.to signature.asc Description: This is a digitally signed message part
Re: Settlers II: 10th Anniversary regression?
On Tuesday 06 March 2007 05:02, Markus wrote: On Monday 05 March 2007 17:30, you wrote: I already updated the Wiki to reflect the settings I had to use under 10.2. -m32 is fully automatic detected in configure, it is not necessary to mention. I cannot confirm this. When not setting -m32 manually, I am getting the previously posted assembler message errors. In fact, when specifying it under CFLAGS only, the linker would try to create a 64bit library out of the 32bit object files. Thus LDFLAGS needed -m32 as well. Just a wild guess here, but have you got your CC environment variable set? wine's configure uses the CC, LD and AS variables to set -m32 (or equivalent options). It does not, however overwrite the variables if they exist.
