Wine Traffic #76 For 1�Jan�2001

I think I mentioned this a couple of times already: standard Windows headers *MUST NOT INCLUDE* config.h.

There is no guarantee that Winelib apps use the same configure script as Wine itself, or that they even use a configure script at all. Any #ifdef in the standard headers must be based on available preprocessor defines like __sparc__ etc.

Several months ago, I promised that wine-devel folks would be among the first to know what TransGaming Technologies has been up to. While we're not ready to make a big PR push at this point, we wanted to make sure that everyone involved in Wine is up to speed with what we're doing.

Our goal is nothing less than 100% compatibility for running Windows games on Linux through Wine.

So - we've been working hard on revamping the DirectX code within Wine to fully support the Direct3D 7 APIs, as well as substantially restructuring the DirectDraw code. So far, we've been able to get most of the core Direct3D 7 sample apps up and running, as well as some major game titles (Sacrifice), and the 3DMark2000 benchmark. We've implemented most of the code D3D features, including multitexturing, stencil buffers, alpha blending, fog, etc. We're still working on optimizations such as holding D3D Vertex Buffers in video memory for quick access to hardware T&L.

On the DirectDraw side, we've unified the code in the the x11 and DGA drivers into a new more OO design, separating direct use of xlib from the core code. We've added an 'update thread' which should make non-DGA use almost as good as DGA, especially when combined with some of contextual smarts in the GDI x11 driver Ove submitted a few weeks ago to speed up DIBsections. We still have some work to do on this front, since DGA support hasn't yet been integrated into our new design.

Initially, the Direct3D code will be released with limited redistribution rights under the Aladdin Free Public License - it will not be available under the Wine license. The DirectDraw code will be made available under the Wine license, and we should be submitting a patch with that code within a couple of days.

In 2001, we will be setting up a subscription service that allows users to vote on the games they would most like to see working. Users who pay will be allowed to vote on what we work on next - essentially a variant of the Street Performer Protocol ( http://www.firstmonday.dk/issues/issue4_6/kelsey/ (http://www.firstmonday.dk/issues/issue4_6/kelsey/) ).

Once a set number of users have subscribed to the service we will release the code under the Wine license. After the initial code is released under the Wine license, so will all subsequent patches, assuming we retain a set minimum number of subscriptions.

You can get the AFPLed code from our web site ( http://www.transgaming.com/) now. Once we have some feedback on the 2D side of things, we'll send a patch to wine-patches for release under the Wine license.

I got tired of certain keyboard autorepeat issues. When I played Monkey Island 4 in OpenGL mode a couple of weeks ago, I had to always remember to turn autorepeat off (xset r off) or there would be trouble. When I play a DirectInput-using game, I don't have to do that (because DirectInput does it), but when the game exits, the autorepeat is still off so I have to turn it on manually (xset r on).

Why do we have to put up with that? We know why (because X autorepeat isn't detectable). So this patch goes to the root of the problem...

The message sequence that Wine generates when a key is in auto-repeat mode is incorrect.

In Windows one gets a series of WM_KEYDOWN messages. The first one has the 'previous state' bit (30th of LPARAM) set to 0, and all those that come after have it set to 1. Then when the key is released the application gets a single WM_KEYUP message.

In Wine the application receives a succession of WM_KEYDOWN and WM_KEYUP messages instead. Note that this description is valid for a key like the down arrow key.

It's the very same thing. For where XKB is available and supports detectable autorepeat (certainly at least any PC that runs XFree86), you could now close the bug.

In most systems you can receive an event saying that such and such key has been pressed/released, but you can also query whether a given key is up or down. When we receive the KeyUp event, would it be possible to query X to determine if the key is really up or if it is pressed? If it is still pressed, then we would ignore the KeyUp event, mark the key as pressed internally, and on the next KeyDown event we would send a VM_KEYDOWN with the bit 30 set to 1.