Release of Enigma 1.30-alpha

[Andreas Lochmann-2]

Dear developers, contributors, and friends of Enigma,

today we release Enigma 1.30-alpha. It is meant as a
version for level developers and bug hunters. However,
if you currently have problems running Enigma 1.21 on
your system, you might consider switching to Enigma
1.30-alpha, instead of waiting for the beta version.

The major change from version 1.21 can be safely
attributed to Daniel Heck: He swapped out the outdated
SDL 1.2 against SDL 2.0. Many thanks to Daniel for
this major work! It will hopefully provide more
stability in the future, even if, right now, this
means that Enigma 1.30-alpha will be more bug-ridden
than Enigma 1.21 was in its heyday.

We have a list of more than 190 additional levels
planned for 1.30-beta. Enigma 1.30-alpha will provide
you with 22 of them, primarily for showcasing the
new game objects we introduce with Enigma 1.30.
However, there are some gems among these 22 levels,
and I highly recommend you try them out. Many thanks
go out to Nobby, Thomas, Raoul, and our new
contributor and author, Georg Honold, who will curate
the remaining ~170 levels for Enigma 1.30-beta.

If you are a level developer, we hope the new objects
we include will inspire you, help you to realize
new ideas and new kinds of puzzles. Please feel free
to present us your new levels, via enigma-devel or
illmind's mag-heut.net forum. Kudos to illmind for
providing us with a forum for more than 16 years now!

You can find Enigma 1.30-alpha here:

   https://github.com/Enigma-Game/Enigma/releases/tag/1.30-alpha

On Linux:
   Right now, no binary package exists for Linux.
   If you run into problems compiling the source code,
   please don't be afraid to ask for help here on the
   enigma-devel mailing list, or on mag-heut.net.

On Windows:
   The zip-file Enigma-w32-1.30-alpha.zip will unpack
   to a directory, from which you can run Enigma
   directly, no further installation neccessary. We might
   provide you with an installer in the coming days, if
   need be. You can alternatively download the windows
   zip-file from sourceforge:

   https://sourceforge.net/projects/enigma-game/files/Release%201.30-alpha/

On Mac:
   Sidney has been working tirelessly on compiling
   Enigma for macOS. Four days ago he wrote a message
   on how to use homebrew to compile Enigma from the
   github master branch. If you follow his advice,
   you can compile Enigma 1.30-alpha for yourself.
   He is also working on a dmg, which might be added
   soon. Many thanks go to Sidney for his continuing
   work on making Enigma available on Mac!

Please remember that this is an alpha-version. There
might be evil bugs not yet seen, so please backup
your scores and self-written levels before trying it.

List of shortcomings / known bugs:

- Credits have not been updated since 1.21.
   Sorry to everyone not yet mentioned, this will
   be fixed in beta of course.
- Translations have not been updated since 1.21.
   Many thanks to the translators. Your work is
   highly appreciated, I just could not find the
   time to fit it into alpha before Christmas.
   It will definitely be in beta!
- Switching to another language is not
   instantaneous, but might need a restart of Enigma.
   (I noticed this bug too late, sorry.)
- The ratings are not updated.
- I forgot to add some license docs for dlls on
   Windows. They will be added for beta.
- Enigma has some performance issues since switching
   to SDL 2.0, particularly in smoothly scrolling
   levels. We will try to improve this for beta.
- Rescaling the application window introduces
   graphical artifacts: Better use fixed window
   sizes for now.
- Not all fullscreen modes are available yet.

If you find more bugs, please don't hesitate to
inform us, via enigma-devel, mag-heut, or an issue
on GitHub.

We wish all of you happy holidays,
please stay safe, and: Have fun!

Andreas, Daniel, Raoul, Nobby, Thomas, and Georg

[Fòram na Gàidhlig]

Thanks!

I have given it a quick spin on Linux and it seems to be working fine.
Need to brush up on my dexterity now!

Can you update the translation files on Transifex soon? It would also be
good if the strings were sorted by file occurrence rather than
alphabetically, to give translators some context.



Sgrìobh Andreas Lochmann na leanas 23/12/2020 aig 14:16:

>
> Dear developers, contributors, and friends of Enigma,
>
> today we release Enigma 1.30-alpha. It is meant as a
> version for level developers and bug hunters. However,
> if you currently have problems running Enigma 1.21 on
> your system, you might consider switching to Enigma
> 1.30-alpha, instead of waiting for the beta version.
>
> The major change from version 1.21 can be safely
> attributed to Daniel Heck: He swapped out the outdated
> SDL 1.2 against SDL 2.0. Many thanks to Daniel for
> this major work! It will hopefully provide more
> stability in the future, even if, right now, this
> means that Enigma 1.30-alpha will be more bug-ridden
> than Enigma 1.21 was in its heyday.
>
> We have a list of more than 190 additional levels
> planned for 1.30-beta. Enigma 1.30-alpha will provide
> you with 22 of them, primarily for showcasing the
> new game objects we introduce with Enigma 1.30.
> However, there are some gems among these 22 levels,
> and I highly recommend you try them out. Many thanks
> go out to Nobby, Thomas, Raoul, and our new
> contributor and author, Georg Honold, who will curate
> the remaining ~170 levels for Enigma 1.30-beta.
>
> If you are a level developer, we hope the new objects
> we include will inspire you, help you to realize
> new ideas and new kinds of puzzles. Please feel free
> to present us your new levels, via enigma-devel or
> illmind's mag-heut.net forum. Kudos to illmind for
> providing us with a forum for more than 16 years now!
>
> You can find Enigma 1.30-alpha here:
>
>   https://github.com/Enigma-Game/Enigma/releases/tag/1.30-alpha
>
> On Linux:
>   Right now, no binary package exists for Linux.
>   If you run into problems compiling the source code,
>   please don't be afraid to ask for help here on the
>   enigma-devel mailing list, or on mag-heut.net.
>
> On Windows:
>   The zip-file Enigma-w32-1.30-alpha.zip will unpack
>   to a directory, from which you can run Enigma
>   directly, no further installation neccessary. We might
>   provide you with an installer in the coming days, if
>   need be. You can alternatively download the windows
>   zip-file from sourceforge:
>
>   https://sourceforge.net/projects/enigma-game/files/Release%201.30-alpha/
>
> On Mac:
>   Sidney has been working tirelessly on compiling
>   Enigma for macOS. Four days ago he wrote a message
>   on how to use homebrew to compile Enigma from the
>   github master branch. If you follow his advice,
>   you can compile Enigma 1.30-alpha for yourself.
>   He is also working on a dmg, which might be added
>   soon. Many thanks go to Sidney for his continuing
>   work on making Enigma available on Mac!
>
> Please remember that this is an alpha-version. There
> might be evil bugs not yet seen, so please backup
> your scores and self-written levels before trying it.
>
> List of shortcomings / known bugs:
>
> - Credits have not been updated since 1.21.
>   Sorry to everyone not yet mentioned, this will
>   be fixed in beta of course.
> - Translations have not been updated since 1.21.
>   Many thanks to the translators. Your work is
>   highly appreciated, I just could not find the
>   time to fit it into alpha before Christmas.
>   It will definitely be in beta!
> - Switching to another language is not
>   instantaneous, but might need a restart of Enigma.
>   (I noticed this bug too late, sorry.)
> - The ratings are not updated.
> - I forgot to add some license docs for dlls on
>   Windows. They will be added for beta.
> - Enigma has some performance issues since switching
>   to SDL 2.0, particularly in smoothly scrolling
>   levels. We will try to improve this for beta.
> - Rescaling the application window introduces
>   graphical artifacts: Better use fixed window
>   sizes for now.
> - Not all fullscreen modes are available yet.
>
> If you find more bugs, please don't hesitate to
> inform us, via enigma-devel, mag-heut, or an issue
> on GitHub.
>
> We wish all of you happy holidays,
> please stay safe, and: Have fun!
>
> Andreas, Daniel, Raoul, Nobby, Thomas, and Georg
>
>

[Sidney Markowitz]

What version of Linux did you use and how did you build it? I guess you built
from the git master branch? I tried making a release 1.30-alpha tar.gz and
building from that on CentOS 7 and on Ubuntu 18.04 and on both of them the
mouse was not responsive once I started a level.

  Sidney


Fòram na Gàidhlig wrote on 24/12/20 7:51 am:
> Thanks!
>
> I have given it a quick spin on Linux and it seems to be working fine.
> Need to brush up on my dexterity now!
>
> Can you update the translation files on Transifex soon? It would also be
> good if the strings were sorted by file occurrence rather than
> alphabetically, to give translators some context.

[Sidney Markowitz]

So far I have tried building it on VirtualBox virtual machines with CentOS 7,
Ubuntu 18.04.5LTS, and Ubuntu 20.04LTS, all with VirtualBox Guest Additions
installed, and I have both built from the working directory from the repo with
autogen.sh, configure, make gmo, make, sudo make install, sudo enigma
--makepreview being run, and also tried creating a distribution tar.gz and
building from that (no additional autogen.sh, make gmo, or makepreview).

In every case, I ran it by running the command "enigma" in a Terminal command
line. It started up ok, including being able to use the mouse to select menu
items, up until I clicked on a level to run it. When in a level, moving the
mouse caused lines of output on the Terminal saying (with varying numbers)
    mouse event with 33320, 14986
but the ball did not move. Clicking the mouse did cause the correct response
in the game for a mouse click.

Pressing the Esc key properly escaped the level and the magic wand mouse
cursor did then appear and worked to select from the menu.

Has anyone else had a similar experience, or can say what is different in your
setup if you have been successful running in Linux, or do you have any insight
on the mouse event messages and the inability to use the mouse in the levels?

Thanks,

  Sidney

Sidney Markowitz wrote on 24/12/20 10:12 am:

> What version of Linux did you use and how did you build it? I guess you built
> from the git master branch? I tried making a release 1.30-alpha tar.gz and
> building from that on CentOS 7 and on Ubuntu 18.04 and on both of them the
> mouse was not responsive once I started a level.
>
>    Sidney
>
>
> Fòram na Gàidhlig wrote on 24/12/20 7:51 am:
>> Thanks!
>>
>> I have given it a quick spin on Linux and it seems to be working fine.
>> Need to brush up on my dexterity now!
>>
>> Can you update the translation files on Transifex soon? It would also be
>> good if the strings were sorted by file occurrence rather than
>> alphabetically, to give translators some context.
>

[Fòram na Gàidhlig]

I'm on an Ubuntu 20.04-based Linux Mint Mate. I ran:

./autogen.sh
./configure
make
sudo make install (needed for translations)

Running ./enigma or enigma worked fine.

I was missing some dependencies initially, so just to be sure I can
"make clean" in between attempts.

This is my ./configure summary:

   Source directory:    .
   Installation prefix: /usr/local
   C++ compiler:        g++ -g -O2 -DENABLE_ASSERT -g -DCXXLUA
   Libraries:           -lcurl -lxerces-c -lpng -ldl
   Linker options:
   Languages: de fr nl it es sv ru hu pt fi uk be el pl cs gd hr sk da
   System enet: no

Compiler: gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

If you're on a VirtualBox, maybe there is a driver issue?



Sgrìobh Sidney Markowitz na leanas 24/12/2020 aig 04:11:

> So far I have tried building it on VirtualBox virtual machines with
> CentOS 7, Ubuntu 18.04.5LTS, and Ubuntu 20.04LTS, all with VirtualBox
> Guest Additions installed, and I have both built from the working
> directory from the repo with autogen.sh, configure, make gmo, make, sudo
> make install, sudo enigma --makepreview being run, and also tried
> creating a distribution tar.gz and building from that (no additional
> autogen.sh, make gmo, or makepreview).
>
> In every case, I ran it by running the command "enigma" in a Terminal
> command line. It started up ok, including being able to use the mouse to
> select menu items, up until I clicked on a level to run it. When in a
> level, moving the mouse caused lines of output on the Terminal saying
> (with varying numbers)
>    mouse event with 33320, 14986
> but the ball did not move. Clicking the mouse did cause the correct
> response in the game for a mouse click.
>
> Pressing the Esc key properly escaped the level and the magic wand mouse
> cursor did then appear and worked to select from the menu.
>
> Has anyone else had a similar experience, or can say what is different
> in your setup if you have been successful running in Linux, or do you
> have any insight on the mouse event messages and the inability to use
> the mouse in the levels?
>
> Thanks,
>
>  Sidney
>
> Sidney Markowitz wrote on 24/12/20 10:12 am:
>> What version of Linux did you use and how did you build it? I guess
>> you built
>> from the git master branch? I tried making a release 1.30-alpha tar.gz
>> and
>> building from that on CentOS 7 and on Ubuntu 18.04 and on both of them
>> the
>> mouse was not responsive once I started a level.
>>
>>    Sidney
>>
>>
>> Fòram na Gàidhlig wrote on 24/12/20 7:51 am:
>>> Thanks!
>>>
>>> I have given it a quick spin on Linux and it seems to be working fine.
>>> Need to brush up on my dexterity now!
>>>
>>> Can you update the translation files on Transifex soon? It would also be
>>> good if the strings were sorted by file occurrence rather than
>>> alphabetically, to give translators some context.
>>
>
>

[ZockDom]

Well, I‘ve been running Enigma successfully. Since you asked for possible differences:
I built Enigma from the tar archive and everything seems to work fine. I‘m running Manjaro Linux with kernel 5.9.11. Enigma is linked against libSDL2-2.0.so.0 (package version 2.0.12-3), ..._image (2.0.5-2), ..._mixer (2.0.4-5), ..._ttf (2.0.15-2), libjpeg.so.8 (libjpeg-turbo 2.0.6-1), libtiff.so.5.5.0 (package version 4.1.0) and libpng16.so.16 (package version 1.6.37-3).
Maybe differences there might cause the bug you describe.

> Am 24.12.2020 um 05:11 schrieb Sidney Markowitz <[hidden email]>:
>
> So far I have tried building it on VirtualBox virtual machines with CentOS 7, Ubuntu 18.04.5LTS, and Ubuntu 20.04LTS, all with VirtualBox Guest Additions installed, and I have both built from the working directory from the repo with autogen.sh, configure, make gmo, make, sudo make install, sudo enigma --makepreview being run, and also tried creating a distribution tar.gz and building from that (no additional autogen.sh, make gmo, or makepreview).
>
> In every case, I ran it by running the command "enigma" in a Terminal command line. It started up ok, including being able to use the mouse to select menu items, up until I clicked on a level to run it. When in a level, moving the mouse caused lines of output on the Terminal saying (with varying numbers)
>  mouse event with 33320, 14986
> but the ball did not move. Clicking the mouse did cause the correct response in the game for a mouse click.
>
> Pressing the Esc key properly escaped the level and the magic wand mouse cursor did then appear and worked to select from the menu.
>
> Has anyone else had a similar experience, or can say what is different in your setup if you have been successful running in Linux, or do you have any insight on the mouse event messages and the inability to use the mouse in the levels?
>
> Thanks,
>
> Sidney
>
> Sidney Markowitz wrote on 24/12/20 10:12 am:
>> What version of Linux did you use and how did you build it? I guess you built
>> from the git master branch? I tried making a release 1.30-alpha tar.gz and
>> building from that on CentOS 7 and on Ubuntu 18.04 and on both of them the
>> mouse was not responsive once I started a level.
>>  Sidney
>> Fòram na Gàidhlig wrote on 24/12/20 7:51 am:
>>> Thanks!
>>> I have given it a quick spin on Linux and it seems to be working fine.
>>> Need to brush up on my dexterity now!
>>> Can you update the translation files on Transifex soon? It would also be
>>> good if the strings were sorted by file occurrence rather than
>>> alphabetically, to give translators some context.

[Sidney Markowitz]

I tried installing on Ubuntu 20.04 based Linux Mint Mate and got the same
problem with the mouse while in the level.

At this point the only point of difference I see is that I'm running it on a
VirtualBox virtual machine.

In other news, I've built and uploaded a macOS dmg that anyone can use to
install Enigma on macOS without having to have Homebrew and without building
from source. So far it has only been tested on macOS Catalina. If it doesn't
work on High Sierra or Mojave, let me know and I can build it on a High Sierra
machine instead, which should be forward-compatible to Mojave and Catalina.
Big Sur will have to wait until I can set up a machine to play with it.

https://github.com/Enigma-Game/Enigma/releases/download/1.30-alpha/Enigma-1.30-alpha.dmg

Sidney

[Andreas Lochmann-2]

A mouse event with so large numbers is discarded by Enigma on purpose, because the black ball would suddenly be subjected to an enormous impulse, if the mouse event would have been interpreted the normal way. So, the ball not moving is a logical and necessary consequence to an overly large mouse xrel/yrel-pairing. So ... we have to ask: Why does SDL2 report so large xrel/yrel-values?

I cannot reproduce the bug ... could you please answer the following questions?

Do you use a special kind of mouse or mouse port?

Do you use an intermediary program (like a logger) or a remote desktop? (Those might manipulate the mouse coordinates. The fact that you observe the same problem using VirtualBox can be explained by (1) VirtualBox manipulating the mouse coordinates or (2) the host OS being involved in the bug.)

Were there other windows on the screen, besides Enigma's window?

There is a bug report about SDL 2 here concerning "jumpy" relative mouse motion:

  https://bugzilla.libsdl.org/show_bug.cgi?id=3067

It needs other windows other than Enigma to be present. It should be closed on X11, but your host OS might still be reporting wrong numbers. However, the numbers you report are so much larger, that it just doesn't make sense, unless you use something like a 40.000 x 20.000 pixel display?

Best

Andreas

Am Do., 24. Dez. 2020 um 15:20 Uhr schrieb Sidney Markowitz <[hidden email]>:

I tried installing on Ubuntu 20.04 based Linux Mint Mate and got the same
problem with the mouse while in the level.

At this point the only point of difference I see is that I'm running it on a
VirtualBox virtual machine.

In other news, I've built and uploaded a macOS dmg that anyone can use to
install Enigma on macOS without having to have Homebrew and without building
from source. So far it has only been tested on macOS Catalina. If it doesn't
work on High Sierra or Mojave, let me know and I can build it on a High Sierra
machine instead, which should be forward-compatible to Mojave and Catalina.
Big Sur will have to wait until I can set up a machine to play with it.

https://github.com/Enigma-Game/Enigma/releases/download/1.30-alpha/Enigma-1.30-alpha.dmg

Sidney

[Sidney Markowitz]

That could explain it. I have a MacBook Pro laptop with two external monitors attached. The virtual machine display is on one of the external monitors. I can imagine that a bug in the interaction between SDL2 and the virtual graphics stuff could result in coordinates with large numbers as if the three screens were one huge virtual display. I'll try it with the VM displayed on just the laptop screen, and try with the external monitors unplugged to see if it makes a difference. If that helps we can see if there is a way to get it to work with external monitors.

Do have an idea what is different with the mouse when it is in a menu screen and the magic wand mouse cursor does display and move correctly?

Thanks,

 Sidney

Andreas Lochmann wrote on 25/12/20 9:52 am:

A mouse event with so large numbers is discarded by Enigma on purpose, because the black ball would suddenly be subjected to an enormous impulse, if the mouse event would have been interpreted the normal way. So, the ball not moving is a logical and necessary consequence to an overly large mouse xrel/yrel-pairing. So ... we have to ask: Why does SDL2 report so large xrel/yrel-values?

I cannot reproduce the bug ... could you please answer the following questions?

Do you use a special kind of mouse or mouse port?

Do you use an intermediary program (like a logger) or a remote desktop? (Those might manipulate the mouse coordinates. The fact that you observe the same problem using VirtualBox can be explained by (1) VirtualBox manipulating the mouse coordinates or (2) the host OS being involved in the bug.)

Were there other windows on the screen, besides Enigma's window?

There is a bug report about SDL 2 here concerning "jumpy" relative mouse motion:

  https://bugzilla.libsdl.org/show_bug.cgi?id=3067

It needs other windows other than Enigma to be present. It should be closed on X11, but your host OS might still be reporting wrong numbers. However, the numbers you report are so much larger, that it just doesn't make sense, unless you use something like a 40.000 x 20.000 pixel display?

Best

Andreas

Am Do., 24. Dez. 2020 um 15:20 Uhr schrieb Sidney Markowitz <[hidden email]>:

I tried installing on Ubuntu 20.04 based Linux Mint Mate and got the same
problem with the mouse while in the level.

At this point the only point of difference I see is that I'm running it on a
VirtualBox virtual machine.

In other news, I've built and uploaded a macOS dmg that anyone can use to
install Enigma on macOS without having to have Homebrew and without building
from source. So far it has only been tested on macOS Catalina. If it doesn't
work on High Sierra or Mojave, let me know and I can build it on a High Sierra
machine instead, which should be forward-compatible to Mojave and Catalina.
Big Sur will have to wait until I can set up a machine to play with it.

https://github.com/Enigma-Game/Enigma/releases/download/1.30-alpha/Enigma-1.30-alpha.dmg

Sidney

[Andreas Lochmann-2]

Yes, there is quite a difference: The menu mouse cursor is displayed by absolute mouse coordinates, delivered by SDL. If there was a problem with absolute measurements, nearly every SDL using application would fail. However, in the game we use relative coordinates (delivered by SDL), which is a much more seldom used feature. There are also several bugs related to relative mouse measures:

  https://bugzilla.libsdl.org/buglist.cgi?quicksearch=sdl%20mouse%20xrel

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?

Your configuration with several monitors sure can explain the large numbers, this is very interesting. However, it's not an uncommon configuration, we should be able to present a solution.

SDL's solution to relative mouse motion is just by calculating differences and reporting these. If something suddenly changes the absolute position of the mouse cursor (VIrtualBox might do this!) the result is an extraordinarily large number, like you observed, and like we observed in prior versions of SDL 1.2 in certain situations as well (this is why we filter out all excessively large numbers). We might be able to calculate the relative mouse positions by ourselves, but this is not trivial -- we might have to regularly reset the absolute position of the mouse cursor to the center of the window etc.

Am Do., 24. Dez. 2020 um 22:13 Uhr schrieb Sidney Markowitz <[hidden email]>:

That could explain it. I have a MacBook Pro laptop with two external monitors attached. The virtual machine display is on one of the external monitors. I can imagine that a bug in the interaction between SDL2 and the virtual graphics stuff could result in coordinates with large numbers as if the three screens were one huge virtual display. I'll try it with the VM displayed on just the laptop screen, and try with the external monitors unplugged to see if it makes a difference. If that helps we can see if there is a way to get it to work with external monitors.

Do have an idea what is different with the mouse when it is in a menu screen and the magic wand mouse cursor does display and move correctly?

Thanks,

 Sidney

Andreas Lochmann wrote on 25/12/20 9:52 am:

A mouse event with so large numbers is discarded by Enigma on purpose, because the black ball would suddenly be subjected to an enormous impulse, if the mouse event would have been interpreted the normal way. So, the ball not moving is a logical and necessary consequence to an overly large mouse xrel/yrel-pairing. So ... we have to ask: Why does SDL2 report so large xrel/yrel-values?

I cannot reproduce the bug ... could you please answer the following questions?

Do you use a special kind of mouse or mouse port?

Do you use an intermediary program (like a logger) or a remote desktop? (Those might manipulate the mouse coordinates. The fact that you observe the same problem using VirtualBox can be explained by (1) VirtualBox manipulating the mouse coordinates or (2) the host OS being involved in the bug.)

Were there other windows on the screen, besides Enigma's window?

There is a bug report about SDL 2 here concerning "jumpy" relative mouse motion:

  https://bugzilla.libsdl.org/show_bug.cgi?id=3067

It needs other windows other than Enigma to be present. It should be closed on X11, but your host OS might still be reporting wrong numbers. However, the numbers you report are so much larger, that it just doesn't make sense, unless you use something like a 40.000 x 20.000 pixel display?

Best

Andreas

Am Do., 24. Dez. 2020 um 15:20 Uhr schrieb Sidney Markowitz <[hidden email]>:

I tried installing on Ubuntu 20.04 based Linux Mint Mate and got the same
problem with the mouse while in the level.

At this point the only point of difference I see is that I'm running it on a
VirtualBox virtual machine.

In other news, I've built and uploaded a macOS dmg that anyone can use to
install Enigma on macOS without having to have Homebrew and without building
from source. So far it has only been tested on macOS Catalina. If it doesn't
work on High Sierra or Mojave, let me know and I can build it on a High Sierra
machine instead, which should be forward-compatible to Mojave and Catalina.
Big Sur will have to wait until I can set up a machine to play with it.

https://github.com/Enigma-Game/Enigma/releases/download/1.30-alpha/Enigma-1.30-alpha.dmg

Sidney

[Sidney Markowitz]

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

[Mark Pulley-3]

I can’t run it on Mojave - an error box comes up: “The application requires MacOS 10.5 or later”. It runs fine on Catalina.

Mark P.

On 25 Dec 2020, at 1:20 am, Sidney Markowitz <[hidden email]> wrote:

In other news, I've built and uploaded a macOS dmg that anyone can use to install Enigma on macOS without having to have Homebrew and without building from source. So far it has only been tested on macOS Catalina. If it doesn't work on High Sierra or Mojave, let me know and I can build it on a High Sierra machine instead, which should be forward-compatible to Mojave and Catalina. Big Sur will have to wait until I can set up a machine to play with it.

[Andreas Lochmann-2]

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 <[hidden email]>:

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

[Andreas Lochmann-2]

I just created a new branch "alternative-mouse-input-1.3". Right now, there is nothing new in it, but I will try some replacement for SetRelativeMouseMode, and commit it here, if it works.

Am Fr., 25. Dez. 2020 um 12:54 Uhr schrieb Mark Pulley <[hidden email]>:

I can’t run it on Mojave - an error box comes up: “The application requires MacOS 10.5 or later”. It runs fine on Catalina.

Mark P.

On 25 Dec 2020, at 1:20 am, Sidney Markowitz <[hidden email]> wrote:

In other news, I've built and uploaded a macOS dmg that anyone can use to install Enigma on macOS without having to have Homebrew and without building from source. So far it has only been tested on macOS Catalina. If it doesn't work on High Sierra or Mojave, let me know and I can build it on a High Sierra machine instead, which should be forward-compatible to Mojave and Catalina. Big Sur will have to wait until I can set up a machine to play with it.

[Sidney Markowitz]

I'm not surprised, although I assume that was a typo in your email and the
error message was "requires macOS 10.15 or later".

I think I've figured out the proper settings to make a VirtualBox virtual
machine on my Mac that can run High Sierra, and how to deal with the mess
resulting from Homebrew dropping support for anything earlier than Mojave.

That should let me put together a build of enigma that will run on all three
of High Sierra, Mojave, and Catalina. All bets are off on Big Sur, especially
on the new Arm Macs, until I or someone else has one to work with. I won't
bother going all the way back to Sierra... Strangely enough, any machine that
is capable of running Sierra is capable of being upgraded to High Sierra, and
the November 2020 security patches did not provide fixes for Sierra.

  Sidney


Mark Pulley wrote on 26/12/20 12:53 am:

> I can’t run it on Mojave - an error box comes up: “The application requires
> MacOS 10.5 or later”. It runs fine on Catalina.
>
> Mark P.
>
>> On 25 Dec 2020, at 1:20 am, Sidney Markowitz <[hidden email]
>> <mailto:[hidden email]>> wrote:
>> In other news, I've built and uploaded a macOS dmg that anyone can use to
>> install Enigma on macOS without having to have Homebrew and without building
>> from source. So far it has only been tested on macOS Catalina. If it doesn't
>> work on High Sierra or Mojave, let me know and I can build it on a High
>> Sierra machine instead, which should be forward-compatible to Mojave and
>> Catalina. Big Sur will have to wait until I can set up a machine to play
>> with it.
>

[Sidney Markowitz]

Andreas Lochmann wrote on 26/12/20 1:56 am:
> Hmm ... please change line 932 in video.cc from
>      SDL_SetRelativeMouseMode(enabled ? SDL_TRUE : SDL_FALSE);
> to:
>      SDL_SetRelativeMouseMode(SDL_FALSE);

This worked, though with the problem you mentioned when the invisible mouse
cursor leaves Enigma's window.

> 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.

No, the result of that is 0, and the large numbers problem of course re-appears.

>
> 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.)

There is no "Last SDL error" in the log, and nothing in the log looks to me as
if it represents an SDL error message. There could be lines that I incorrectly
think are other warnings, but none of them strike me as being an SDL error
message.

  Sidney

[Andreas Lochmann-2]

Thank you for your patience, Sidney. We now know the location of the bug (SDL, of course), and have to find a way to work around it. This will need some time. I have an idea how to do this, but it will probably further impact Enigma's performance negatively. I might have to add an option for this.

Am Fr., 25. Dez. 2020 um 23:00 Uhr schrieb Sidney Markowitz <[hidden email]>:

Andreas Lochmann wrote on 26/12/20 1:56 am:
> Hmm ... please change line 932 in video.cc from
>      SDL_SetRelativeMouseMode(enabled ? SDL_TRUE : SDL_FALSE);
> to:
>      SDL_SetRelativeMouseMode(SDL_FALSE);

This worked, though with the problem you mentioned when the invisible mouse
cursor leaves Enigma's window.

> 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.

No, the result of that is 0, and the large numbers problem of course re-appears.

>
> 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.)

There is no "Last SDL error" in the log, and nothing in the log looks to me as
if it represents an SDL error message. There could be lines that I incorrectly
think are other warnings, but none of them strike me as being an SDL error
message.

  Sidney

[Mark Pulley-3]

> On 26 Dec 2020, at 7:03 am, Sidney Markowitz <[hidden email]> wrote:
>
> I'm not surprised, although I assume that was a typo in your email and the error message was "requires macOS 10.15 or later".

Oops - 10.15 or later is what I meant!

I’ve just installed Big Sur in a separate partition, and Enigma seems to work correctly with this version of MacOS (at least on my 2018 MacBook Pro).

Mark P.

[Andreas Lochmann-2]

Hi Sidney,

I wrote a first draft of a manual relative mouse mode, in branch "alternative-mouse-input-1.3". You find the new button in the options menu, submenu "Config" (together with the other mouse related options). When you set it to "slow" it should work for you.

With "slow" and "fast" I refer to possible performance impacts. However, It turns out that the new "slow" method actually moves the marble slower. This was not intended. Even worse: Sometimes events are ignored. I reposition the (invisible) mouse cursor to the middle of the window on a regular basis. This generates a mouse motion event (because of cause manually moving the cursor generates an event -- it's not that the program wouldn't know, duh?), which has to be flushed. "SDL_FlushEvent" does not work for me, so, right now, I flush everything, including key strokes that happen in between. And maybe even additional, real mouse motion events, which would be the origin for the slowed down marble.

So, as of now, it's a hot-needle workaround.

Could you check if the "slow"-mode at least works for you? Thank you in advance.

Am Fr., 25. Dez. 2020 um 23:00 Uhr schrieb Sidney Markowitz <[hidden email]>:

Andreas Lochmann wrote on 26/12/20 1:56 am:
> Hmm ... please change line 932 in video.cc from
>      SDL_SetRelativeMouseMode(enabled ? SDL_TRUE : SDL_FALSE);
> to:
>      SDL_SetRelativeMouseMode(SDL_FALSE);

This worked, though with the problem you mentioned when the invisible mouse
cursor leaves Enigma's window.

> 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.

No, the result of that is 0, and the large numbers problem of course re-appears.

>
> 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.)

There is no "Last SDL error" in the log, and nothing in the log looks to me as
if it represents an SDL error message. There could be lines that I incorrectly
think are other warnings, but none of them strike me as being an SDL error
message.

  Sidney

[Sidney Markowitz]

Andreas Lochmann wrote on 26/12/20 1:40 pm:
> I wrote a first draft of a manual relative mouse mode, in branch
> "alternative-mouse-input-1.3". You find the new button in the options menu,
[ ... ]
> Could you check if the "slow"-mode at least works for you? Thank you in advance.

"Slow" mode works to some degree. In that mode, I have some control over the
mouse, but it is is finicky to an unusable degree. I find it hard to describe
exactly what it is doing. Sometimes it seems as if I move the mouse down, the
ball moves up, I move the mouse up, the ball moves up, I move the mouse right,
the ball moves right, I move the mouse left the ball moves right. But it isn't
that clear-cut, if I move the mouse quickly, down, for example, the ball might
move down. Mostly it seems like the ball responds erratically to the mouse
movement. I can get the mouse outside of the Enigma window, in which case I
get mouse events showing again in the log, this time with numbers in the minus
to plus 300 range.

With all that, if I set the mouse speed to anything higher than 1, the mouse
moves too quickly and erratically for me to do anything at all with it.

Regards,
Sidney