Hmm ... please change line 932 in video.cc from
SDL_SetRelativeMouseMode(enabled ? SDL_TRUE : SDL_FALSE);
to:
SDL_SetRelativeMouseMode(SDL_FALSE);
In my case (Ubuntu, XFCE) this introduces another bug: As soon as the
(invisible) mouse cursor leaves Enigma's window, no more mouse events are
reported. This means that the ball stops moving at some point, until the
(invisible) mouse cursor re-enters the window. If this works for you, or at
least gets rid of the large xrel/yrel-numbers, we can try to work from
there.
Could you also try the following as replacement for line 932?
Log << "Result of SetRelativeMouseMode: " <<
SDL_SetRelativeMouseMode(SDL_TRUE) << "\n";
I assume that "enigma --log" yields something like
"Result of SetRelativeMouseMode: -1";
Indicating an error.
Oh, and is there a "Last SDL error:" at the end of the log (fourth line
from the bottom)
(Probably just "missing sound", but maybe it's an important hint.)
Am Fr., 25. Dez. 2020 um 04:39 Uhr schrieb Sidney Markowitz <
sid...@sidney.com>:
> Andreas Lochmann wrote on 25/12/20 11:19 am:
> > Could you try "enigma --log --nograb"? This is no solution, but it helps
> to
> > pin down the problem. It sets two SDL-switches to false; one of them
> grabs the
> > mouse, such that Enigma does not loose focus when the mouse cursor
> leaves the
> > window; the other one is connected to relative mouse motion. The first
> switch
> > has to be on for the game to be playable, but the second ... who knows?
>
> That helped, although as you said, disabling the mouse grab option part of
> that makes the game unplayable.
>
> Here is what I found before I tried the --log --nograb options:
>
> Removing the external monitors made no difference. Changing the resolution
> on
> my laptop screen made no difference.
>
> When I moved the Enigma game window around the virtual desktop, I found
> that
> the mouse event numbers got smaller the closer to the upper left corner I
> put
> it. I could never get it close enough to the upper left corner top
> actually
> work. The smallest numbers were in the 2000 range. When I moved the window
> toward the lower right corner of the virtual desktop, the numbers could
> get up
> into the forty-some thousands.
>
> When I changed the size of the virtual display screen, the numbers in the
> mouse event output looked like the virtual screen was always something
> like
> 45,000 or maybe 50,000 in size. Wherever the Enigma window was and
> whatever
> size it was, the mouse event numbers looked like they were based on the
> position of the mouse within the virtual desktop. For example, if I set
> the
> desktop to be as big as I could and set the Enigma window to be as small
> as I
> could, then when I put the Enigma window in the upper left, the mouse
> event
> numbers could get as low as in the 2000's. But if the virtual display was
> set
> to a smaller resolution, the enigma window occupied more of it, so when I
> put
> the Enigma window in the upper left, the mouse position of the ball was
> farther away from the upper left corner as a proportion of virtual display
> screen size, and the mouse event numbers could not get lower than the
> 20,000's. In other words, imagine that no matter what the resolution
> settings
> in the VM, no matter how many or few pixels the desktop is, when I started
> a
> level the mouse events showed where the ball is in a coordinate system
> that
> scales to make the desktop approximately 50000x50000.
>
> Here is what I found trying enigma --log --nograb options:
>
> I was able to control the ball with mouse properly, although it was a bit
> erratic when I set a very large virtual screen size and scaled it to fit
> on my
> physical screen. The mouse event numbers were in the two digits range and
> some
> of them were negative numbers. If there was an option that did the same
> thing
> for relative mouse without disabling mouse grab, that might work.
>
> Sidney
>
