<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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?<br>
    <br>
    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.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Il 2017-03-16 19:04, Brian Paul ha
      scritto:<br>
    </div>
    <blockquote
      cite="mid:F929EAEB-6743-44BF-989F-8C61161793DF@vmware.com"
      type="cite">
      <pre wrap="">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
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">


</pre>
      <blockquote type="cite">
        <pre wrap="">On Mar 15, 2017, at 12:26 PM, Federico Dossena <a class="moz-txt-link-rfc2396E" href="mailto:dossenus91@gmail.com"><dossenus91@gmail.com></a> 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:
</pre>
        <blockquote type="cite">
          <pre wrap="">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:
</pre>
          <blockquote type="cite">
            <pre wrap="">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
<a class="moz-txt-link-rfc2396E" href="mailto:jfonseca@vmware.com"><jfonseca@vmware.com></a> 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
<a class="moz-txt-link-freetext" href="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=">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=</a>         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:
<a class="moz-txt-link-freetext" href="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=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=SWh6lT89FsLAyTgJ-rsJ9RAojPix3V1ZDKyBjIR31pI&s=wIA0rhmz7LTqJQNdsTCWPhjT8WafJsNAPOxM5IYqZg0&e=</a> 
<a class="moz-txt-link-rfc2396E" href="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="><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=></a>


               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
                       <a class="moz-txt-link-rfc2396E" href="mailto:dossenus91@gmail.com"><dossenus91@gmail.com></a>
                       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
                       <a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="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=">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=</a> 


                   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 -- <a class="moz-txt-link-freetext" href="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=">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=</a> 

                   Jose




------------------------------------------------------------------------

               mesa-dev mailing list
               <a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="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=">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=</a>







-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
</pre>
          </blockquote>
          <pre wrap="">
</pre>
        </blockquote>
        <pre wrap="">
_______________________________________________
mesa-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="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=">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=</a> 
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>