23 Jan
2004
23 Jan
'04
8:27 p.m.
Just a thank you for the people who followed up on this recently,
including the recent patch.
(I have been offline due to a failing modem, so couldnt participate
towards the end.)
Jason
24 Jan
24 Jan
2:29 a.m.
Jason Edmeades wrote:
Just a thank you for the people who followed up on
this recently,
including the recent patch.
Yep, that was really great teamwork. I also thank you all, especially
you Jason for cornering the bug!
(I have been offline due to a failing modem, so couldnt participate
towards the end.)
Jason
Great you're back! Maybe you could shed some light :-)
You remember that you came until a not moving cursor after starting DK.
I applied your second workaround for now and am stuck in the same situation.
I'll elaborate this a bit:
- 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?
--
Thanks,
Frank Schruefer
10:01 p.m.
Great you're back! Maybe you could shed some light
:-)
You remember that you came until a not moving cursor after starting DK.
I applied your second workaround for now and am stuck in the same
situation.
Nope, you are way outside my areas now - I dont know any X programming nor
how events are processed in Wine. You might want to try to work out how the
game gets input - is it dinput or processing windows messages.
<complete_guess>
FYI I do remember a thread on here ages ago about mouse pointers and
movements being relative rather than absolute coordinates, but I'm just
brain dumping here. Since it works when you move right and down, you may be
able to work out what is provided in those cases, and compare to the up and
left case. I wonder if relatively this two cases are negative numbers and we
screw up somewhere
</complete_guess>
I'm in the depths of debugging problems with another game at the moment, but
if noone else steps up to the challenge, I'll try to take a look.
Unfortunately time is always of too short supply.
Jason
25 Jan
25 Jan
10:10 a.m.
- 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.
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.
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 :-) )
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 :-)
--
Lionel Ulmer - http://www.bbrox.org/
5:11 p.m.
Lionel Ulmer wrote:
Hy Lionel,
DINPUT.DLL is not reported as being loaded (using +loaddll) so I think
it's nothing to do with it.
- 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.
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
30 Jan
30 Jan
9:34 p.m.
DINPUT.DLL is not reported as being loaded (using
+loaddll) so I think
it's nothing to do with it.
You're right... Actually, DungeonKeeper uses a better scheme than us to
simulate relative mous grabbing... Will need to do the same in DInput :-)
Anyway, with the two last patches I sent, it should work fine now.
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
26 Jan
26 Jan
9 a.m.
Hello,
I'll elaborate this a bit:
- 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?
Good, it sounds similar to the problem what i had with Theme Hospital.
Try this patch:
http://62.93.166.115/updatesysmetrics.diff
Regards,
Carlos.
--
___ _ \ | / Consulting
| . |._ _ _| | ___ ___ ___ http://www.andago.com
| || ' |/ . |<_> |/ . |/ . \__ GNU/Linux
|_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ /
Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_)
[ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___|
[ calb(a)epsxe.com ] http://www.ePSXe.com
1:55 p.m.
That's the situation.
Any ideas for a starting point for debugging?
Good, it sounds similar to the problem what i had with Theme Hospital.
Try this patch:
http://62.93.166.115/updatesysmetrics.diff
2:12 p.m.
Hello,
GREAT! That did it! Thanks!
Keeper is playable now, only the two mousepointers are very
irritating, and I gotta get the sound going ;-)
Will this patch go into the CVS or is it some kind of hack?
I think that it will be not going to cvs soon :(. It has 2 patches in
one. The first is from Alex Pasadyn, and it is related to resolution
change. The second is mine, and simply reset the clip cursor values
when the resolution is changed (it is what fixes the problem in
theme hospital and dungeon keeper). (checked in windows with a testcase :)
Alex needs to do some changes in his patch, for that it will get in
the cvs.
Regards,
Carlos.
--
___ _ \ | / Consulting
| . |._ _ _| | ___ ___ ___ http://www.andago.com
| || ' |/ . |<_> |/ . |/ . \__ GNU/Linux
|_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ /
Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_)
[ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___|
[ calb(a)epsxe.com ] http://www.ePSXe.com
That's the situation.
Any ideas for a starting point for debugging?
Good, it sounds similar to the problem what i had with Theme Hospital.
Try this patch:
http://62.93.166.115/updatesysmetrics.diff
7414
days inactive
7421
days old
8 comments
5 participants
participants (5)
-
Ann and Jason Edmeades -
Carlos Lozano -
Frank.Schruefer＠t-online.de -
Jason Edmeades
-
Lionel Ulmer