[Mesa-dev] MESA and KOTOR

[Miklós Máté]

Hi,

sorry I'm late to the party, now I'll try to answer some of the 
questions raised in this thread.

On 11/03/17 12:51, Federico Dossena wrote:
> In the last week I've been trying to bring an "old" game back to life, 
> Star Wars Knights of the old republic (KOTOR, for short). It's from 
> 2003 and uses OpenGL 1.4.
>
> I have used Mesa, libtxc_dxtn and some trickery to decompress the 
> textures to boost performance, and right now I have it up and running 
> smoothly with Gallium on LLVMPipe, compiled on Windows. (I can upload 
> a copy if someone is interested). This took me about 2 days of 
> compiling and figuring out stuff.
>
> Here's where the weirdness begins:
> Turning on framebuffer effects or soft shadows make the game crash 
> right after the menu. Using a disassembler and debugger and what 
> little knowledge I have of reverse engineering, I managed to track 
> down the issue to a function which uses wglGetProcAddress to get the 
> addresses of several OpenGL functions. Some of these calls return a 
> null pointer (even if there is a valid context and it is current), and 
> when the game tries to call them, it crashes. The first one that makes 
> it crash is a pointer to wglBindTexImageARB, but there are a few 
> others. NOPing the offending instructions did not work, and returning 
> a nop function just makes the game display artifacts.
I couldn't get the post-process effects to work with llvmpipe+wine 
either. I think llvmpipe (and the other software rasterizers in mesa) 
have problems with frontbuffer rendering. KOTOR uses a series of 
pbuffers, which only have GL_FRONT, to draw the post-process effects and 
then wglBindTexImageARB to composite them onto the image (a dozen times 
per frame).

I didn't spend much effort to fix this, because I thought llvmpipe was 
too slow to run the game anyway (2-3fps), and the post-process effects 
are great performance hit even for a hardware-accelerated driver: on my 
phenom2+pitcairn combo KOTOR (wine) is cpu-limited at ~100fps without 
pp, and gpu-limited at ~60fps with pp. I guess if someone implemented 
wglBindTexImageARB as a zero-copy render-to-texture method (as it was 
originally meant to be), the performance would be better.

>
> This issue is not new: a guy named Miklós Máté, here in the Mesa 
> mailing list somehow managed to fix it in Mesa 11, but his patches do 
> not seem to work anymore 
> (https://lists.freedesktop.org/archives/mesa-dev/2016-February/106695.html). 
> I tried to contact him but without luck.
> The issue affects LLVMPipe, Softpipe and OpenSWR, so I think it's 
> something in Gallium itself.
I tried to explain in PM that my patches still work. They were all 
merged into mesa, and KOTOR works fine with mesa 12.0 and wine 1.9.12 or 
later. It seems my efforts were inadequate.

>
> Nvidia's OpenGL driver is the only implementation that seems to work 
> properly with this game at the moment, so if someone here's willing to 
> help me out with this, a lot of people would be very grateful, and I 
> am willing to pay too.
This is not entirely true. With my previous two video cards (Radeon 
9600XT and HD6850) KOTOR ran fine on windows. With my current card (R9 
270x) the official AMD driver on windows and linux incorrectly renders 
the alpha instructions of ATI_fs (when you walk in grass your leg 
disappears), and it segfaults from the post-processing. That's 2/3 of 
the official AMD drivers that work correctly :)

The rest of the thread:

Jan Vesely mentions that on intel KOTOR displays artifacts. I think 
pre-r200 cards were too slow for rendering the grass, and bioware didn't 
bother testing it without GL_ATI_fragment_shader or 
GL_NV_register_combiners. Without grass or with the ilo gallium driver 
:) the game should be playable on intel gpus.

Jan also mentions that he couldn't enable soft shadows. If that happens, 
you need to add AllowSoftShadows=1 to the [Graphics Options] part of 
swkotor.ini.

The null pointer problem: KOTOR assumes that WGL is feature-complete, 
and doesn't check for null pointers. WGL_ARB_make_current_read and 
WGL_ARB_render_texture are simply required for the post-process effects.

The GLU problem: I don't think microsoft's glu implementation was tested 
with anything beyond GL 1.1.

Sorry for the long and incomprehensible email,
MM