Wine Traffic #301 For 12 Dec 2005

What's new in this release:

• Many marshalling fixes in rpcrt4.
• Various OLE improvements and fixes.
• Better audio driver management in winecfg.
• Many wininet fixes.
• Several Web browser improvements.
• More dbghelp APIs implemented.
• Directory objects in wineserver.
• Lots of bug fixes.

As you all might know 2d games tend to be slow on Wine. For a lot of games the main bottleneck is depth conversion which happens in cases when the depth requested by the game and the X desktop color are not the same.

As a way to speedup 2d Lionel assisted me with hacking wine's ddraw to let it use parts of the Direct3D backend. The final rendering is then done using OpenGL and the end result is that the videocard does the color conversion for us. The patch greatly improves the performance of 2d games which don't use GetDC/ReleaseDC a lot.

While the patch fixes the conversion bottleneck for various games it doesn't handle 8bit paletted which is used by games like StarCraft as OpenGL doesn't support this by default. The second patch which I attached as well adds support for this. On cards (at least all nvidia cards from geforce 1 to the fx) that support the opengl paletted texture extension this extension is used. It makes StarCraft very fast atleast on my Athlon XP2000 system with a GeforceFX where the game was slow before. As not all cards support paletted textures I emulated this using a simple fragment shader. (a 1D texture containing the palette is used as a lookup table)

The attached patches are still experimental and likely contain bugs so please test them. When the patches are applied set 'HKCU\Software\Wine\DirectDraw\UseDDrawOverD3D' to Y else it won't do anything :)

Further note that lots of games like to use multiple threads for graphics... using the patch games use 'd3d' (or actually opengl) which adds more multithreaded d3d games :) Games like Command & Conquer, Red Alert, Total Annihilation and lots of others became multithreaded. (they crash quite quickly due to some critical section in x11drv)

All have fun with the patches and please report any issues that appear so that I can fix the patches and submit them to wine-patches.

Is Starcraft really that slow? How does this compare with using DGA? I'm not too sure because its speed varies. I've been testing Starcraft this weekend and it has been plenty speedy. But I do remember when trying to play it multiplayer a few months ago and was burned when it ran slow. In fact it slowed *everyone* down. Not fun.

This patch seems similar to glSDL where it wraps SDL's 2d API to OpenGL. The good thing about this it can provide acceleration and not require root like DGA. The bad thing with this idea is that it can't be used on older video cards or even some newer ones that lack proper direct rendering. Am I correct that even when just doing depth conversions, without direct rendering it will still be slow?

The code won't work for cards without hw accelerated opengl but note that most cards these days have opengl support. A simple Riva TNT is already quite old but is still supported on Linux and it should do a fine job only it can't handle the palette conversion. I haven't tested performance much using Mesa, I could try that soon using some games but it doesn't have to be slower than the current code as Mesa uses Xlib too in the indirect case. In general about all cards these days have some form of opengl support (intel, via, ati, nvidia, ..) perhaps only the latest S3 GPUs and perhaps some SIS ones (thought some have drivers) lack support. Note that cards don't need much functionality at all as OpenGL is only for the uploading of textures and the rendering of them.

I think the patch is a reasonable solution to work around various depth conversion problems. For sure it is the fastest way for the conversion as the videocard basically does it for free. On my system StarCraft and the Command & Conquer series (although they crash quite quickly due to threading issues) felt a lot faster, I think that the speed is close to that of DGA.

Perhaps I should clarify some misunderstandings that some people have. (I hope I explain it correctly) Basically DirectDraw provides a mechanism to directly access the framebuffer of the videocard. This is the fastest way to render 2D images on the screen. Games like StarCraft, Total Annihilation, C&C and lots of others use DirectDraw in this way. Second there's another class of games like Age Of Empires2, Heroes of Might and Magic IV and others which mix ddraw with GDI. They for instance render a image using ddraw and then use GetDC/ReleaseDC to get a device context so that they can draw in the surface. (directly into the video memory)

In case of X direct framebuffer access is only possible through DGA but it is insecure and has other issues. When DGA works correctly it can accelerate games like StarCraft. Further DGA doesn't have any depth conversion issues as it does depth switching. Without DGA the rendering operations need to go through X. Because of limitations of X, depth conversion problems appear when the depth of the desktop and X aren't the same.

For depth conversion purposes Wine's DirectDraw uses a DIB section. Basically all pixels of an image are translated to the depth of X. This is slow and especially for the case when the application requests 8bit paletted mode using a 24bit desktop. In this case a color lookup needs to happen in a palette for each pixel. The end result is then shown on the screen (if the game is of the StarCraft type)

Games that use GetDC/ReleaseDC can't work using DGA. The performance in general isn't great as lots of X calls happen. (things like conversions from XPixmap to XImages and the way around and also depth conversions happen a lot)

The patch I sent works for both classes of games though it won't help much for the second class as GetDC/ReleaseDC stuff is slow. As explained before the patch uploads the surface to a texture which is then rendered using OpenGL. This is quite fast and as a bonus the videocard can do all depth conversion for us as it isn't limited to rendering textures which are at the same depth as X.

For old videocards the GL renderer won't work and the old code should work fine (except for performance issues). You might have heard people talking about a 'dibengine' which would let Wine do all DIB related operations in software which would save a lot of XImage/XPixmap conversions. (conversion is only needed for the final rendering stage) This dibengine would mainly accelerate games that use GetDC/ReleaseDC. It won't help games like StarCraft (much) as for those DIBs were only used for depth conversion and the conversion algorithm stays the same (it can't be tweaked much if at all). So there's not really a way to speedup games like StarCraft for old videocards. Perhaps XShm might be of use but not sure how much it would help. (think it would only be useful for GetDC/ReleaseDC games)

I think that to merge Roderick's and your (ed note: Stephan's) patch, the best would be to directly hook WineD3D even at the 2D level and not have DDraw hook DDraw's D3D which then goes into WineD3D.

This way we would have a unified DDraw.

Of course, then the problem remains of what to do with older cards :-)

I thought of the same thing, as DDraw -> D3D7 -> WineD3D -> OpenGL is a quite long chain. I abandoned it as too much work at first, but it's surely worth considering.

How about moving the current 2D code to WineD3D, and making DDraw running over WineD3D in any case. Then WineD3D could decide whether to use plain X11, DGA or OpenGL for 2D rendering. :)

Maybe we should have a close look at the details of such a thing. I do not really recommend a ad-hoc attempt, as d3d7->WineD3D was nearly too much.

That basically bows down to have WineD3D completely replace the 'HAL' architecture which was introduced by the TG merge.

Which is kinda an idea that I like :-)

Well, we can first stabilize D3D7 => WineD3D (which will already be quite a lot of work to first do and then polish) and then see if we move the 2D part too.

And then we will need to rename it to something else ... if not merge it integrally into the X11DRV so that other DLLs (like the new Vista ones :-) ) would be able to do 3D accelerations :-)

In the past weeks, I've worked on a re-write of the Direct3D7 implementation with WineD3D. Well, I've managed to get some games running, but I have also encountered a few problems. Before I continue with this, I'd like to ask for your opinions.

I have uploaded a patch to http://doesi.gmxhome.de/d3d7.patch.bz2, it's a diff against Wine CVS from December, 11th 2005. It's not really meant to be used, but rather to have something to look at. I don't know how long I can keep the patch there, because I am limited in space. I've sent the patch to Oliver some days ago to upload it to his sourceforge website, it will be available there when he uploads it.

So what's the point of this mail? While a D3D7->WineD3D wrapping can be done by wrapping D3D7 only and leave DirectDraw in ddraw.dll, it has a few ugly drawbacks:

• Device initialization: In D3D7, the first step is to create a IDirectDraw Device, set up the device, create a surface and then create a Direct3D Device. When creating the WineD3DDevice in the last step, I have to do some ugly things to wrap the already existing Surface to a newly created WineD3DSurface. The same applies in reverse order for the device removal. I also don't know what to do if a game changes the screen setup after D3DDevice creation.
• Surfaces: In D3D7 surfaces are children of IDirectDraw, while in WineD3D they are children of WineD3DDevice. Because the D3D7Device can be created and destroyed without modifying surfaces, I have to manage the surface's properties and memory areas for both DirectDraw and WineD3D. Overrides for the Lock() and Unlock() functions are used to access the WineD3D surface if it exists.

I think that everything would be much cleaner if the DirectDraw functionality was also moved to WineD3D. My suggestion is the following:

• WineD3D would be initialised in the D3D7 way, using a new interface WineDDrawDevice. D3D8 and D3D9 could easily manage this in their create functions
• Surfaces are created with WineDDrawDevice, and they survive the release of WineD3DDevice. This makes surface creation easier for D3D7, and it's easy to adopt it for D3D9 and D3D8.
• The IWineD3DSurface interface gets additional functionality for DirectDraw operations. I'd suggest 3 versions of the 2D functions: One based on plain X11(for compatibility) calls, one that uses DGA(speed without 3D acceleration), and one that uses OpenGL(For fast rendering without /dev/mem access). For DXVersion > 7 the OpenGL version is used, and for DX7 it can be decided when the primary surface is created.

What's the drawback? First, it's much more work, and it's a really invasive change to WineD3D, which becomes more complex. Because of this I'd like to know your opinion before I spend a lot of time for this.

I've hacked up a little script that takes your committed git changes and puts a draft in your gmail draft folder for each commit that contains a changelog and the attached diff. To use the script, make sure you have python installed. You'll also need to change the variables at the top of the script to match your specifics. The script is pretty simple, so if you don't like the format of the email it wouldn't be hard to change. The process goes like so:

1. make your commits, but when you're writing the changelog entry for the commit, make sure to put all the changes you would have in the Changelog section of the email ie for one of my recent patches, the commit message was,
   • Use DelNode itself for the directory recursion.
   • Handle the dwFlags parameter.
   • Factor out file creation and deletion.
   • Add test cases for DelNode and make them pass.
   you can use asterisks if you like or not, it won't affect the script.
2. ./makedraft.py
3. the script calls git-format-patch for you and loops through all the commits
4. the script asks you for a subject (of the email) for each commit
5. if you don't want to send a patch to wine-patches, enter 'stop' as the subject (minus the quotes)
6. the diffs will be in diff_dir and the drafts will be in your gmail drafts folder
7. append anything you need to the email and press send

You'll also need libgmail for python installed as well:

http://libgmail.sourceforge.net/

If you have any comments or suggestions, I'd like to hear them (I think the script is rather ugly myself, but it gets the job done :))

OK, more news. I updated my cvs-script a little bit (nothing really noticeable) but that's not all. Since everybody seems to have changed to GIT, I wrote a git-version of my wine-update-script. Features, functionality and so on are the same as in the cvs-version.

• getwinecvs.sh is now version: 0.36
• getwinegit.sh is version: 0.1 (based on getwinecvs.sh v0.36)

Yesterday I upgraded to WINE 0.9.3, and then tried running Photoshop 7. Photoshop gave me a hardware error. I thought, no problem, I'll just reinstall it, same result. Then I reconfigured WINE using winetools and tried again, same thing. Here is what I got in the Terminal when running Photoshop 7:

(ed note: a bunch of FIXME's)

Then I tried installing Photoshop CS, knowing that it worked fine with 0.9.2. Photoshop CS told me that certain required files was missing, but I forgot to get down the results from the Terminal. After that I downgraded to WINE 0.9.2 and both versions of Photoshop work great.

A little side note: ImageReady 7 works great under 0.9.3, I did not test ImageReady CS. ImageReady 7 works great under 0.9.2 also, but ImageReady CS crashes.

Yes. And here are some instructions on how to go about finding the troublesome patch:

http://winehq.org/site/docs/winedev-guide/x1344

Is anyone using the arts, esound or jack sound drivers for non trivial use? By non trivial, I mean more than one application or more than a single device. If so, I am interested in getting information on the software you are using and how it is using the drivers.

Would redesigning these drivers to show up as a single device per physical device which allowed being opened more than once be a problem?

When trying to set up printing from Wine on Fedora Core 4 for x86_64, I have discovered that Wine fails to find many libraries, including libcups. It turns out that the development packages on Fedora Core 4 don't always provide *.so symlinks for 32-bit libraries. So I wrote this script.

The script creates all missing links in one directory (/usr/local/lib is the default). Not only was libcups found next time, but also the old workaround with imake has become unneeded. The configure script runs out-of-box and finds X11 libraries.

I'm posting the script here in hope that it will be useful for some Wine users. I'm not sure it it merits inclusion in Wine, but I would not object.

They are provided for some basic libraries, such as zlib and ncurses. Other libraries, such as cups, as missing, but my script can remedy it, because the only missing file is the symlink to *.so for the linker.

Unfortunately, openssl support cannot be fixed by the script since /usr/include/openssl/opensslconf-i386.h is missing. That's where a development package would be very helpful.

I see it's not fixed in RawHide yet, so we'll have to deal with such issues for some time.

Background. I am trying to figure out why a program that I thought ran OK on 25 October no longer runs and no longer runs when I recompile from that code too.

So the program accesses invalid memory down inside the WNDPROC stuff (winproc.c line 418, it says, so I guess it means line 416)

So I turn on WINDEBUG=+relay to see what is being passed.

And wine segfaults.

Even

export WINEDEBUG=+relay
wine --version

which yields

0009:Call kernel32.__wine_kernel_init() ret=77ed4e4d
Segmentation fault

I can't use gdb and I can't use winedbg.

Anyone know what is going on?