[Mesa-dev] MESA and KOTOR

[Federico Dossena]

Hi Jose, thanks for replying, I've seen your name inside many files in 
mesa ;)

I have tried mesa master (previously I was using 17.0.1) but it still 
crashes for the same null pointer.
Do you have a link to that patch you've mentioned for kotor?

I have used apitrace and took traces of both the nvidia driver (which 
runs kotor) and mesa (up until the crash).
Here's a link to them: 
https://drive.google.com/file/d/0B6qj91UlSYlYa3dIM0FtaHNULW8/view?usp=sharing

I tried reading them with the dump function but it's way above my 
comprehension.

I know that some applications use wglGetProcAddress to check if an 
extension if available, but I've seen KOTOR check for the 
WGL_ARB_render_texture, and when it's present it enables frame buffer 
effects and soft shadows, which use wglMakeContextCurrentARB (not 
wglBindTexImageARB, I was wrong in my previous mail), which for some 
reason is a null pointer.

////


Il 2017-03-13 14:39, Jose Fonseca ha scritto:
> On 13/03/17 11:09, Emil Velikov wrote:
>> On 11 March 2017 at 11:51, Federico Dossena <dossenus91 at gmail.com> 
>> 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.
>>>
>> Strange - afaict mesa (st/wgl) exposes both wglBindTexImageARB and the
>> WGL_ARB_render_texture extension.
>> You can break on DrvGetProcAddress and trace where/how we end up with
>> NULL function pointer.
>>
>> -Emil
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
> Federico,
>
> You should be using latest master for this.   There have been recent 
> changes/fixes to our WGL implementation.
>
>
> Last fall Brian Paul fixed an issue with WGL extension seen on KOTOR. 
> I'm not sure the the issue has been crossported to Mesa master yet, 
> and it might be unrelated.
>
>
> Generally speaking, wglGetProcAddress returning NULL by itself is not 
> a problem.  Many games wrongly rely on wglGetProcAddress NULL results 
> to detect whether an GL/WGL extension is present (which goes against 
> the spec).  Other libraries try to bindly get every possible 
> entrypoint through wglGetProcAddress, then check which ones to use 
> based on supported extensions (which is actually fine by the spec.)
>
>
> For the record, getting an apitrace is usually useful to debug this 
> sort of issues.  One can use apitrace straigh from windows or with 
> WINE -- https://github.com/apitrace/apitrace/wiki/WINE
>
>
> Jose

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170313/d4336ba2/attachment-0001.html>