Wine Traffic #175 For 20 Jun 2003

WHAT'S NEW with Wine-20030618: (see ChangeLog for details)

• Still more Direct3D and DirectSound improvements.
• Tons of fixes merged from Crossover Office 2.0.
• New iphlpapi dll.
• Lots of bug fixes.

With WineX 3.1, TransGamers can enjoy such games as Morrowind and Grand Theft Auto: Vice City as well as the many graphical and speed improvements visible in games such as Battlefield 1942. Also available for TransGamers is a new release of Point2Play, version 1.1, which incorporates many changes suggested by TransGamers to enhance integration with desktop themes and to simplify game play experience.

Is anyone of you working on Dmusic interfaces ? Now doing test with Dxdiag doesnt work, it says "No such interface" when trying to create a IDirectPerformance object.

I did a look through the source and noticed that Dll(Un)RegisterServer are stubs.

Hi everyone. Sorry for not contributing anything to dmusic in a while, but I'm currently busy with final exams... As I can see, more work was done on it :)

This problem can be fixed with adding a

if (IsEqualGUID(lpcGUID, &IID_IDirectMusicPerformance) || IsEqualGUID(lpcGUID, &IID_IDirectMusicPerformance8))

in DMUSIC_CreateDirectMusicPerformance8 (at the time being, there's check for IID_IDirectMusicPerformance8 only).

But even with this added, dxdiag creates interface, calls some functions and then crashes (though I have no idea why).

Another thing... does anyone of you know how to write effective chunk loading function (it will be needed sooner or later since most dmusic objects are stored in files)?

I wonder why icons located in an executable are not viewable in GetOpenFileName ? I had a look to the source code (dlls/shell32/folder.c and dlls/shell32/classes.c) and saw that a search is made in the registry. But this search failed because my system.reg doesn't have the queried entry ( [Software\\Classes\\.exe]). I noticed that the winedefault.reg doesn't have the queried entry also. When this search fails, a default icon is applied.

By manually adding this entry in system.reg, it is still not possible to get the executables icons :-\ I also saw that [Software\\Classes\\.exe\\DefaultIcon] is also queried. Even if i manually add this entry again, it's not successfull. I think i've missed something in these entries definition but i don't know what. Anyway, by forcing the code to look inside executable for icons, they finally appear :)

But it's better to find another solution. How registry should be setted up (system.reg / winedefault.reg) ? Do we need to review the code (adding special case for exe files) ?

I tried and imported the following entries in the registry:

[Software\\Classes\\.exe] 1055664996
@="exefile"

[Software\\Classes\\exefile\\DefaultIcon] 1055665049
@="%1"

It does work! it displays the exe-icons, when switching into detail mode of the GetOpenFile-dialog box.

Ok, I've just managed to start looking into Aric's Wintab32 patch from April 23rd.

I've been extremely busy (more so than I expected) since then, on a small Java contract. So I've missed my goal of looking into Aric's code in 3 weeks. (Apologies Aric)

But anyway, I'm starting to look into it.

The first thing I'm seeing is a crash in the WTInfo() wintab call with Painter 5. Will look into this further, and attempt to fix.

Aric: Ever had this? I'll investigate further before posting up any significant details, as I suspect the fix is trivial.

Infact, has anyone else looked into this patch?

I haven't looked any further into Aric's other problems with Painter, as this WTInfo() error prevents Painter from even starting!

More importantly, I'd like to know why it didn't make it into the CVS? Did the patch slip behind the filing cabinet (as they do ;-)? Or was there a more substantive reason to reject the patch? I think Mike Hearn mentioned something about it's size (v. large)? Aric, Alexandre: do you want me to want me to re-subimt the patch, once I've got WTInfo() working?

I've also noticed that it doesn't update Wine's autoconf file to look for the XInput X extension, as is done to support other dlls that use X extensions. I assume this should be added.

Just to touch base with Aric: Has anyone done any more work in Code Weavers on this?

I think we where waiting on you. :) I did not formally commit it to wine-patches because i wanted to get your input first.

If you are planing to expand on my patch, then i would say Alexandre should could commit my patch then you work from there. Whatever is easiest for you.

Ok, I've done some preliminary testing, and fixed obvious bugs that have arisen.

What I found, and could fix:

• Sometimes a badly configured tablet can generate X errors on the XOpenDevice method. Fixed by ensuring tablet driver was functional. I don't know if the errors need to be caught, or not, but I think they were causing crashes. This is probably related to synchonous/asynchonous X modes.
• In Photoshop, an infinite loop in method FindOpenContext when attepting to traverse the wintab context chain.
• In Painter, a number of methods didn't handle NULL prameters properly, resulting in various crashes. Wintab uses NULL paramters to signify a query for size of available data, or to signify a request to flush the Wintab packet queue.

Aric, I'm wondering if I should really be fixing these things, as these look like the kind of bugs Code Weavers will have fixed in the normal course of product support.

After fixing these issues, The following remain:

1. Photoshop doesn't seem to respond to pressure.
2. Painter receives wintab events, but coordinates are extreme: only see lines from one side of drawing to another.
3. Maybe some further research into the errors from XOpenDevice. I'm not convinced it is a problem.

Aric, are these the kind of bugs you were seeing with Painter?

I'm suspicious of the Wintab packet building code, as it has to build a C data struct on the fly. Looking at the code though, I can't see anything that could be going wrong. It could also be a scaling issue, where the scales deduced from X are wrong (I remember being suspicious of some of the values returned by the wacom driver).

I've got tons of trace code that runs as a wrapper round wintab on win98, and will move some of this into the wine impl for more testing. I hope this will help solve the remaining bugs.

I think in the light of the crashing bugs, Aric's patch shouldn't go in as-is.

The first thing you need to do is make sure that your tablet is working under X. There is a great little program called xinput, it is a utility that test the XInput module. You can see all the axis of your device and make sure they are working. I found that to get XInput to recognize pressure from my wacom tablet i needed to run the latest wacom drivers from http://linuxwacom.sourceforge.net/index.php/main.

you can download xinput from

ftp://ftp.x.org/contrib/utilities/xinput-1.2.tar.gz

Ok, I recently started using System Shock 2 fullscreen with xvidmode enabled in my wine config, and here's something strange. When xvidmode is enabled, and I'm in a game and press esc to go to the menu, then esc again to return to the game, or load another save or go through a bulkhead/elevator and cause it to load another level, when it returns to the game the 3D area is completely black, though the HUD/inventory and brackets around items all shows up. This happens with a cvs from 2003-06-08 and also with a cvs from 2003-05-17, however if I don't patch 2003-05-17 with the surface locking the screen doesn't black when loading a saved game or moving between levels, etc. (of course then there's no hud or anything without the surface locking) So basically it's like you can only load 1 saved game, then the next area you go to or saved game you restore you need to save and restart the game for it to go away. Sorry I didn't notice this sooner when testing it out for you :) If you need any tracing done I'd be glad to, just tell me what ya need, also if you want a demo of ss2 I could give you a link to that too.... cheers -Dan

Well, seeing this description, I could say only one thing : DRIVER PROBLEM :-)

You description seems to imply that the glReadPixels call returns a completely black frame buffer (whereas the drawing seems to work well as shown when you remove the surface locking stuf). To be 100 % sure, you could enable the debug code in the Lock / Unlock case to have nice screenshots (if they are all black, that would show that :-) ).

Maybe it could be fixed by my attempts to use the texture engine instead of glReadPixels (to be submitted only after profiling)...

Did you try changing the resolution manually using Ctrl +/- ? Does it work like that ?