Game: Dragon's Lair Trilogy
Version: GOG 1.09
Installer MD5:
e74ec4f967f8b24d7b082ec1fa03c7a2 - setup_dragons_lair_1.09_(22122).exe
f30e6af2cba79462f27ae4588df1d7b3 - setup_dragons_lair_1.09_(22122)-1.bin
8e4b1b3fc71218a91ac21432b1e2f34d - setup_dragons_lair_1.09_(22122)-2.bin

Distro: Linux Mint 19.1 Tessa | Mate | 64-bit
Kernel version: 4.15.0-72-generic x86_64
Graphics card: Intel HD Graphics
Wine version(s) tested: Wine 4.15-staging 64-bit
WineHQ AppDB link: click (awaiting new version and test report to be accepted)

Install notes: Installs correctly.
How well does it run: Perfect. No issues and well performance. Two games have been completed; I was not able to complete the third because of bug, which exists also in Windows version.
Details: I'm using budget laptop with Intel Pentium CPU 3550M 2×2.30GHz + integrated Intel HD Graphics on board. I'm using PlayOnLinux (without their predefined scripts).

Game: Two Worlds Epic Edition
Version: GOG 2.0.0.23
Installer MD5:
52dbe4f341efc0edac995426b7f9309a setup_two_worlds_epic_edition_2.2.0.23.exe
12d727cb609dee78a45ef7c29afec5a9 setup_two_worlds_epic_edition_2.2.0.23-1.bin
WineHQ AppDB Link: GOG

Distro: Linux Mint 19.2 Tina | Cinnamon | 64-bit
Kernel: 4.15.0-72-generic
Graphics: NVidia GeForce GTX 670
CPU: Intel i7-3930K @ 3.20GHz × 6
Wine Version: Wine Staging 5.0-rc2 32-bit

Install Notes:

Winetricks: devenum quartz wmp9 xact
DLL Overrides: x3daudio1_1 (native, builtin)
Works fine with PhysX packaged in the GOG installer.
Videos had to be re-encoded from vc1 to wmp2 (with ffmpeg).

How well does it run:

Near perfect so far (haven't completed).
No crashes in over 20 hours of play.
No significant performance issues.
Some issues rendering early morning fog -- creates an RGB strobe effect.

Details:

Disabled fog with the following in-game console command to fix the RGB strobe:
Engine.SetFogParams 100 1000 0.2 0.02 0

Created a config file to expand render distances without a noticeable performance impact.
Additional details in the full thread.

GOG's Linux release doesn't run on Ubuntu 18.04+, so I thought I'd try an update.
Thanks @shmerl for the video encoding tips.

Not a clean prefix and not a regression. Set dsound to builtin and sfx will work normally. I've seen that back in Wine 2.1, IIRC. Anyway, game is Gold including videos. With Wine 4.21 in a clean 32-bit prefix: Technically, I installed wmp9 as I was flailing around forgetting the wineboot -u, but it isn't necessary.

Looks great. Just needs an AppDB link e.g. Also, if you could move these paragraphs to the end or above the Install Notes:. That way the post starts with the report, thanks.

Maybe try "winetricks strictdrawordering=enabled". It fixed some rendering issues for me. Not sure though if your issues are the same.

Already gave that a go. No dice.
Spent a couple hours tweaking common render vars to see if I could get rid of it.
In the end disabling the fog was all I could come up with.

After extending the render distances, though, I prefer no fog. Seems like the fog and depth of field serve, in part, to hide the short render distance. Without them I can stand up on a mountain top and view castles miles away... so... silver lining I guess? ;)

do you mean sound setting in launcher, or? Im kinda confused

I meant in the dirty prefix you have an override with native dsound (e.g. winetricks -q dsound or one that included it). Setting it back to builtin in winecfg should be sufficient for working sfx. That part only applies to the existing prefix.
If instead you use a separate, clean prefix you won't have a preexisting override for it and won't need to worry about that bit.

Doesn't apply since wine-3.5:

Replying to an old post -- I finally gave this one a go (Grim Dawn) on Wine Staging 5.0-rc3 set to Windows 7. Good news is no winetricks or manual dll overrides required. It played well out of the box. But initially I did encounter a lot of micro-freezes.

Took a couple days to track the issue down, but my best guess is that they write and immediately re-read the save files at regular frequency (maybe for fog-of-war changes?) as well as any time a player event occurs -- leveling, unlocking quests, changing the inventory, etc. -- as such events always triggered up to a 1-second stutter followed by a time-adjusted catch up.

Initially, I installed to a standard external spin drive over USB3. Running entirely from ramdisk (/dev/shm) the issues went away, so I tested disk access by bind mounting individual portions of the install to copies in ram. I found that bind mounting the save directory (drive_c/users/<username>/My Documents/My Games/Grim Dawn/save) eliminates the stuttering completely, even with the rest of the game running from external disk.

As to my best guess -- if they were just reading, the read files would already be in ram (verified with vmtouch). If they were just writing, the disk cache should handle a delayed write to disk gracefully without a thread lock. But if they write and re-read, the writes (only 1 MB or so) have to be flushed to disk and then reloaded to ram. It's not much, but if they do it on the main thread that could certainly cause the stuttering I encountered.

Game: Grim Dawn
Version: GOG 1.1.5.2 hotfix 2 (64-bit)
Installer MD5:
ee1dcbe47a88cbc6e0fbeb842b83c50d setup_grim_dawn_1.1.5.2_hotfix_2_(64bit)_(34628)-1.bin
7abcc0f37de325d41285e73cf934040d setup_grim_dawn_1.1.5.2_hotfix_2_(64bit)_(34628).exe
WineHQ AppDB Link: 1.1.1.2_hotfix3 (64-bit) (most recent as of this post)

Distro: Linux Mint 19.2 Tina | Cinnamon | 64-bit
Kernel: 4.15.0-72-generic
Graphics: NVidia GeForce GTX 670
CPU: Intel i7-3930K @ 3.20GHz × 6
Wine Version: Wine Staging 5.0-rc3 64-bit

Install Notes:
Installs correctly (with the usual error popups).
No winetricks or manual DLL overrides required (overrides are auto-detected).
In Game: Enable Options > Video > Deferred Rendering

How does it run:
Entirely playable with no crashes, though the frame rate is a little low at times.
Without "Deferred Rendering" enabled, water textures are sometimes the wrong color.
As mentioned above, constant save file access can cause stuttering with slow disk access. Run from an SSD or bind mount a copy of My Documents/My Games/Grim Dawn/save from a ramdisk to eliminate the stutter.
Edit: As @dtgreene noted, the stuttering may be due to write caching being disabled, but I'm unable to verify that on the test machine.

Details:
Played with most settings on high/ultra with vsync, triple buffering, post processing, and ambient occlusion enabled.
Played through the Warden quest (~10 hours) with keyboard and mouse as well as as a controller (PS4) without issues.

Game: Pilot Brothers
Version: gog-3
Installer MD5: 7a49b05a5b88f65b7cc019bdd0c0a22a setup_pilot_brothers_gog-3_(5221).exe

Distro: Linux Mint 19.1 Tessa | Mate | 64-bit
Kernel version: 4.15.0-72-generic x86_64
Graphics card: Intel HD Graphics
Wine version(s) tested: Wine 5.00-rc3 32-bit
WineHQ AppDB link: no entry for this game

Install notes: Installs correctly. 4 traditional pop-up runtime errors' messages end the installation process, but with no further impact.
How well does it run: Perfect. No issues and well performance. The game has been completed.
Details: I'm using budget laptop with Intel Pentium CPU 3550M 2×2.30GHz + integrated Intel HD Graphics on board. I'm using PlayOnLinux (without their predefined scripts).

It's possible that the OS may be seeing the drive as an external drive and therefore not caching writes in order to ensre the filesystem doesn't get corrupted if the drive is removed without unmounting. You could try changing the cache mode for that drive, or you could try using an internal drive instead.

Try putting the save directory on an internal disk, while the rest of the game runs from the external, and see if that solves the problem.

A very good point, and one I hadn't considered after working for so many years on a desktop.
Write caching is indeed disabled and is likely the culprit. Though enabling write caching (hdparm -W 1 /dev/sdb) didn't seem to make any difference.

These days I'm always traveling, so I never work from an internal disk except on my laptop -- always boot and run on externals or ram sessions, so I've no way to test with an internal disk on this machine (it's presently formatted for windows). Then again, it's got SSDs in it anyway, so I'm not sure how valid a test that would be.

If anyone cares to duplicate I'd be happy to update accordingly, but in the mean time, I've added a note about disk caching being a potential cause.

out of curiosity - why did you use bind-mount instead of symlinks? And is it anyhow better?
Asking coz I've never encountered these before