World Wine News

• Many Direct3D fixes and performance improvements.
• More comctl32 tests and some bug fixes.
• Compatibility improvements in cmd.exe.
• Still more fixes to builtin OLE.
• Support for process control on Solaris.

There is a way you can save on your OS costs, though. You could still switch to Linux, and thanks to software like CrossOver and Wine you can run your Windows applications within Linux itself. These programs give Windows applications a "friendly environment" to run in, essentially fooling them into believing they're running inside the OS they're supposed to. CrossOver is actually a paid version of Wine, offering you a bunch of extra features and more user-friendliness.

For the summer of code I'm planning to improve the dsound code and alsa code, to make alsa finally better than OSS, in a way that will get accepted into the wine tree, for that I'm thinking of improving on the following fronts:

Winealsa:

• Add mixer device and aux controls
• Implement dsound capture
• Separate the initialisation of the directsound code from the waveout code, to allow creation of multiple dmix devices.
• Try to configure alsa to allow arbitrarily big buffers, working around the alsa problem that only up to a certain amount can be allocated for buffers, certain programs (for example winamp) may require more.
• Remove the queuing thread and use Lock() and Unlock() instead.
• Make it run so well, people wouldn't want to use OSS anymore.

Both dsound/winealsa:

• Allow proper usage of Lock() and Unlock() for sound drivers, it's not used properly or even tested in current dsound code.
• Rework some of the dsound code, to allow mixing to be done in winealsa, and fix possible errors that can be caused by it.
• Improve the dsound software mixer code to allow mixing and (if possible) be less prone to buffer underruns.

The challenge is to get this working right, without too much of an impact hit. I also will have to work around alsa limitations: I cannot make buffers arbitrarily big, while in windows they can be. It seems no 2 programs use dsound in the same way, so I will have to test with various different programs to get everything working.

I'll try to get in contact with alsa-devel first, if there is a way to change buffer size to something arbitrary, it is worth it in the long run to use that method. A manual fix seems to be close everything using alsa, then echo 256 > /proc/asound/card0/pcm0p/sub0/prealloc, but I am hoping there is an easier way to fix it, in either case I am afraid I will have to put some memory buffer code in winealsa as fallback.

If there's still some time left, I'll also try to get some 3d sound code in, using some openal code, the license seems to be lgpl compatible, or I will try to get support for multiple (4, 5.1 ?) speakers working, it depends a little on how fast I can get this to work in a nice shape.

Has anyone thought about adding the directx options to the Graphics tab in WineCfg

Just now I've been testing all the work that's been done on the graphics layer on different games so I've been switching on and off GLSL and changing backbuffer to fbo etc using regedit

Would it not be better to change these things easily instead to allow for wider testing.

PS With GLSL and FBO Tomb Raider Legent Opening Level Sequence the cliffs are black

It's not something you should have to configure. Eventually GLSL and FBOs should simply become the defaults, and if it doesn't work that's a bug. I think GLSL is basically at the point where in general it's at least as good as the ARB backend, FBOs will need a bit more work.

GLSL is OK IMO, because some drivers (*cough* macos *cough*) have serious problems with glsl. It could be included into the shader dropdown box. The issue that needs to be dealt with is that we can't combine arb vertex shaders and glsl pixel shaders or vice versa.

Video memory size maybe too. There are vendor dependent ways to read it, but implementing them is pretty nasty (requires some private to winex11.drv). Although we had that discussion a number of times already and we only agreed on a registry key so far.

Offscreen rendering should have fbos fixed and made default, otherwise use backbuffer (not pbuffer because backbuffer with aux buffers is cheaper). I don't think it is a good idea to add it to winecfg

I don't think render target locking should be configurable as is. That rendering should be fixed to catch NOP locks some games do (which does the same as glFinish() on windows).

What I have considered is some performance vs correctness slider. With decreased correctness things like render target locking or drawStridedSlow are disabled. If the correctness is decreased even more some properly implemented, but known to be expensive settings could be deactivated, like smooth shading, per pixel fog (ok. not sure if that is expensive). Windows drivers have such a setting, so why shouldn't we :-) . This slider could also cover some software emulated features like vertex blending (if we ever get that). Of course we shouldn't pollute the wined3d code with if (someSetting) statements either.

I have some benchmarks posted here:

https://wiki.winehq.org/BenchMark-0.9.5

https://wiki.winehq.org/BenchMark-0.9.6

And I have all the Graphics test in PCMark 04 running, but the app is crashing between test, but if I run them one at a time they will complete.. The quandary is would posting the test results from each test while not run as a whole but separately be of use? and would this be unfair when comparing the results against XP?

I was looking through the mailing list archives about the status of wine working in Intel-Macs. I'd like to start helping the wine project making some effort in Macintel computer, and i like to reach some 3D approach that works in Mac.

The Direct3D and OpenGL parts are working too, but I am struggling with some driver issues. Namely GLSL shaders are completely broken, but Jason Green tells me that this is MacOS'es fault. Other than that a few handy Nvidia extensions are missing, but apple has its own, so we may want to add a few codepaths for apple exts to wined3d. I did that for GL_APPLE_fence so far, but there are maybe others.

What needs work for getting 3D stuff working better is the quartz backend. I haven't done any comparison benchmarks yet, but I think we're loosing a bit of performance due to the X server (But not as much as many mac users think), and there are some window setup issues because of the X server and quartz-wm.