Bug 44 - Right mouse click + hold not working the expected way in The Settlers 3
Summary: Right mouse click + hold not working the expected way in The Settlers 3
Status: CONFIRMED
Alias: None
Product: DXGL
Classification: Unclassified
Component: ddraw (show other bugs)
Version: SVN
Hardware: PC Linux + Wine (specify versions)
: Normal normal
Target Milestone: ---
Assignee: William Feely
URL: DXGL
Depends on:
Blocks:
 
Reported: 2015-05-02 10:26 EDT by Adrian Kalla
Modified: 2015-05-09 10:24 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Kalla 2015-05-02 10:26:56 EDT
-Wine 1.7.38 on Kubuntu 14.10 64 bit
-(Original ddraw.dll from Wine overwritten with the DXGL one and ddraw.dll set to "native" in winecfg)
-SVN r607 (built with MSVC 2013)

In The Settlers 3 the default method to scroll the map is to hold  the right mouse button and move the mouse. This does not work with DXGL (also tested with the downloadable compiled 0.5.7 release) in the expected way: when trying to scroll, nothing happens and the cursor also stays in place...

Interestingly: if, while holding the right mouse button, a key-up or key-down event happens (no matter which key on the keyboard), then the mouse starts moving.
But after releasing the mouse button once, you have to repeat the same procedure, which is a pain to play it that way...

I tried many DXGL setting-combinations, but none of them did change anything in this behavior.

This can be also tested with the demo version of the game, which can be found here: http://s3de.siedler3.net/ftp.bluebyte.com/demos/eng/settlers3amazons/s3a_demo_us.exe

I'm not sure if this bug also happens on Windows when using DXGL, as I didn't have the opportunity to test it there, yet.


Would be nice, if this could be fixed, as otherwise the DXGL ddraw.dll works with Wine *much* better than the original-Wine-ddraw.dll (and also consumes about 50% less CPU, at least with The Settlers 3), not speaking of the obvious things like smooth resolution scaling :)

I'm the maintainer of the game's entry in Wine's AppDb: https://appdb.winehq.org/objectManager.php?sClass=version&iId=3931 and also a programmer (but Python or Java - only very limited C...), so if I can help in any way - here I am.
Comment 1 William Feely 2015-05-02 18:35:23 EDT
I just created a virtual machine in VirtualBox and the problem is there but behaves a bit differently.
Also, it doesn't work in Windows because it specifically loads ddraw.dll from the Windows system folder, and not the application directory.  While it is quite safe to put DXGL in the system folder of Wine, it should never be attempted in Windows because it is a protected system file.
Comment 2 Adrian Kalla 2015-05-03 04:30:44 EDT
(In reply to William Feely from comment #1)
> I just created a virtual machine in VirtualBox and the problem is there but
> behaves a bit differently.

Could it be the second bug regarding Settlers 3, which I didn't have time to fill, yet:
Sometimes, after choosing a map and launching a game, no input is possible (neither mouse nor keyboard) - while before that, in the game menus it did work. 
When using Wine's windowed mode, this seems to happen in about 1 of 5 tries, but when not using it (full screen), then at least 4 of 5 tries end up without any way of input (thankfully, "Alt + F4" still works ;) ). But: I couldn't reproduce this issue (yet) with the demo - only with the full game...


> Also, it doesn't work in Windows because it specifically loads ddraw.dll
> from the Windows system folder, and not the application directory.

I think the demo may behave a bit differently from the latest full game version: I tried it in a Windows 7 Virtual Box VM and after configuring DXGL and starting the game, the whole VM freezes... My conclusions are:
1) With the full game version, DXGL ddraw.dll seems to be correctly loaded, as without it, the game does not freeze the VM...
2) This reminds me, that the VirtualBox 3D drivers are in an extremely bad shape - especially when comparing with VmWare or Parallels...
3) I need to test the full game in a not-virtualized Windows
Comment 3 William Feely 2015-05-03 05:37:54 EDT
Actually the no input issue was exactly what happened when I tried the demo under VirtualBox with Kubuntu 14.10.
Comment 4 Adrian Kalla 2015-05-09 04:40:24 EDT
(In reply to William Feely from comment #3)
> Actually the no input issue was exactly what happened when I tried the demo
> under VirtualBox with Kubuntu 14.10.

Any ideas what's causing both issues and how to fix them or at least work around them?

Regarding the no-input issue, just a thought I had: with a different app I had an interesting sighting: for some unknown reason, if the app asked the OS(Wine), if the Settlers3 app is foreground, the answer was in most cases no, even though Settlers 3 was running full screen and foreground. So the thought is: does DXGL check somewhere, if the game is foreground?
Comment 5 Adrian Kalla 2015-05-09 10:24:44 EDT
So, I did now some testing on a native Windows 7 64 bit:
-DXGL did out work out of the box with the full version of the game
-both bugs that could be seen with Wine can also be seen with Win7: so this is definitely not a Wine bug