May 2006 - Wine-devel - list.winehq.org

Re: wined3d: Allow vertex shaders to generate GLSL shaders [Take Two]
by H. Verbeet 18 May '06

18 May '06

On 18/05/06, Jason Green <jave27(a)gmail.com> wrote: + /* We will check for errors later when we try to use the program */ Lets not do that. Assuming you're talking about inside drawPrimitiveDrawStrided, that's going to kill performance. What is the problem with checking for errors right after compilation?

2 2

[WINED3D] D3DCAPS: Check registry for UseGLSL enabled
by Phil Costin 18 May '06

18 May '06

Alexandre, This patch does not depend on Brian Hill's interface modification and it does allow a manually edited registry key option to enable GLSL, even without the new check box on the interface. Regards, Phil Costin

1 0

Whats with the Application DB?
by Roland Kaeser 18 May '06

18 May '06

Hello I just tried to update the state section of Corel Draw 9 with the newest expertises but cannot login again. Can somebody tell me the state of the appdb and eventually send me a actual account registration? Thansk Roland Kaeser

1 0

Re: wined3d: Allow vertex shaders to generate GLSL shaders [Take Two]
by Ivan Gyurdiev 18 May '06

18 May '06

Jason Green wrote: > This is a resend of the earlier patch, with one addition: > - previously, the line to alias the program.env[] to C[] was done in > the vertex shaders since that was the only function that needed them > (and it needs to be done to support relative addressing). However, > with PS 2.0+, pixel shaders now need to be able to use relative > addressing as well. This can't be done with ARB_fragment_program, but > it can be done with GLSL, so for consistency, we are now aliasing the > program.env[] array to C[] for both ps & vs. I think I've mislead you here (sorry)... the relative addressing on PS 3.0+ is on input registers, against aL, not on constants. I think it allows you to read the inputs in a loop against the loop counter. According to spec, pixel shader constants still do not allow relative addressing. So, this constant aliasing thing... we likely don't need this in pixel shaders. However, I still think that it'd be nice to use the same names (so we can share more code), and put this kind of initialization in baseshader if possible. From that point of view I agree w/ the patch, as long as nothing breaks.

1 0

Re: [winecfg] - Graphics tab layout tweak for GLSL option
by Alexandre Julliard 18 May '06

18 May '06

Brian Hill <dcatz(a)nc.rr.com> writes: > This patch adds an option to use GLSL for shaders as described in the > Wiki. It also fixes a minor grammar error (Allow Pixel Shader -> > Allow Pixel Shaders). GLSL (OpenGL Shading Language) is needed to > support Shader Model 2.0 and higher with WineD3D. It is best to leave > GLSL as an option through WineCFG as the WineD3D GLSL code will be > experimental for some time. I don't think that's a reason for exposing such details to the user. If it's not working well enough to be enabled by default, then people who know what they are doing can tweak the code, or possibly set a registry key. -- Alexandre Julliard julliard(a)winehq.org

1 0

cross referencing
by Pragyag 18 May '06

18 May '06

Hi I was just trying to configure lxr...but while browsing through.got errors like couldn't open xref databse, couldn't open .glimpse_filename.etc...i saw the cross referencing page of wine too..it has the same errors there.can anybody help me with these bugs??

1 0

Re: wined3d: Allow vertex shaders to generate GLSL shaders
by Ivan Gyurdiev 18 May '06

18 May '06

> + /* Create the uniforms (aka constants) */ > + shader_addline(&buffer, "uniform vec4 C[%u];\n", This->baseShader.limits.constant_float); > + /* TODO - Add varyings, attributes, etc. */ > + Shouldn't this go into the "generate_glsl_declarations" thing into baseshader? Things previously merged into baseshader should stay that way, imho...

2 1

Re: [Wine] random crashes in starcraft with 0.9.13
by Scott Ritchie 18 May '06

18 May '06

On Wed, 2006-05-17 at 20:41 -0400, Philippe A. wrote: > Hi, > > I have crashed for the third time while playing starcraft since i > upgraded to wine 0.9.13. Here's the trace i just got. No clear steps. > Just playing. I play with sound disabled in wine. I hadn't crashed > like that with previous versions of wine, for the past previous 100 > games or so (quick estimate based on my rec). > _______________________________________________ This kind of stuff goes best forwarded to wine-devel. I'll forward it for you. For convenience to the devs, this link is where the crash log is: http://www.winehq.org/pipermail/wine-users/2006-May/021680.html Thanks, Scott Ritchie

1 0

Re: Dinput8: DirectInput8Create rewrite
by Roderick Colenbrander 17 May '06

17 May '06

> On 5/15/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > > > > Yes, that's the reason. I forgot that I still need to send the patch for > the > > registry settings. Basicly what you need to add is this: > > > What about bf798030-483a-4da2-aa99-5d64ed369700? > > trace:ole:DllMain 0x7f3b0000 0x1 0x1 > trace:ole:DllMain 0x7f3b0000 0x2 (nil) > trace:dinput:DirectInput8Create hInst (0x400000), dwVersion: 2048, > riid ({bf798030-483a-4da2-aa99-5d64ed369700}), punkOuter ((nil))) > trace:ole:CoCreateInstance > (rclsid={25e609e4-b259-11cf-bfc7-444553540000}, pUnkOuter=(nil), > dwClsContext=00000001, riid={bf798030-483a-4da2-aa99-5d64ed369700}, > ppv=0x1d546f0) > err:ole:CoCreateInstance apartment not initialised > err:dinput:DirectInput8Create CoCreateInstance failed with hr = > -2147221008 > I think the issue is that CoInitialize isn't called from DirectInput8Create main. I think I missed this because my test app did this for me. Try to add a CoInitialize(NULL); and see if it helps. (and a CoUninitialize) Regards, Roderick Colenbrander -- Echte DSL-Flatrate dauerhaft f�r 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

2 3

A great way for non programmers to help with Wine - Audio
by Jeremy White 17 May '06

17 May '06

I've taken the liberty of changing the subject of Robert Reif's recent email and am expanding it a bit, because I don't want it to be ignored. The task is to perform a basic test of Wine's audio support to make sure it's a stable platform for us to build upon; what a great way for all you lurkers to help us out <wicked grin>. The basic procedure is - get a current version of Wine, test the sound, and send the results in. It won't take long (took me ~30 minutes), and it'll be very helpful. More details: Checkout Wine from CVS or git Figure out if you're using OSS, Alsa, or Alsa in OSS emulation mode (lsmod is your friend, and winecfg is quite nice as well) Run the test: cd dlls/winmm/tests WINETEST_INTERACTIVE=1 wine winmm_test.exe.so wave 2>&1 | tee /tmp/wave.out *important* As it runs, you should hear a nice steady set of soothing beeps, all at the same pitch and duration. If you hear any variation from that, make a note of it, so you can report it. It's important to listen the whole way through; a tad boring, I know, but important; it'll shift to a virtual device half way through and it's important to hear if it keeps on working or not. Report your results: Pack up your output files, and report your results along with your sound driver info. Failures are obviously the most interesting, but success on not previously validated hardware/driver combos are likely to be useful too. Sound report: Kernel 2.6.13 Sound driver: snd_intel8x0 Sound driver description from lspci: Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 32 bit Debian system Alsa version 1.0.10-2 Tested against Wine CVS up to date as of 5/7/06, 10:27 (without Robert's last two patches :-/; folks might want to wait a hair until those are applied) Results: Tested under winealsa, as well as wineoss with OSS emulation All sounds played flawlessly. Alsa runs reported 0 failures. OSS runs reported 48 failures; not clear if that was relevant Only anomaly is that the modem driver is treated as an OSS sound card, and so has a number of flawed attempts to play against it Full log files of the runs attached. Cheers, Jeremy

4 5