[Mesa-dev] MESA and KOTOR

Federico Dossena dossenus91 at gmail.com
Sat Mar 25 05:50:37 UTC 2017


Hmm, that didn't work. Turning off GL_ATI_fragment_shader makes the game 
glitch (see attached screenshot), forces framebuffer effects and soft 
shadows to off, and makes the game look worse because the extension is 
used for a lot of stuff like water, characters, and more.
Besides, the guy who implemented the extension (Miklos Mate I think it 
was) did it specifically for KOTOR.

Just to be 100% sure, I would like to compile that GLU that you have in 
your repos, since the error is genrated inside windows's own glu32.dll, 
it might work better with Mesa's. I can't find build instructions 
though, what do I need besides mesa, make and gcc?


Il 2017-03-24 22:42, Brian Paul ha scritto:
> I'm going to re-post my recent wgl patches (verified to work now) for 
> review before committing to master.
>
> Looking at some other notes in our code, there's another issue with 
> KOTOR.  Try setting the following env var:
>
> MESA_EXTENSION_OVERRIDE=-GL_ATI_fragment_shader
>
> The '-' means disable the GL_ATI_fragment_shader extension.
>
> -Brian
>
> On 03/16/2017 12:39 PM, Federico Dossena wrote:
>> I managed to fix the patch and apply it to mesa master, but I'm getting
>> the same result as with my stub. The crash is still the same, in
>> glu32.dll, I wonder if the GLU that you guys have in your repo will work
>> any better. I tried to crosscompile it but without luck, any 
>> instructions?
>>
>> Still, I want to thank all of you for helping me out on this one. I've
>> been fixing old games for years but this one has always been my nemesis.
>>
>>
>> Il 2017-03-16 19:04, Brian Paul ha scritto:
>>> Patch for implementing WGL_ARB_make_current_read attached.  I can’t 
>>> test it at the moment since I’m not near my Windows development 
>>> environment. Let me know what you find.
>>>
>>> -Brian
>>>
>>>
>>>
>>>
>>>> On Mar 15, 2017, at 12:26 PM, Federico 
>>>> Dossena<dossenus91 at gmail.com>  wrote:
>>>>
>>>> That's good, can't wait to see your implementation.
>>>>
>>>> I have tried to simply return wglMakeCurrent(hReadDC,hglrc); but 
>>>> then I get a crash in gluBuild2DMipmaps (not mesa, glu32.dll). 
>>>> According to the specification, it should work, or at least draw 
>>>> some glitches.
>>>> Looking at the parameters passed by the game to 
>>>> wglMakeContextCurrentARB, I see that hReadDC and hDrawDC are the 
>>>> same so I guess they intended to use it as a replacement for 
>>>> wglMakeCurrent, but still, it's not working. So, does 
>>>> wglMakeContextCurrentARB do something else in addition to that?
>>>>
>>>>
>>>> Il 2017-03-15 15:50, Jose Fonseca ha scritto:
>>>>> VMware maintains a Windows OpenGL driver based off Mesa source.
>>>>>
>>>>> We typically open source most of our modifications, but these 
>>>>> haven't been yet open sourced.  No particular reason I believe. 
>>>>> We've been just busy with other stuff.
>>>>>
>>>>> The simplest shim would be to invoke wglMakeCurrent from 
>>>>> wglMakeContextCurrentARB, ignoring exttra arg.
>>>>>
>>>>>
>>>>> Jose
>>>>>
>>>>> On 15/03/17 14:31, Federico Dossena wrote:
>>>>>> Where can I find that implementation?
>>>>>>
>>>>>> Also, is there an alternative to that function? As in a snippet 
>>>>>> of code
>>>>>> that does the same thing and can be used to create a "shim"?
>>>>>> It's so old, I can barely find documentation about it...
>>>>>>
>>>>>> On March 15, 2017 2:42:35 PM GMT+01:00, Jose Fonseca
>>>>>> <jfonseca at vmware.com>  wrote:
>>>>>>
>>>>>>     It looks like wglMakeContextCurrentARB too has been implemented
>>>>>>     internally but not yet crossported.
>>>>>>
>>>>>>     It's far from trivial (especially because Microsoft ICD 
>>>>>> interface never
>>>>>>     was designed to allow implementations to provide alternative
>>>>>>     imlpementations of functions like wglMakeCurrent or 
>>>>>> wglCreateContext)
>>>>>>     though in the way you're using it, it's less important, as 
>>>>>> the original
>>>>>>     opengl32.dll is never used.
>>>>>>
>>>>>>     I don't know how much effort / time it takes to crossport 
>>>>>> this and other
>>>>>>     outstanding patches to master, but my guess is that it would 
>>>>>> be more
>>>>>>     effective to wait a bit.
>>>>>>
>>>>>>     Jose
>>>>>>
>>>>>>     On 15/03/17 06:35, Federico Dossena wrote:
>>>>>>
>>>>>>         I have created a simple stub for wglMakeContextCurrentARB in
>>>>>>         stw_wgl.c
>>>>>>         and stw_getprocaddress.c. It simply returns TRUE, but the 
>>>>>> good
>>>>>>         thing is
>>>>>>         that now the game no longer crashes because the function 
>>>>>> is missing!
>>>>>>         However I get a divide by zero in glu32.dll, presumably 
>>>>>> because
>>>>>>         the stub
>>>>>>         doesn't do jack.
>>>>>>         I tried returning FALSE but the game has no fallback, it 
>>>>>> just
>>>>>>         ignores
>>>>>>         the return values and assumes that everything is fine.
>>>>>>
>>>>>>         From what I've seen, there is no need to override the 
>>>>>> system's
>>>>>>         opengl32.dll like you did for 
>>>>>> wglCreateContext/wglDeleteContext,
>>>>>>         so it
>>>>>>         shouldn't be too tricky to implement the function. 
>>>>>> However, I
>>>>>>         can't seem
>>>>>>         to find any real documentation about what it's supposed 
>>>>>> to do. I
>>>>>>         found
>>>>>>         this at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.khronos.org_registry_OpenGL_extensions_ARB_WGL-5FARB-5Fmake-5Fcurrent-5Fread.txt&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=fUdpS5GuTWuLy5BFTEQD_f8_MfXcrh7ZeLWr6WDKvk0&e= 
>>>>>> but it's pretty vague:
>>>>>>
>>>>>>         The function wglMakeContextCurrentARB associates the 
>>>>>> context <hglrc>
>>>>>>         with the device <hDrawDC> for draws and the device 
>>>>>> <hReadDC> for
>>>>>>         reads. All subsequent OpenGL calls made by the calling 
>>>>>> thread are
>>>>>>         drawn on the device identified by <hDrawDC> and read on 
>>>>>> the device
>>>>>>         identified by <hReadDC>.
>>>>>>
>>>>>>         How do I do that? Do I have to copy the frame buffer? Or 
>>>>>> just the
>>>>>>         pointer? Or am I completely off road?
>>>>>>
>>>>>>
>>>>>>         Thanks for helping me out ;)
>>>>>>
>>>>>>
>>>>>>
>>>>>>         Il 2017-03-14 03:44, Brian Paul ha scritto:
>>>>>>
>>>>>>             Looks like my KOTOR patch never made it to master. I'm
>>>>>>             attaching it
>>>>>>             below so you can try it. I should commit it master. 
>>>>>> In any
>>>>>>             case, let
>>>>>>             me know if it helps.
>>>>>>
>>>>>>             -Brian
>>>>>>
>>>>>>             On 03/13/2017 10:55 AM, Federico Dossena wrote:
>>>>>>
>>>>>>                 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://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_file_d_0B6qj91UlSYlYa3dIM0FtaHNULW8_view-3Fusp-3Dsharing&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=wIA0rhmz7LTqJQNdsTCWPhjT8WafJsNAPOxM5IYqZg0&e= 
>>>>>>
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_file_d_0B6qj91UlSYlYa3dIM0FtaHNULW8_view-3Fusp-3Dsharing&d=DwMDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=u9OxTt6a0b4XxAVoFjjG7RmQNYLAIe3smaD2NtY0mhE&s=h5NDyV1_DsR1WIruLOfH3IDrWkYTa8VEHeC3vIiucF4&e=> 
>>>>>>
>>>>>>
>>>>>>
>>>>>>                 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=SPL0EPazpw03JE7fy8hsKkGEZG_dXNpI6E1b0xrG2S4&e= 
>>>>>>
>>>>>>
>>>>>>
>>>>>>                     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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apitrace_apitrace_wiki_WINE&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=Dqed5TB98LDF0BfqxZagu3S40Um8dCPYfCVeBmIEytU&e=
>>>>>>
>>>>>>                     Jose
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>>
>>>>>>                 mesa-dev mailing list
>>>>>>                 mesa-dev at lists.freedesktop.org
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=u9OxTt6a0b4XxAVoFjjG7RmQNYLAIe3smaD2NtY0mhE&s=jnsrLdbWwBr7d8cUeUr_dxHK8sN25_6TfLQjoVbMCj8&e= 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=SPL0EPazpw03JE7fy8hsKkGEZG_dXNpI6E1b0xrG2S4&e= 
>>>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2017-03-25 06_40_01-Star Wars_ Knights of the Old Republic.png
Type: image/png
Size: 1909874 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170325/b6d8b6a6/attachment-0001.png>


More information about the mesa-dev mailing list