Star Wars Knights of the Old Republic (32370)

[d10sfan]

Game launches and I'm able to see the intro movies, but the menu is just black. The cursor shows up and I can hear the music.

steam-32370.log

[fazo96]

edit the swkotor.ini file next to the game binary and set the game to a windowed 4:3 resolution like 800x600.

This fixed your problem for me. I played for a very short time but the game ran perfectly

[d10sfan]

Tried that (800x600) and then the top half of the game was clipped outside the screen for some reason. I then tried 1280x1024 and that loaded ok and after restarting, the mouse and everything worked great.

[ElricleNecro]

Just to avoid people having to search everywhere how to put the game in windowed mode. Add to the swkotor.ini file under the [Graphics Options] section :

Height=1024
Width=1280

And change FullScreen=1 to FullScreen=0

[tbsteinb]

This is actually an issue in Windows too. Everything else works perfectly, so this should be ready for a whitelist request.

[bjoern-tantau]

In my case I had to set

EnableHardwareMouse=0

as well to get the mouse cursor to line up with buttons. But still sometimes it won't line up perfectly with buttons or dialog options.

And videos play for me only very small (probably their original resolution) in the top left corner.

Installing the game through Lutris works perfectly, though. I think it is because there wine actually does a modeswitch to the proper resolution.

[MikaelBox]

I can't play this game, because the game auto closes after hero select and the game loading. Proton log: steam-32370.log

[Graphics Options] V-Sync=1 Anisotropy=1 Frame Buffer=0 Anti Aliasing=0 Texture Quality=1 Emitters=1 Grass=0 Soft Shadows=0 Shadows=1 Brightness=57 EnableHardwareMouse=1 FullScreen=0 Disable Vertex Buffer Objects=1 RefreshRate=60 Width=1280 Height=1024 AllowWindowedMode=1

[codeman101]

Game is playable for me once I changed the settings in swkotor.ini to window mode. However the mouse doesn't exactly line up with menu options when scrolling down them using the mouse. (the cursor is always a little below the selected menu option) Also I hope support for this game could be fixed to give it higher resolutions for the sake of fullscreen mode.

[codeman101]

I really hope this gets fixed. As a temporary solution I've decided to run this game through the windows version of steam under a pure wine prefix so I'm able to play the game in fullscreen.

[adrianlshaw]

Game crashes when loading a save game (same as MikaelBox)

[codeman101]

Discovered a better fix for the screen issue. The latest version of the fork here fixes it. https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.11-GE-1-MF If the differences can be checked out and merged that'd be awesome.

Edit: Played for a good couple of hours or so. No issues with it other than having the active character freeze sometimes and having to switch to another in the party to get around but I'm pretty sure it's also a Windows bug so needless to say the GloriousEggRoll fork made my weekend. I really hope the main proton gets to this point as well. Oh also I suspect the fork is doing automatically what I used to do manually which is changing my screen res and then changing it back when I exit the game. I suspect this because I noticed the icons on my desktop got moved to the top left corner of the screen and I think it happened after playing but honestly IMO it's a very small price to pay.

[oxr463]

Just upgraded to Ubuntu 20.04 LTS and now I am getting this error:

EDIT: I was on Proton 4.2-9 before, and then upgraded to 5.0-9. I downgraded back to 4.2-9 and the launcher is working again.

Proton-GE

Discovered a better fix for the screen issue. The latest version of the fork here fixes it. https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/5.11-GE-1-MF If the differences can be checked out and merged that'd be awesome.

I tried this, however, I am now getting this error:

steam-1286830.log

--

I upgraded my drivers and changed it back to 5.0-9 and now it's working!

[fazo96]

I tried the game on Proton 6.3-6 RC today and the window workaround is not needed anymore.

However, @adolfintel has found an issue where if soft shadows are enabled, sometimes after a loading screen the rendering of the game is wrong: the entire world is not rendered and only characters and some dynamic objects are rendered. When the bug is triggered, the only solution is either turning off soft shadows or restarting the game. The bug is random and can be replicated by repeatedly loading a saved game until it triggers.

Soft shadows are not enabled by default so to replicate the bug they must be turned on from the advanced graphics settings. We replicated the bug on both an Nvidia GTX 1080 running proprietary drivers and an AMD gpu running open source drivers.

Here is a photo of the issue:

[adolfintel]

I can confirm that KOTOR is absolutely unplayable on Proton as of version 6.3, including branch 6.3-next which supposedly makes it playable (#5065).

These are my findings so far:

• Proton 6.3-6 RC with AMD open source driver or Intel open source driver: the game gets forced into using the wrong pixel format, which causes visible banding in the smoke in the menu. Ingame, rendering is completely broken when either soft shadows or framebuffer effects (post processing) are enabled (see screenshot at the end of this post), since those effects work by processing the rendered image, whose pixel format has been messed with. The game also crashes after 3-4 area transitions
• Proton 6.3-6 RC, NVIDIA proprietary driver: see @fazo96's post
• Proton 6.3-6 RC, LLVMPipe software rendering: black screen
• Wine 6.14-staging, AMD open source driver, NVIDIA proprietary driver, Intel open source driver: the game renders correctly (has been rendering correctly since around 2019), but it crashes after 10-12 area transitions, meaning it crashes very frequently after the first few hours and is therefore not playable
• Wine 6.14-staging, LLVMPipe software rendering: same as above, but anisotropic filtering doesn't work too

These tests were performed on:

• CPUs: AMD 5800X, Intel Core i5 8250U
• GPUs: AMD RX550, NVIDIA GTX 1080, Intel UHD 620
• Manjaro 21.0.7 (Linux 5.13)
• KOTOR versions: 1.0.3 (Steam), 1.0.3 (GOG)

Game settings:

• 1280x1024 resolution, windowed mode for convenience
• All graphics settings enabled, including advanced settings (enabling VSync is important for this game!)
• 4xMSAA, 16xAF
• Disable Vertex Buffer Objects=1 in swkotor.ini (does not affect graphics quality, it was meant to improve performance but makes the game unstable)

To replicate the area transition crash:

1. Save game by pressing F4
2. Reload the saved game by pressing F5
3. Repeat until the game crashes

I did some investigation about the area transition crash, and made a few discoveries (assume GOG executable here):

• The crash does not occur in Windows
• On Wine, the crash always occurs after reloading 10-12 times, regardless of where you are in the game
• The crash always occurs at address 0x46be9a, but it's not always the same crash: 70% of the time it's a null pointer (in register EDX), while 30% of the time the pointer is invalid
• Rarely, the game will not crash but display corrupted graphics instead (all static geometry is invisible). When this happens, you can safely save the game and restart it without issues
• Changing the resolution resets the "10-12 area transitions counter". This calls a function at address 0x44dab0 that initializes the engine. In theory, triggering an engine restart with this function before or after each area transition (only takes a handful of milliseconds) would fix this, but my reverse engineering skills are limited and I wasn't able to do this

Screenshot of KOTOR on Proton 6.3:

[alasky17]

@adolfintel On AMD, there is an upstream mesa update to dri.conf that should help with crashes. You can just put the attached dri.conf file at this location "~/.drirc" (note - the file should be renamed .drirc). It will work as long as you are using Mesa 21.1 or newer. As a warning, this file will impact other things besides KOTOR - you can just delete it or move it in order to not interfere with other games etc. dri.txt

[adolfintel]

@alasky17 Can you point me to that dri.conf? Thanks

[adolfintel]

Will try it, thanks :)

[adolfintel]

@alasky17 That seems to have done the trick. I removed the configuration for all the other games and KOTOR seems to work fine with Wine 6.14-staging. Of course, I'll have to do a full playthrough of the game to be sure... :smile:

Where does this file come from? I'd like to know more

[kisak-valve]

The driver workaround landed in https://gitlab.freedesktop.org/mesa/mesa/-/commit/bdd8646306b0dad87747425812039e24da808b62, which is in mesa 21.2.0 and newer. The file comes from https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/00-mesa-defaults.conf.

[adolfintel]

That is awesome, I've been keeping around an old PC specifically for KOTOR and now I can play it properly on linux. I had no idea it did that with texture names.

[emarleau]

I get weird color banding using proton 7.0-1 and the soft shadow bug is still present. I'm using the latest Nvidia proprietary driver on Arch Linux. Otherwise, the game runs very well.

[adolfintel]

I can confirm @emarleau's screenshot, I have the same problem on a 6900xt and going back to an older version of proton fixes it. In addition to that, performance is pretty bad in some spots, but it seems to be a mesa issue.

[Blisto91]

If there is a graphical issue which seemed fine in a older version of proton then there is likely a dxvk regression. Which version of proton did it start appearing? 7.0-1?

[adolfintel]

@Blisto91 the game uses OpenGL so dxvk is not involved. The problem started with 7.0-1 as far as I can tell, I'd like to bisect the issue but it takes hours to do a build

[Blisto91]

@adolfintel Oh derp. Just saw DirectX®: Directx 9.0b or better on the steam requirments page and assumed 😁

[emarleau]

I just tried the game with Proton 7.0-2. The color banding and the soft shadow bug is gone. The game is now working perfectly for me.

[mtmkls]

I just tried this game with Proton 7.0-2 (radeonsi, Mesa 21.3), and framebuffer effects don't work: light glows don't show up, stealth mode turns the character completely black, force speed turns the whole screen black, etc. Running the game with vanilla Wine 7.6 works perfectly.

BTW if soft shadows is greyed out in the menu, add AllowSoftShadows=1 in swkotor.ini in section [Graphics Options]

Update: turning off MSAA fixes the framebuffer effects

[ProjectSynchro]

Using Mesa-Git (with an RDNA3 GPU), this game seems to work correctly now with framebuffer effects, soft shadows enabled. and MSAA. It seems like whatever bug was causing textures to fail to render correctly when soft shadows and MSAA were enabled has been fixed.

It might also be fixed in Mesa 23.2, but I haven't tested that. As an added bonus it appears that Zink can be used as well.

[adolfintel]

@ProjectSynchro I've been following the state of kotor on linux for a while now and I can confirm you that it's been playable with mesa-git for about a year now with 23.2 fixing the last minor rendering issue with transparencies.

As for Proton, the invisible world with the white background was fixed recently, but there's still a severe CPU bottleneck that causes stuttering and FPS drops into the 20-30s in areas such as Taris Upper City, even on high end CPUs. A workaround for the bottleneck is to build regular mainline wine with the new wow64 implementation, then the game is perfectly playable, I played through all of it.

About Zink, kotor uses OpenGL 1.4, Zink only supports 2.1 and up, you were probably still using RadeonSI.

[ProjectSynchro]

@ProjectSynchro I've been following the state of kotor on linux for a while now and I can confirm you that it's been playable with mesa-git for about a year now with 23.2 fixing the last minor rendering issue with transparencies.

As for Proton, the invisible world with the white background was fixed recently, but there's still a severe CPU bottleneck that causes stuttering and FPS drops into the 20-30s in areas such as Taris Upper City, even on high end CPUs. A workaround for the bottleneck is to build regular mainline wine with the new wow64 implementation, then the game is perfectly playable, I played through all of it.

About Zink, kotor uses OpenGL 1.4, Zink only supports 2.1 and up, you were probably still using RadeonSI.

The game definitely does launch via ZINK, if it is using radeonsi, then both MESA_LOADER_DRIVER_OVERRIDE=zink and mangohud are not working correctly.

Performance is not as good, and it when MSAA is enabled the framerate definitely takes a hit.

[adolfintel]

Huh, interesting. The documentation says 2.1 and up, they must have implemented older versions too. I'm impressed it can run kotor at all, it's not exactly a textbook opengl application, it even uses some deprecated proprietary extensions.

[ProjectSynchro]

Huh, interesting. The documentation says 2.1 and up, they must have implemented older versions too. I'm impressed it can run kotor at all, it's not exactly a textbook opengl application, it even uses some deprecated proprietary extensions.

Yeah, it also appears to use some non-ratified versions of some OpenGL 2.0 extensions. My guess is that MESA has become a bit more robust when it comes to 'errors' in OpenGL code.

Definitely will keep my eye on it as ZINK can be pretty handy as it can bypass some of the vendor specific code in older games.

[ProjectSynchro]

There seems to be some kind of regression in Proton >7.

For context I am running a modded game wit higher resolution textures and models. While I get this isn't technically making the game 'unplayable' for the typical user, it is a regression nonetheless.

When transitioning between the same location in KOTOR in Proton 7.0-6, 8.0-5 and Experimental, I am getting crashes on any version newer than 7.0.

Here is a crash log from that event. It seems to be related to an access violation for (I'm assuming) an out of bounds memory location. steam-32370.log

In Proton 7.0, this same location using the same modded game I have installed works correctly, and does not crash.

Is there any way I could provide any more information? I attempted to use winedbg to get some kind of useful backtrace, but I didn't have any luck.

As far as a normal unmodified game however, the game runs flawlessly.

[ProjectSynchro]

I have been able to reproduce a crash that appears about 40 hours into the game with Proton Experimental (bleeding edge debug) branch.

steam-32370.tar.gz

Some relevant lines seem to be:

35804.752:0110:0124:fixme:uiautomation:base_hwnd_provider_GetPatternProvider 000000000159D6F0, 10002, 0000000001C3F8A0: stub
35810.809:012c:0244:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
35810.809:012c:0244:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command fence with id 0x1, ret 0x4.
35810.809:012c:0244:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
35810.809:012c:0244:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command fence with id 0x2, ret 0x4.
35810.813:012c:0244:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
35810.813:012c:0244:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command fence with id 0x3, ret 0x4.
35810.813:012c:0244:err:d3d:wined3d_fence_wait glClientWaitSync returned 0x911b.
35810.813:012c:0244:err:d3d:wined3d_context_gl_wait_command_fence Failed to wait for command fence with id 0x4, ret 0x4.
wine: setpriority -19 for pid -1 failed: 3
35810.823:0110:0124:fixme:uiautomation:msaa_provider_GetPatternProvider Unimplemented patternId 10002
35810.823:0110:0124:fixme:uiautomation:base_hwnd_provider_GetPatternProvider 0000000001569220, 10002, 0000000001C3F8A0: stub
35812.819:00d4:00d8:fixme:event:wait_for_withdrawn_state window 0x30030/600002 wait timed out
ATTENTION: default value of option vk_khr_present_wait overridden by environment.