[Mesa-dev] MESA and KOTOR
Federico Dossena
dossenus91 at gmail.com
Thu Mar 16 18:39:12 UTC 2017
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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170316/b12f25a7/attachment-0001.html>
More information about the mesa-dev
mailing list