I'm considering buying this, but is it possible to run the Windows version without much problem with Wine?

Given that it has a native Linux version and not many people bothered yet it's a question hard to google.

Anyone? Same question here.
Any chance someone checked how the game runs under Linux/Wine?

A quick visit to Lutris shows there's no usable recipe for it. Sometimes you can get clues from the Steam recipe on how to get it to work with GoG installers. However, in this case, it appears the Steam recipe simply pokes Steam to install the Linux version.

Well it's not like Lutris has install scripts for EVERYTHING so this is really no indication.

So I guess it would require lots of manual digging to produce a meaningful report.
But I would say that this game would very likely work fine with enough digging so I guess it's only a matter of time and somebody's effort to make an install script / guidelances for it.

I got the game running using Gamehub and the latest version of Proton.

I had to disable E-Sync, F-Sync as well as D3d10 and D3D11 (Last two may not matter).

Game had some very faint audio pop (nothing major and after a little bit you don't even notice it) but was very playable.

I have been messing around with the settings for a bit. Here are my results:

Audio:
I changed the Audio API from XAudio (default) to OpenAL in the settings due to crackling. Audio was fine in OpenAL mode

Graphics:
Graphics API: DX11 (without DXVK)
The menues work, but the in game graphics are complete garbage

Graphics API: DX11 (with DXVK)
Playable, but still graphics issues (texture flickering on all textures).
The game crashed, when chaning graphical options. The game crashes when exiting the game

Graphics API: Vulkan
Playable. but still graphics issues (texture flickering on all textures). I tried various different graphic options, but couldn't resolve the flickering issue. No crashes.

I have tried with wIne 5.0.2, wine 5.7.10 (lutris version) and proton 5.0, but didn't see any difference.

System:
Linux Mint 20 (Kernel 5.4.0-48)
Nvidia GeForce MX150 (driver: 450.66-0ubuntu0.20.04.1)

I have it running on my Debian Testing. (Kernel 5.8.10, Mesa 20.1.8, AMD RADV NAVI10 LLVM 10.0.1)

I use an older Wine Staging 5.2 64bit in PlayOnLinux with DXVK 1.5.5. It's the same virtual drive i use to play Obduction, Megadimension or RiMe.

Some Quirks:
At first the sound was filled with crackling noise too. Longer sentences were misaligned with the subs and cut off at the end. The Log "Talos.All.log" was spammed full with
[...]
14:34:34 WRN: Failed to detect default audio endpoint. Using the first available sfx adapter.
14:34:34 WRN: Failed to detect default audio endpoint. Trying one more time...
[...]

Changing from Xaudio2 to OpenAL resulted in louder and better audio. But the Graphics got instantly corrupted with black flickering in hexagonal figures on the ground with diagonal lines.

The solution for me was to change back to XAudio and simply choose the right output device in the same menu.
I had to choose between:
default
1: Default Device
2: Navi 10 HDMI Audio device
3: Starchip/Matisse HD ...

By choosing "2: Navi 10 HDMI Audio device" the crackling vanished. (I'm aware that this or the list is specific to my configuration.)

The game still crashs and want to send an bug report after i quit. (like MrMuggles described it)
As a result: At every start it asks "Do you want to start in safe mode?". Which i kindly decline.

The game checks some sort of graphics driver version for a required minimum. For some reason it is coming to different conclusions (1014, 1018, 1022) at each start of the game. I had to manually edit the Checkdriver.lua at line 47 to expect a lower version as 1100.
Usually the first try results in an message box with "Display driver is too old..." or a lightgrey fullscreen window with annother error and an Access Violation in "Talos.All.log", which i'm failing to reproduce since then.
The second try starts the game without any error.

Maybe it is something on my end like the slow network drive (an nfs-share from my NAS).

The game itself runs flawlessly (with DirectX11 and DXVK). I tested/played 2-4h and cleared door 1-4 from building A without any crashs or problems.

I just changed back to XAudio and set the device as you described and that solved my texture flickering problems. I would never have guessed, that the Audio API would cause graphical glitches.

But with that solved, the game runs perfectly fine for me.

PART 1 / 2 To you and to anybody who will show up in this thread (that is willing to report any results).
PLEASE when reporting specify if you are running game with Galaxy or standalone (offline installer).
It actually DOES make a world of difference in terms of 1.Installation procedures 2.Prefix configuration (Galaxy has it's own dependencies which usually don't overlap with games) 3.Runtime flow (different errors may occur, things may fail at different times, different overhead, etc).
Please specify while reporting as configuration for the two is usually different.

Also, if we are going to make this thread internet centre for info about running Windows build of this game through Wine then please:
1.KEEP THIS THREAD CLEAN
2.Provide as much details as possible, including but not limited to:
- exact Wine version (specify if custom build too)
- type of Wine prefix system (XP, 7, and so on)
- any used LD_PRELOADS
- any used env vars, EXPORTs, etc
- your kernel version (yes that is relevant)
- your kernel type (Distro provided [it almost NEVER is vanilla], vanilla, Liqourix, Zen, etc]
- your GPU driver version (if you use custom compiled in patches or non standard branch or GIT then please specify too)
- used shader compiler (ACO, llvm, others)
- if you have WM compositor enabled while running the game (it is very relevant) + if you have window decorations ACTUALLY in use while using game
- your used WM and / or DE
- if you use Wayland or X11 (or rootless X11)
- your exact audio backend (Pulse, Jack 2, Jack, Alsa, Oss, etc)

PART 2 / 2

- any custom config that you have for the audio backend (such as Pulse "never idle", the infamous nobody-knows-the-docs "pulse latency msec", if you have set default sink, maybe also what exact audio card you have, if you use tsched, etc)
- your exact CPU model (how is this relevant? It is because different CPU support different instruction sets, say SSE4_2, and there are games that require some exact versions [maybe even without anybody saying it officially on requirements page])
- if you use SMT in your CPU
- your Linux Distro
- this is rarely relevant but sometimes is - your storage / IO / system schedulers (especially if they are highly non standard)
- if you run the game from HDD / SSD / other things - some games have high storage demands (but of course that usually ISN'T specified in requirements "because no") and glitch (for example texture pop-in, and other things that are hard to diagnose and wouldn't suggest slow storage as the primary culprit) when the device is too slow
- your mouse polling rate (the joke's on you, if you don't know exactly what this is about you would be amazed when discovering the premise's details, there is certain long running Wine BUG [yes Wine devs, this IS on you, acknowledge it already DARN!] that produces stuttering above certain mouse polling rates)
- if you use FreeSync / G-Sync / Vesa Adaptive Sync
- if you use Lutris / PlayOnLinux / any other helper software
- if you have enabled networking during game runtime (this is relevant in lots of ways, such as for example some games try to phone home and some of their functions fail if they meet problems)
- your monitor refresh rate (some games break with some configurations)
- your keyboard polling rate (same BS as with mouse tho somewhat different appearance ratio apparently for whatever reason)
- bits of your Wine prefix (32, 64)
- any Wine DLL overrides (specify types, details, etc)
- game uptime during testing (some stuff breaks after specific time, some games memory leak, some games go out of memory due to missing 64 executable, etc)
- if you used GPU model / vram amount spoofing
- if you have enabled gamepads / joypads / etc in Wine config
- if you have Wine symlinks enabled (present by default, sometimes breaking stuff, afaik they are usually not needed for ANYTHING)
- if you have gamepads connected while running game (even if not used while in game)
- if you use any gamepad / input mappers / wrappers (xboxdrv, etc)
- what input method do you use in the game
- if you have connected input audio devices while running the game (some games try to grab audio input and may run into unexpected and hard to diagnose issues and / or stutters when run through Wine)
- if you have connected USB audio cards while running the game (some games have shitty code and react badly to them due to various reasons)
- if you used any mods
- if you have / use any Aura / Razer / RGB-whatevername shebangs (some games use it, some games react weirdly to it)
- if you use CSMT
- if you use Esync / Fsync / Async
- if you have Virtual Desktop enabled in Wine
- if you have mouse warp override enabled in Wine
- if you have any non standard Wine config

- any other details you see as valuable info
- preferably runtime debug logs (just don't go TOO FAR with their verbosity)

edit: ( I forgot the most obvious crap. Lol )
- obviously also your GPU model (some software really breaks with some models)

From our tests with ./play.it team, The Talos Principle can run almost flawlessly on Linux. See this thread for more details: [./play.it] Install The Talos Principle on Linux

Well a few days ago a user posted the message,that the linux version on steam is broken in some way:
https://www.protondb.com/app/257510

So I have no idea what is going on. Maybe that is why there is no Linux version on GoG? they beaked it somehow? ¯\_(ツ)_/¯

What? THAT? ( https://www.protondb.com/app/257510#G42J585ma_ )

First of all:
ProtonDB is not meant for nor is actually used for (by pretty much ANYBODY; I am YET to see a native version report there actually) for reporting runtime results for NATIVE versions of games.
If you see there a report for a game that has native Linux port then it means that the report in question regards running windows port and not the native one.

Well, I posted somewhere else on GOG in relation to that specific report (at least I think I did).
That report is trash. Period.
I don't know if and how much you crawl ProtonDB, and what is your experience with Linux gaming comprehensive reports, but I have been digging through it and have vast experience and can easily tell you that this report doesn't fall even under "amateur" category.
It is just SO BAD it's practically useless.

Why?
Well first off, on WineHQ, on ProtonDB and in a bunch of other related places there is pretty large percentage of people that produce imcomprehensible reports due to one of these reasons:
1."I don't know what I'm doing but I want to show off that I reported something on the internet"
2.Not experienced enough to know how to fix things (stuck at "garbage" rating for silver+ rated game)
3.Only testing if things work COMPLETELY out of the box (WITHOUT ANY user intervention nor work) and if not then they just slap GARBAGE (Proton "broken") rating on it (this way A LOT of silver+ games get "broken" rating).

Also for these people report verbosity generally doesn't exist and their reports are laconic and lacking necessary details which only adds to the insult.

This specific report seems like a combo of all 3 points.
When you check other reports of that person ( https://www.protondb.com/users/1221197695 ) you will see that this persons' reports have steaming pile of utter TRASH quality.
Heck, you can easily find that this person has made 2 EXACTLY THE SAME (down to the punctuation and WHOLE system details) reports for 2 DIFFERENT games around the same time...
And "coincidentially" one of those games is Talos Principle.

I am sorry to say that (ACTUALLY I am not sorry at all. I have NO MERCY for incompetence and job butchers [I don't know if this is right expressions. I mean the people who make the whatever task botched]) but this person's reports are completely incompetent and useless.

Now, if you actually read that trashy report you will IMMEDIATELLY notice the "It was working fine but".
So, basically this person had this working before but DIDN'T BOTHER to report it then.
They only reported it after things broke down and without giving any meaningful details.
Just WHAT is the point with such a report then? It's like posting a picture on some social platform with "my car broke down". Seriously.
This is not only useless. This is MISLEADING to others.

Also, this person uses GPU ( AMD Radeon RX 5700 XT ) that is known to trip and break A LOT of games.
Even now this GPU is causing a lot of problems and back when it was launched it was a total wild west for most people running games on Linux. This alone could break this game without breaking it for others (possibly).

I cross-checked driver and kernel versions against Arch package repos and they seem to align (not "partial upgrade" at least for these two) but WHAT IS this "4.6" before "Mesa" supposed to mean anyway? (Compatibility profile? How is this related to Vulkan AT ALL?)

Note: Linux vanilla kernel (which Arch kernel is almost exactly 100% vanilla except for some rare manual changes) didn't use to have Fsync patches and I don't think it does have them now still (I don't use this kernel personally).

Now, funny things await on Github.
https://github.com/ValveSoftware/Proton/issues/2861
First off, the reporting profile, not to judge but essentially a "repo preserver" (AKA "ima fork this and that 'just because'") fro the looks of it.
Now for the report:
GPU "maybe" within requirements, but BARELY
weird non-standard screen resolution
old Mesa version from before ACO was even in Mesa-Git (let alone in stable release)
is using i3 WM (notorious for causing problems with games)
using Ubuntu of all things (MAYBE "ok" system for inexperienced people, but nowhere near up-to-date and an actual burden when game TROUBLESHOOTING is neccessary)

This report contains bare minimum of neccessary details and nothing else.
Doesn't involve advanced troubleshooting nor is followed by retesting.
Pretty useless out-of-date report essentially.

The problem seen in both ("Cannot set display mode") seems like one that could be fixed with moderate research.
I made <30m research and found that it is related to Croteam's "Serious Engine" specificly and dates at least until 2010.
I don't feel like digging into technical details now (I have to go sleep, I am heavily sleep deprived) but it MAY be related to non standard resolutions (there is rich history of games using various engines that break, glitch, crash or just refuse to work should there be custom resolution involved).
Could possibly be fixed with something similar to these:
[url=https://www.pcgamingwiki.com/wiki/Serious_Sam_3:_BFE#4K_Ultra_HD]https://www.pcgamingwiki.com/wiki/Serious_Sam_3:_BFE#4K_Ultra_HD[/url]
[url=https://www.pcgamingwiki.com/wiki/Serious_Sam_Classics:_Revolution#Widescreen_resolution]https://www.pcgamingwiki.com/wiki/Serious_Sam_Classics:_Revolution#Widescreen_resolution[/url]
(it's pretty stupid how on their own engine they change cvars SO MUCH between iterations)
Also the issue "might be" related to DX9 dlls [dlls specificly, NOT the api itself, so Wine overrides could be desired] in some ways:
https://steamcommunity.com/app/41000/discussions/0/451850468372366926/

I did some more digging and on Steam most people experiencing issues with it are advised to switch to legacy version branch (which OBVIOUSLY isn't available on GOG).

I honestly don't feel like spending actual time trying to fix someone elses bug when I don't even own this game atm.
Sorry. If I would own it and should I have the bug in question I would likely dig deep enough to fix it.
The thing is this bug isn't new and fixes are likely out there.
Just people reporting didn't bother to look for them.

My point here is these 2 reports are half-a**ed and are worthless.
They are NO INDICATION of current status of this game.
They contain no details, no useful logs, no troubleshooting steps, NOTHING.
First one (on ProtonDB) is "I tried it and it just didn't work (and I didn't fiddle with it further to try to fix it)". And the one on Github is "here are my specs, the game doesn't work, the end of the story".

If you want more competent reports here are some examples (and these AREN'T examples of "extreme details"):

(people working on issues collectively by providing multiple reports and retesting, also decent reports)
https://github.com/ValveSoftware/Proton/issues/2307

(pretty good description of issue, cause and impact [shader compiling stuttering caused by rather slow pre-ACO llvm Mesa compiler])
https://www.protondb.com/app/502500#ulZk-mUka9

(not being biased [some people ignore that 1.Issues are often on windows too 2.Windows fixes often work under Wine too] and just reporting findings for betterment of others)
https://www.protondb.com/app/502500#rxYMYJ2Oxd

(not detailed enough but at least putting a clear warning about issue)
https://www.protondb.com/app/502500#rxYMYJ2Oxd

(example of more involved community efforts)
https://github.com/ValveSoftware/Proton/issues/124
(even more involved somewhat)
https://github.com/ValveSoftware/Proton/issues/2121

(valuable report)
https://www.protondb.com/app/235460#xexulgjvec
(trash report for comparison)
https://www.protondb.com/app/235460#dC385bI9ts

(more valuable report examples)
https://www.protondb.com/app/863550#VK0dEqPtfv
https://www.protondb.com/app/863550#bjJn1WdQtd
https://www.protondb.com/app/863550#xx_WLnI4ya
https://www.protondb.com/app/863550#xfeM_oZGhW

The problem with both ProtonDB, WineHQ, and some other places is:
1.Most game test runs never make it to reports (even when working perfectly)
2.If game is not very popular (or has native version) then combined with 1 the report page may be completely empty or filled with "n**b garbage reports"
3.It is a rule that people generally don't retest or don't post results for new versions (laziness, incompetence, lack of effort, etc)

You just should never put a cross on a game or assume ANYTHING based on one sh***y report.
ALWAYS do extensive background checks.
In these case these reports are hot garbage proving NOTHING (they aren't verbose enough to prove anything).

The Talos Principle: Gold Edition

Distro: Ubuntu 20.04
Kernel: 5.4.0-7642-generic
GPU Driver: NVIDIA 440.95.01
GPU: NVIDIA GeForce GTX 1070 Ti
CPU: AMD Ryzen 7 1700X
Wine: lutris-5.7-x86_64

This is how I got it working, I had the same audio cracking and graphical glitches as others. In the Lutris runner options I disabled DXVK, then in game I switched to Vulkan for the graphics API and OpenAL for the audio.

This fixed the audio cracking but not the texture flickering, no changing of the graphical settings worked. But what did work surprisingly was to run the benchmark, The benchmark ran without glitches and then after it was done the rest of the game ran fine.

TL;DR
- Disable DXVK
- Switch to Vulkan
- Switch to OpenAL
- Run Benchmark
- Start New Game