Re: wined3d: fix a compiler warning
2009/6/24 Michael Stefaniuc : > Pierre Bourdon wrote: >> >> I think what Michael meant is that >> sprintf(a, "%s", b); >> >> is doing exactly the same thing as >> strcpy(a, b); > Right, that's what I meant. > >> in a less efficient way. > I'm not that much concerned about efficiency as the compiler will > optimize it. But a strcpy is definitely easier to read. I tend to assume that the compiler is an idiot that doesn't know a thing about optimisation, but that's me (e.g. using fputs for printing a string constant instead of fprintf). I find it makes for more readable/lean code.
Re: [1/3] [wined3d] add ps_np2fixup_info structure (resend)
Am Wednesday 24 June 2009 17:51:44 schrieb Tobias Jakobi: The patches look ok to me
Shameless call for game testing
Hi, I need some help for people who spectate this list and use Wine mostly for gaming. In the past weeks, I have improved our ARB shader backend to support Shader Model 3.0 on cards that support GL_NV_vertex_program3 and GL_NV_fragment_program2(Geforce 6+), and 2.0 on other cards that have support for the needed shader constants(ATI Radeon 9500+, intel chips). What is this good for: *) Works better on platforms with bad GLSL support, like Macs and Mesa *) Deal with some corner cases, like texldd support on dx9 nvidia cards *) Slightly better performance in some games However, GLSL is the default right now, and we don't want to change this anytime soon, but I'd still like to get some testing of the ARB code. So I'd be happy if some people could disable GLSL(HKEY_CURRENT_USER/Software/Wine/Direct3D/UseGLSL="disabled") and see how their games work? In the ideal world, the results are like this: *) Everything that works with GLSL works with ARB on NV cards *) The ARB backend is slightly faster(I've seen approx. +10%) Can you test your games, and if something does not work that works with GLSL file a bug and assign it to me? Also please file a bug if there is a noticeable performance loss, or if ARB is MUCH faster(hints towards a GLSL shader code bug). If the game runs just fine, feel free to reply to this mail with your results and GLSL performance comparisons. Note that ATI cards do not support SM 3.0 with ARB. This is NOT a bug. Those cards just don't have any extensions that provide the additional features with ARB shaders, so you have to use GLSL there if you need SM 3.0. Thanks for your help, Stefan
Re: italian translations for winecfg
Davide Pizzetti wrote: i've got a question: how i produce a patch with 'git diff'? what is the correct syntax of the command? Il giorno mer, 24/06/2009 alle 19.17 +0400, Nikolay Sivov ha scritto: Davide Pizzetti wrote: Here are the italian translations for winecfg. 1. Use 'git diff' format to produce patches 2. Use plain text attachments. Feel free to ask here any related questions Actually it's a correct format itself: 'git diff' from a git-tree. If you did commits to your local tree use 'git format-patch' as described http://www.winehq.org/sending_patches 'git format-patch --stdout --keep-subject origin' this will output all local commits with info headers. If you didn't commit you could just use 'git diff' output which will contain all changes from current head. Also add a more descriptive subject, something like: 'winecfg: Update Italian resources' with module you're working on as a prefix. Note that your attachment should be plain text without any additional formatting (no html messages, no wrapping).
Re: italian translations for winecfg
Davide Pizzetti wrote: Here are the italian translations for winecfg. 1. Use 'git diff' format to produce patches 2. Use plain text attachments. Feel free to ask here any related questions.
Re:
2009/6/24 Austin English : > -releaseObjects(); > +releaseObjects(); > } > > Now sure why that was changed...did you accidentally change the > encoding or something? > The change adds trailing spaces.
Re:
2009/6/24 Pavel Procházka : Howdy Pavel, A few minor things: A) Please use a descriptive subject, and put your message in the e-mail body. It's easier for those that don't read every patch but only care about certain areas to skim the mailing list that way. Also, it's hard to search the archives when there's no subject on the e-mail. B) +/*MULTIBUFFERING PART*/ It's not a huge deal, but please add spaces around comments, they're hard to read that way. C) @@ -2716,5 +2909,5 @@ START_TEST(visual) return ; cleanup: -releaseObjects(); +releaseObjects(); } Now sure why that was changed...did you accidentally change the encoding or something? -- -Austin
Re: Re: wine compatible logo needed
On Wed, Jun 24, 2009 at 1:50 AM, M. Stefanov wrote: > You're right. I'll use the full version. And an electronic manual wouldn't > be practical in my case. > > Which is: > > begin > > "We need this." > > repeat > > "Is this what you need?"; > > "No, modify"; > > Mod_soft; > > until Response = "OK, this is it."; > > write(manual); > > burn(CD); > > install_all; > > end. > > So basically it's the end of the development cycle for that specifical > program. > > That's why I think to specify the particular version of wine and linux > distro that I'm certain it works with and throw in a note that experiences > with other wine versions / linux distros / different OS may be different > (with other words of course). > > And when/if the time comes for a v 2.0 of my soft, I'll test that against > the latest wine that exists at the time of 2.0 release, and if it works, do > the same with the 2.0 manual. > > Basically I was asking if there was a pre-existing template for such a case > - a finished program which works out-of-the-box under wine at the time of > the soft finalization... Instead of specifying what it's supposed to work with, why not just bundle wine with your app? That way they always have 'the' working version. -- -Austin
Re: free software replacement for MFC?
Karl Berry schrieb: In the course of reviewing some possible projects for GNU, Richard Stallman asked me if there was any active work going on to write a free software replacement for MFC. From the MFC pages I found on the Wine web site (http://www.winehq.org/docs/winelib-guide/mfc), which talk about ways of working with the Microsoft classes and don't mention any alternatives, I gather this isn't a current goal of Wine itself. But still, I figured that this would be the most likely place for any such project would be known about, or even find possible developers if one was to be started. Looking on the web, all I found was the old ofc.sf.net, which appears not to have gotten very far and to have been abandoned years ago, judging from the source repository. The other projects I came across, such as wxWidgets and SmartC++, appear not to try to be a compatible replacement for MFC, but rather a functional alternative. If anyone here has corrections, additions, suggestions related to those, I'd be grateful for any replies. Thanks, k...@gnu.org I was looking for an compatible alternat, too. I gathered the same informations like you. As i can see there is no compatible thing, but if you find one, inform me! The best thing is really to rewrite the code using wxWidgets. IMHO it is the best alternate you can get. Would be nice to have something like "GnuFC"...
Re: [put the subject here]
"Pavel Procházka" wrote: Subject:[2/3] wined3d: IWineGDISwapChainImpl_Present relevant to windows implementation Making multibuffering working well when flip - sequence is W RGB, R GBW, G BWR, B WRG, W RGB. When W = WHITE, R = RED, G = GREEN, B = BLUE. It is doing well for any count of backbuffers - for 1 too. Please try to make the patch subject short and clear. All additional comments put in the patch body. -back = (IWineD3DSurfaceImpl *) This->backBuffer[0]; +back = *((IWineD3DSurfaceImpl *)This->backBuffer[0]); /*this value can not be pointer*/ Any reason for the above change and comment? +/*moving data from backbuffers to left - no pointers!*/ +for(i=0;ipresentParms.BackBufferCount-1;i++) Some spaces wouldn't hurt, and would better match the code you are changing. -- Dmitry.
Re: avifil32: Romanian translation
Paul, Paul Chitescu wrote: > Changelog: > avifil32: Romanian translation it looks like you are missing the #pragma code_page(65001) around the translation. bye michael
Re: programs/taskmanager: Fixed missing Dutch translations
Frans Kool wrote: Beat you to it ;) http://www.winehq.org/pipermail/wine-patches/2009-June/074719.html -- Cheers, Paul.
Re: [1/3][resend] wined3d: Allowing infinity count of backbuffers
Am Wednesday 24 June 2009 12:11:17 schrieb paulo lesgaz: > 2009/6/24 Pavel Procházka : > > Please set a proper subject on your mails. I think this has been asked > before. > > You can't just remove the check without making it work first, the > patch has to make sense on its own. > > I don't get what you mean. Do you suggest that Pavel merges the two first > patches in one single, with a title like "Allows multibuffering in ddraw" ? Actually, the check removed by this patch doesn't "protect" against hitting the not quite working code in swapchain_gdi.c. We already allow up to 4 backbuffers, which is already broken in swapchain.c. The check is here because d3d9(according to msdn) doesn't allow more than 4 back buffers.
Re: [1/3][resend] wined3d: Allowing infinity count of backbuffers
--- En date de : Mer 24.6.09, Henri Verbeet a écrit : De: Henri Verbeet Objet: Re: [1/3][resend] wined3d: Allowing infinity count of backbuffers À: wine-devel@winehq.org Date: Mercredi 24 Juin 2009, 11h13 2009/6/24 Pavel Procházka : > Please set a proper subject on your mails. I think this has been asked before. You can't just remove the check without making it work first, the patch has to make sense on its own. I don't get what you mean. Do you suggest that Pavel merges the two first patches in one single, with a title like "Allows multibuffering in ddraw" ? David
Re: [1/3][resend] wined3d: Allowing infinity count of backbuffers
2009/6/24 Pavel Procházka : > Please set a proper subject on your mails. I think this has been asked before. You can't just remove the check without making it work first, the patch has to make sense on its own.
Re: free software replacement for MFC?
Karl Berry wrote: > In the course of reviewing some possible projects for GNU, Richard > Stallman asked me if there was any active work going on to write a free > software replacement for MFC. I still have writing a mfc42 DLL for Wine on my extended todo list. But for Wine I would focus on the ABI compatibility and *not* on the API compatibility. Means the mfc42 dll would be written in C and not C++. As I don't want to get tainted by looking at the mfc headers/source I wouldn't write any mfc public headers for Wine. I guess you guys are interested in the API and not ABI compatibility; just to make it easy for people to port their stuff to the native non-Windows host. > From the MFC pages I found on the Wine web site > (http://www.winehq.org/docs/winelib-guide/mfc), which talk about ways of > working with the Microsoft classes and don't mention any alternatives, I > gather this isn't a current goal of Wine itself. > > But still, I figured that this would be the most likely place for any > such project would be known about, or even find possible developers if > one was to be started. Looking on the web, all I found was the old > ofc.sf.net, which appears not to have gotten very far and to have been > abandoned years ago, judging from the source repository. > > The other projects I came across, such as wxWidgets and SmartC++, appear > not to try to be a compatible replacement for MFC, but rather a > functional alternative. > > If anyone here has corrections, additions, suggestions related to those, > I'd be grateful for any replies. bye michael
Re: clock: Reset default codepage in utf8 rc file
Paul Chitescu writes: > I just checked the patch I've sent to wine-patches and it had #pragma > code_page(default) at the end. On the other hand the git commit didn't > include it. > > What gives? I removed it because it's not needed now that the resource files are compiled individually for clock. Other modules should be adapted to follow the same pattern, it will ensure that codepage pragmas can't leak from one file to the next. -- Alexandre Julliard julli...@winehq.org
Re: clock: Reset default codepage in utf8 rc file
On Wednesday 24 June 2009 02:28:12 Frédéric Delanoy wrote: > clock: Reset default codepage in utf8 rc file > > In the Romanian resource file for the "clock" program, which is in utf-8 > format, the code page wasn't reset to the default code page at the end of > the file. Now that's weird... I just checked the patch I've sent to wine-patches and it had #pragma code_page(default) at the end. On the other hand the git commit didn't include it. What gives?
Re: wined3d: fix a compiler warning
Pierre Bourdon wrote: > On Wed, Jun 24, 2009 at 03:43, Austin English wrote: >> On Tue, Jun 23, 2009 at 3:58 AM, Michael Stefaniuc wrote: >>> Hello Austin, >>> >>> are you reinventing strcpy? >> We do this elsewhere throughout the source. It prevents possible >> crashes/security vulnerabilities, as well as this warning: >> arb_program_shader.c: In function ‘shader_arb_get_register_name’: >> arb_program_shader.c:931: warning: format not a string literal and no >> format arguments >> arb_program_shader.c:935: warning: format not a string literal and no >> format arguments >> >> -- >> -Austin > > I think what Michael meant is that > sprintf(a, "%s", b); > > is doing exactly the same thing as > strcpy(a, b); Right, that's what I meant. > in a less efficient way. I'm not that much concerned about efficiency as the compiler will optimize it. But a strcpy is definitely easier to read. bye michael
Re: Developers-Hints wiki page: Character encoding in resource file translations
Francois Gouget writes: > On Mon, 22 Jun 2009, Frédéric Delanoy wrote: > [...] >> Furthermore, >> - the "65001" should probably be replaced by "utf8" (I checked in >> tools/wrc/parser.l:373) [ which would be better IMNSHO in new/updated >> resource file] > > Do the Windows/Mingw resource compilers support utf8 there? No, that's why using 65001 is preferable. -- Alexandre Julliard julli...@winehq.org
Re: Developers-Hints wiki page: Character encoding in resource filetranslations
"Francois Gouget" wrote: On Mon, 22 Jun 2009, Frédéric Delanoy wrote: [...] > Furthermore, > - the "65001" should probably be replaced by "utf8" (I checked in > tools/wrc/parser.l:373) [ which would be better IMNSHO in new/updated > resource file] Do the Windows/Mingw resource compilers support utf8 there? No, they don't. -- Dmitry.
RE: Is there any way to debug driver?
It works. Thanks Roderick! Guan Xiaofeng AMD Shanghai SW OpenGL Team 021-61601838-25746 xiao-feng.g...@amd.com -Original Message- From: Roderick Colenbrander [mailto:thunderbir...@gmail.com] Sent: Wednesday, June 24, 2009 12:23 AM To: Eric Pouech Cc: Wang, Robin; Guan, Xiao-Feng; wine-devel; Zhou, Jesse; Sun, Sunny; Boudier, Pierre; Jin, Jian-Rong Subject: Re: Is there any way to debug driver? It was just mentioned on IRC that the environment variable WINELOADERNOEXEC=1 needs to be set. After that you can just run 'gdb wine' and continue the same way as using wine-preloader. Roderick On Mon, Jun 22, 2009 at 10:24 PM, Eric Pouech wrote: > Wang, Robin a écrit : >> >> Hi Roderick, >> >> Using winedbg, it is OK for us to break into libGL.so. But we cannot set >> break point in our dri drivers, which is loaded by libGL.so using dlopen(). >> >> > > please send me the output of running > WINEDEBUG=+dbghelp wine > > and then at debugger prompt > > Wine-dbg> break your_func_in_dri_driver > Wine-dbg> cont > > TIA > > -- > Eric Pouech > "The problem with designing something completely foolproof is to > underestimate the ingenuity of a complete idiot." (Douglas Adams) > > >
free software replacement for MFC?
In the course of reviewing some possible projects for GNU, Richard Stallman asked me if there was any active work going on to write a free software replacement for MFC. >From the MFC pages I found on the Wine web site (http://www.winehq.org/docs/winelib-guide/mfc), which talk about ways of working with the Microsoft classes and don't mention any alternatives, I gather this isn't a current goal of Wine itself. But still, I figured that this would be the most likely place for any such project would be known about, or even find possible developers if one was to be started. Looking on the web, all I found was the old ofc.sf.net, which appears not to have gotten very far and to have been abandoned years ago, judging from the source repository. The other projects I came across, such as wxWidgets and SmartC++, appear not to try to be a compatible replacement for MFC, but rather a functional alternative. If anyone here has corrections, additions, suggestions related to those, I'd be grateful for any replies. Thanks, k...@gnu.org
Re: Developers-Hints wiki page: Character encoding in resource file translations
On Mon, 22 Jun 2009, Frédéric Delanoy wrote: [...] > Furthermore, > - the "65001" should probably be replaced by "utf8" (I checked in > tools/wrc/parser.l:373) [ which would be better IMNSHO in new/updated > resource file] Do the Windows/Mingw resource compilers support utf8 there? -- Francois Gouget http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !
