Running Finmer on Linux

[SyntacticKitsune]

(I think this is the right subforum for this post.)

So here's a little backstory: I'm on Linux. My first attempt at getting Finmer running via WINE never really worked (it'd crash immediately after the character creation screen), so I ended up playing Finmer using a Windows VM (it was great by the way -- Finmer that is, the VM was a pretty ordinary experience).

However, a few days ago I made another attempt (and tried harder this time), and managed to get it running perfectly! Both the game and the editor work fine. (I tested creating a new game, all the way up to the first actual save point. I also tested unpacking Core using the editor, as well as repacking it. I did notice that occasionally some of the text in the "log" gets blurred slightly, but I'm not sure if that's a WINE problem, a Finmer problem, or not a problem at all.)

For anyone else looking to get Finmer running on Linux (although I don't expect there to be many of these such people -- I'm possibly the only one), here's a series of steps to follow:

1. Download and install Lutris.
2. Download a copy of Finmer, specifically the "WithEditor" one.
3. Download the Lutris installation script I created for Finmer.
4. Open Lutris and click the plus in the top left corner of the window, which will open an "Add games to Lutris" dialog.
5. Choose "Install from a local install script".
6. Select the script file you downloaded in step 3.
7. Click "Install".
8. It'll allow you to configure the installation directory and whether to create shortcuts. You can change these if you want. Once you're done, click "Continue".
9. Select the copy of Finmer you downloaded in step 2 and then click "Install".
10. The script will now install Finmer automatically. This will take a while, mostly because it has to install .NET 4.8.
11. Once it finishes, you can close the dialog and click "Play" to launch Finmer (or its editor). Finmer itself will have been installed in a "Finmer-WithEditor" folder inside your installation directory, in case you want to add custom furballs or update Finmer.

[Nuntis]

Thank you so much for sharing this info and taking the time to delve into this, this is very insightful, and I'm sure it's helpful for others who are interested. I'm pretty sure you're not the only one; I've had a few reports of people trying to get the game working on Steam Decks and similar Linux hardware.

I have investigated the crash you described earlier (someone else reported it), but unfortunately it makes little sense to me. A component of the main game window - the scrollable text log, where all the game text will show - is absent. This causes a crash later on when game systems try to manipulate it: when you leave character creation. I do not currently understand what this has to do with Linux, but having no Linux dev environment myself, I can't really reproduce it to test, either - which is also why supporting the platform officially is tricky. It's probably something very fixable, I'm just not seeing it at the moment.

One of the interesting things that stands out to me in your install script is the fact that it disables hardware acceleration. If you re-enable this, does that cause the crash after leaving character creation? Being a WPF-based application, Finmer does make extensive use of your computer's GPU to draw and animate the UI.

As for text becoming blurred: do you happen to have a screenshot of this? Do you see a pattern as to when it happens, e.g. every time after a scrolling animation finishes? I'm going to guess that this is a pixel snapping mechanism not working correctly.

[SyntacticKitsune]

So back when I was trying to get things working I did try to look into the crash a little (since I can at least sort of read C# code) and it didn't really make any sense to me. My best guess is that WPF wasn't being initialized correctly (or something?) causing it to not set up the components, but then I suppose the better question would be why do any other components show up? It might be a problem with the text window component itself, but I'm not certain. Actually -- and this is something I just thought of now -- it could be that Mono (which WINE uses by default instead of the .NET Framework) doesn't support that specific component (since Mono -- or maybe it was WINE -- tries to reimplement WPF as part of its compatibility stuff). This would explain why everything else was there. Regardless, that issue disappears when you add the .NET Framework (but the initial time I tried that the game wouldn't actually boot -- that's what prevented my first attempt from working).

The disabling hardware acceleration I did mostly because the guide I followed to get WPF applications working specifically mentioned black screens and other problems happening when you have hardware acceleration on and have DXVK installed. Lutris comes with DXVK by default, and so I added the hardware acceleration disabling just in case. It is possible to disable DXVK, and that should make the hardware acceleration workaround unnecessary, but I remember that coming with some extra setup requirements that DXVK normally takes care of, so I didn't investigate that.

The blurred text was a bit strange I'll admit. I tried to spot any patterns, but there's no specific spots (ruling out something like my monitor being faulty). It also sticks around (and on the same text), so it's not scrolling that's the problem. My guess was it's some kind of weird artifact caused by any of the workarounds in play here.

I'm testing the blurred text thing again, and I've managed to get it to affect one of the choice buttons. I've attached a screenshot showing that (notice that "North" here is a bit blurry compared to the others). There's also one for the text (here "tad too lightly" is blurred, same with "but feel a little exposed"). I think the scrolling does aggravate the issue, as I didn't notice any blurred text (save for that button) until after the scroll bar appeared, but it sounds like it's probably not the cause.

[Nuntis]

Since the crash disappears when the runtime environment changes from Mono to .NET proper, that suggests that the problem is not with the application but rather the emulation of the environment the application is expecting. You might be on to something with that idea of the emulation being imperfect. It's a little unclear why that is though, since a FlowDocumentScrollViewer (the thing that is breaking afaict) is not exactly a special component; it's a staple of WPF used a lot in news article-, feed- and print-related software too.

Okay, thanks for the info about software rendering; sounds like that isn't related to the crash at least.

As for the blurry text: it's interesting to see that affects specific patches only, as opposed to whole blocks. I mentioned animations and scrolling specifically because they do a bunch of position and opacity interpolation things, which could theoretically leave some text offset by a tiny fraction of a pixel, causing blurring (because the whole font glyph becomes offset). Normally WPF takes care of that by snapping the text automatically though. Though if you're now running on .NET rather than Mono (if I understood you correctly) then there is no compatibility layer, and Finmer should be using Microsoft's original code. Making things even more confusing.

Perhaps this is part of Windows' ClearType features. Like the renderer, it has some tweakable settings in the registry. Maybe this article is an interesting starting point?

[SyntacticKitsune]

Regarding the crash, I looked into whether FlowDocumentScrollViewer might be missing, and it does appear to be there (along with obviously its FlowDocument). It could be that maybe whatever parses the xaml files isn't injecting the FlowDocumentScrollViewer (maybe it isn't set up correctly?), but I'm not sure where I would look. Does an xaml file referencing a nonexistent "control" produce the same missing-UI-component-with-no-errors situation? (I suppose as a workaround you could add a null-check in LogView_OnLoaded that maybe shows a pop-up or something if the scroll viewer for whatever reason doesn't exist. It might help catch people trying to run Finmer using WINE Mono instead of .NET.)

I tried messing with some registry settings to maybe fix the blurry text, but nothing changed. Specifically, I tried turning off anti-aliasing in my system settings (since WINE apparently overrides the font smoothing settings), but other than deep-frying all the text on my computer, nothing else happened. I also tried setting the "Control Panel\Desktop" font-smoothing stuff using Winetricks, which also did nothing (I tried "fontsmooth=rgb" and "fontsmooth=disable").

I would have tried changing the "Avalon.Graphics" ones but those appear to require a display device name, which I'm not sure how to obtain. The documentation you linked implies this information can be obtained using EnumDisplayDevices, which I'm sure would tell me what the "name" of my display is, but I don't know how to use it let alone compile the resulting program (as compiling something that requires Windows APIs on Linux seems like it would range from difficult to downright impossible). I did try to see if WINE already had a builtin thing to list these display devices, but I didn't find anything. I also looked to see if there was any information on this function in the context of WINE, but that mostly only turned up a bunch of people trying to get WINE to use specific displays (which didn't help).

One thing I did notice while trying all this is that the text that gets blurred appears to be deterministic; the same text is always blurred (or at least the "North" button always is -- I didn't test as far as I did the last time). It also looks like bold text is always blurred, although that may also be the case on Windows (I don't remember).

[Nuntis]

If the XAML load fails (or more accurately its processed form BAML), then I would expect the framework to throw an error directly, complaining about not being able to deserialize the document, instead of spitting out half of something that is very obviously broken. I would be very surprised if that were the case.

Perhaps something is wrong with my method of getting at the FlowDocumentScrollViewer; I use some odd trickery to traverse down the hierarchy of UI controls and grab it. This is something I'd just have to debug, though again, the lack of a Linux dev env makes this a bit difficult...

Interesting that you mention the blurry text being mostly deterministic. Does it change if you force the words to break up and/or move around, for example by resizing the game window?

[SyntacticKitsune]

Now that you mention it I do see the odd trickery. In that case maybe the FlowDocumentScrollViewer is somehow turning into some unrelated type (which seems physically impossible, but welcome to Linux: where the impossible is possible), or maybe it's being wrapped in a type that isn't exposing its children correctly (which also seems really unlikely)? I'd be tempted to drop a few print statements in there to see what it's picking up, but alas, I cannot compile Finmer (the lack of .NET and really Visual Studio as a whole makes compilation rather difficult -- and I highly doubt MSBuild wants to touch it without being on Windows).

I went and looked at the text again and it looks like the text in the log is influenced by the window size -- shrinking the window can cause the text to un-blur itself. And in fact I think I just realized precisely the reason some of the text is blurry. So normally Finmer launches maximized -- that is, taking up the entire desktop area. However, it doesn't cover the top and bottom "panels" that I have. Altogether they take up a height of 82 pixels, which drops the effective window area from a height of 1080 to a height of 998 (so Finmer gets a window size of 1920x998 incl. window decoration). This causes Finmer to not recieve a "nice" aspect ratio, which presumably causes some of the text to become blurry. Although I suppose one question would be why doesn't all of the text become blurry?

If I resize the window to a nice size like 1600x900 (using "wmctrl -r Finmer -e 0,0,0,1600,900") then that does appear to unblur most of the blurry text in the log, although it doesn't fix all of the blurred text in the log -- some other text becomes blurred instead (although less than previously). It also doesn't seem to affect the text on other UI components (such as the HP bar). Overall, this has certainly helped, although I don't think it has completely solved the problem. I'm not sure what more can be done though.

[SyntacticKitsune]

An update on the ScrollViewer situation: I added in those print statements (but overengineered because the console for whatever reason didn't exist -- that is, WriteLine did a whole lot of nothing). Anyway, so I've got two log files: one from my Windows VM, and one from Linux. Here's the link. Interestingly, the problem appears to be that the FlowDocumentScrollViewer's Grid just ceased existing (or isn't being returned). I have absolutely no idea what's going on there. It does seem like WINE's WPF reimplementation is at fault, although I'm not entirely sure how. If there's any other logging that would be useful I can see about getting it (now that I have Finmer building correctly, albeit inside a VM).

[Nuntis]

Oh that is a fun one. I suppose the child control actually being absent would do the trick haha. Thank you for taking the time to debug this.

I wonder if it is an implementation flaw, or if it is perhaps simply because the Mono folks decided to implement the FlowDocumentScrollViewer in a different way than what I am expecting. After all, to be fair, I am relying on an implementation detail (the fact that I can extract the private ScrollViewer at all) where that is very much not a part of the normal/expected interface.

If it is not possible to grab the ScrollViewer, then perhaps a solution for this problem could be to simply disable the scrolling animations on Linux. I suppose it could be determined on the fly, based on whether or not the game was successful in trying to locate it.

[SyntacticKitsune]

The situation gets even better. So I've been doing more work trying to get the ScrollViewer that definitely should exist somewhere, and I even tried some reflection to see if I could snag it. Interestingly, the reflection stuff returned null on both the property and field, implying that the ScrollViewer is never set (as opposed to say, throwing an exception for missing properties/fields). Here's the funniest part: I threw in some extra null-checks so I could get into the game, and there's just straight-up no ScrollViewer whatsoever. It just flat out doesn't exist. Where you would expect to see the log, there is only the void. The tutorial at least plays fine, if one can stand the lack of any text aside from what's on the buttons and other three UI components.

I think the best option here if you don't feel like making a custom FlowDocumentScrollViewer reimplementation is just to throw a more informative exception when the ScrollViewer cannot be retrieved (or display some kind of informative popup), since WINE Mono's FlowDocumentScrollViewer implementation is cursed. I don't think there's much else that can be done to handle the FlowDocumentScrollViewer itself being completely broken.