[Mesa-dev] MESA and KOTOR
Federico Dossena
dossenus91 at gmail.com
Wed Mar 15 18:26:07 UTC 2017
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://www.khronos.org/registry/OpenGL/extensions/ARB/WGL_ARB_make_current_read.txt
>> 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://drive.google.com/file/d/0B6qj91UlSYlYa3dIM0FtaHNULW8/view?usp=sharing
>>
>> <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://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
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> 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.
>
More information about the mesa-dev
mailing list