We're doing everything we can to support Linux natively, however if we would want to go this deep, we'd have to start keeping separate builds and testing pipelines for every distribution, and every custom setup of every user. We are a team of 4, and we're doing a game built on a custom engine for 3 different platforms. There's no QA team, there's no publisher, there's nowhere to go then to us. We could develop the game in a snail pace, but considering the development of the custom engine took already 7 years, that would basically kill us. I think this can be fixed but I have no way to test such an event. There's no way to detect AFAIR if the controler has XBox labels or Sony labels, but I might add that as an option in configuration. Add --vk or --gl to the command line. This is something that we'll add soon. Surprisingly, the documentation is already written but not displayed (didn't figure out yet where to put it). Depends if you're asking for a roguelike 'l'ook command or looking around with the camera.

Cheers!
Kornel (project lead)

Thanks for your response. I apologize for not making my intentions clearer from the start: I didn't really expect this to be fixed. I just wanted to mention the issues in case anyone else had them, and also to vent. The game works now, and that's all that matters. I much prefer having to spend effort to get a Linux version running than spending effort fighting wine to get a Windows version working (which may just work, or it may never work). I spent years (OK, I stabbed at it once a year or so for a few hours) trying to figure out what was wrong with the Eschalon series on Linux, and only very recently finally figured it out, even though the games work mostly fine in wine. So, thanks for providing a Linux version that didn't take too much effort to get working in any case.

My issues with having to disable parts of my controller driver and the fullscreen mode issues are most likely issues in SDL2, and affects many games. It's my own fault for not filing bugs against SDL2. The fact that I had to match the resource name rather than the title to fix the iconification issue is weird, but I don't think there's anything you can change to fix that.

As to the other issues:

I only mention the button label issue because it affects many games, and it annoys me slightly. I've gotten used to it, though. Automatic detection of which set of labels to use is prone to error (I've even had 3rd party XBox-compatible controllers with Sony-style button labels), so a preference would be best if you want to implement it at all. Or don't, it's not that important or with the effort.

The command-line option to permanently select Vulkan works. Thanks. Did I miss that in the documentation? It's probably not a solution for the long term, since most users don't want to edit the startup scripts. A prompt on first start is a good idea, and since you store preferences as plain text, it's probably easier to deal with issues by telling people to manually edit or remove the config file if it's so bad that you can't even get to the in-game pref editor to change it. Your call, though. I'm fine with it as is.

As to the looking issue, I guess I haven't played the game long enough to know if it is worth it, but in other games with restricted viewports (approx 21x11?) due to the graphics size, it is generally possible to scroll the viewport. I have not been able to do so in this game. Even switching to targeting mode, the cursor just disappears when it moves off-screen. I guess the minimap might be sufficient, but even in games with such minimaps (AmiOmega comes to mind) it is usually possible to scroll the main viewport. It might also be nice to allow zooming in and out. In any case, I'll have to play a lot more to get used to the graphics.

As to writing into the game directory: I generally don't like games that do this, because I like to keep the installation directory pristine, and in fact change ownership to root to enforce it. For me, this means I have to add a single command-line argument to my game wrapper script, which then sets up unionfs for writing. vv221's ./play.it scripts use soft links by default, anyway, which works as long as you don't try to open game files for writing (which you apparently don't, so that's good). Overall, I'd prefer you store things in XDG directories, e.g. ~/.config/ChaosForge/Jupiter Hell/* for config and ~/.local/share/ChaosForge/Jupiter Hell/ for saves & logs, but it's not that important.

Again, thanks for your quick response, and sorry for my slow return. Also, make sure that gog knows you're a developer, so your posts show up as orange/yellow/whatever that color is.