Okay, judging by comments here, maybe I'd be better off sticking with Mint. I've only been working with computers for 25 years, but it is difficult to wrap my head around this, especially when it SHOULD be working.

I will set up my Mint computer a bit later and try again, making sure I have it with me as I'm typing.

Many thanks to all for your assistance, it's really appreciated.

To be honest, this situation has me really annoyed because I feel like I should be able to help... but I have no experience with Mint's file manager because I got into Linux early enough that, by the time Mint got invented, I was happily using stuff much further on the power-user/greybeard end of the "ease of use vs. light on system resources" spectrum.

That said, two things I'd suggest are:

1. if you don't mind installing a second file manager for testing purposes, that's one thing you could try to narrow down where the problem is. If another file manager works, you know it's something in the desktop.

(Not necessarily the file manager, because some desktops spit up the responsibilities. For example, KDE is made of a whole bunch of pieces communicating over D-Bus.)

I use PCManFM and, when I double-click an executable .sh file, it pops up a dialog with "Execute", "Execute in Terminal", "Open", and "Cancel" buttons. (I've attached a screenshot as an example.)

2. As part of the "Is it plugged in?" checking:

a. Copy and paste the exact permissions the file has (run `ls -l` in a terminal in the folder containing it and look at the left-most column) here as part of the "Is it plugged in?" checking.

On mine, that'd be this example line:
-rwxrwxr-x 1 ssokolow ssokolow 51M Apr 29 2016 gog_bit_trip_beat_2.0.0.1.sh

b. Run `mount` in a terminal, find the line with the longest matching prefix for the folder containing the installer, and confirm that it doesn't contain "noexec" in the parentheses at the end.

On mine, that'd be this line:
/dev/sdh1 on /mnt/buffalo_ext type ext4 (rw)

c. If you don't want to install a second file manager, you could instead try running it in the terminal by typing or pasting the full path to it, case-sensitive. If that works, that also indicates that it's something in the desktop.

(NOTE: If you don't want to use the full path, you have to prefix things in the current directory with ./ to tell the system that you're not expecting a command searched up from the PATH. That's another protection against exploits based on social engineering.)

Have you tried opening the directory the .sh file is in, opening a terminal window, then dragging the .sh file into the terminal, then pressing enter?

This is how I install gog games on Ubuntu. I could do it in the more convoluted fashion, but I am lazy :)

You should also know that you should be giving us relevant system info and which specific game (actually the specific installer even). ;) Is this a 32-bit install (uname -a)? If so run $ bash installer-name.sh (32-bit DASH bug). By default it tries to run with SH which is symlinked to DASH in Mint.
Otherwise, once you mark the file executable simply double-click and choose Run in Terminal. It should look similar to the attachment (MInt 18.1 Cinnamon 64-bit).

Got it working in a fully up-to-date Manjaro install. The game takes a VERY long time to load up, but it works.

What's your kernel (amdgpu) and Mesa version?

Mesa 17.0.1 amd kernel 4.10.

It could be the kernel and amdgpu driver. I'm stuck on 4.9.13 because of Debian testing freeze. And it's hanging even with newest Mesa master. When it was hanging for you, was your kernel older?

I should probably get another hard drive and experiment with an extra pure rolling distro, exactly for such kind of cases.

Ah, that's interesting. I didn't wait that long. I should give it another try. Would you mind reporting this to Mesa bug tracker? It sounds like something they should look at.

Sorry for the late reply (I very rarely check this thread). As others have said, you'll probably find Ubuntu a lot harder to get used to (I can't stand it either, horrible UI IMO). Also I wrote a beginner's guide for Linux Mint on these forums which you might find helpful: https://www.gog.com/forum/general/the_try_linux_repostrewrite

Anyway, assuming you're using the Cinnamon edition of Linux Mint: Right click on the installer and select "Properties", then check the box for "Allow executing file as program" found under the Permissions tab, as so: https://www.gog.com/upload/forum/2016/07/380c71ea3bc891d1ed395c7631649bb61cf7dca8.jpg

Then just double-click on the installer in the file manager - a popup will appear asking what you want to do; simply choose "Run" and it'll work.

I now followed through with testing, and Trine 3 indeed loads after quite some time. On the second run with Mesa git it loads faster, since Mesa / radeonsi now implemented shader cache (50 seconds to load on first run, 25 seconds to load on subsequent runs, once cache is populated). So it's clearly some shader compilation issue.

Also, during starting, the CPU is loaded about 25%, so shader compilation doesn't take advantage of all cores.

UPDATE: I filed a bug here.

I just noticed updates for Psychonauts and Brutal Legend. Any idea what changed in them?

Linux compatibility updates.

https://www.gog.com/forum/general/the_what_did_just_update_thread/page800

Bingo,

This got it working for me. Thank you so much!