Dungeon Keeper thread(s) recently

[Frank Schruefer]

Lionel Ulmer wrote:
>>- I have two mouse pointers.
>>- The first is trapped in the upper left corner and looks like a standard
>>   mousepointer. When the mouse is moved down or right it follows a bit and
>>   then always jumps back to it's corner.
>>- The second one is the Dungeon Keeper mouse pointer (some picture of a
>>   monsters head). This one moves down and right if the mouse is moved in
>>   this directions but doesn't move up or left.
>>   Except this the mousepointer behaves absolutely normal.
>>
>>
>>That's the situation.
>>Any ideas for a starting point for debugging?
> 
> 
> Well, this looks like a dinput bug in the handling of relative mouse
> grabbing when computing the coordinates of the middle of the screen.


Hy Lionel,

DINPUT.DLL is not reported as being loaded (using +loaddll) so I think
it's nothing to do with it.


> 
> To make a long story short, X does not really provide any way to get
> relative mouse movements (I do not despair to one day check-out the fd.o X
> server and add an extension to do that). So we need to 'warp' the mouse to
> the middle of the window each time it moves and compute from absolute mouse
> events the relative ones.


Interesting you mention warping ... if found that X11DRV_SetCursorPos is
called very often, obviously by a timer (of the game) or reset after every
mousemotion event.
It looks like the prog is constantly setting the mouse pointer (#1) back
to 0,0.
So I made the SetCursorPos doing nothing.
Then the situation changed as follows:

- The pointer #1 is now movable freely on the screen.
- If the mouse is moved right or down there are XMotionEvent's generated,
   and the game mouse pointer (#2) is moving down/right.
- If the mouse is moved left/up the game mouse pointer is still moving
   down/right. Also it's moving only if #1 was moved previously out of it's left upper
   corner (so xpos>0 or ypos>0).
- No more MotionEvents have been going on while the mouse wasn't moved.
   (Before they've been coming constantly).

So X is obviously not generating any events if the mouse is at 0,0 and
moved further left/up. Well, guess it's because that would be out of the client
area.
I don't know all implications of commenting out the SetCursorPos code but
it seems that even if X would send those events there's still some other problem.

Maybe one is: Why are there motion events generated by SetCursorPos if the
pointer wasn't actually moved, neither the position actually changed?

Well, that's what I've been able to find out so far ...


> 
> Anyway, this whole DInput code worked one day (when it used direct X calls
> and was full of hacks) and was a bit broken by the DLL separation work
> (basically, to support this properly we cannot use plain Win32 calls as it's
> done now but need to hook directly at the low level input system).
> 
>       Lionel (back from one week snowboarding in the Alps and still handling
>               the mail backlog :-) )

Hope you had some good rides there :-)

> 
> PS: will look too at the DDraw bug Jason reported.
> 
> PS2: was not able to run 'kddata.exe' properly (got hangs in Wine in random
>      places), but unzipping directly with unzip worked better :-)
> 

-- 
Thanks,
   Frank Schruefer