On 25/03/17 05:50, Federico Dossena wrote:
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?
That's a dead end. I never header anybody using anything but Microsoft
GLU32.DLL . Even if I thought it was a worthwhile endeavor, I have idea
how to build it for Windows, or even if it can be built. Probably
nobody does.
If there's a divide by zero inside glu32.dll then probably that's
because Mesa is return zero where it shouldn't.
It might be worth trying to get an apitrace. It should trace all calls
done by GLU32 -> OPENGL32.DLL, so you might find the odd one by
inspecting the calls immediately before the crash.
How are you using Mesa opengl32.dll? Are you just putting it on the
same dir as the game? I think that.
Most of the testing we do is via Microsoft OpenGL ICD interface:
WGL ICD
APP.EXE ----> OPENGL32.DLL ---> DRIVER.DLL
(Microsoft) Mesa
But when put Mesa's opengl32.dll into the game dir, you're actually
using Mesa's WGL -> ICD "shim", which is fairly imcomplete and not
throughly tests.
My recommendation is for you to crate a Windows VM without any 3D
enabled, then follow the mesa/doc/llvmpipe.html registry instructions to
use Mesa's opengl32.dll as an ICD driver.
Jose
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<dossenu...@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
<jfons...@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
<dossenu...@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@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@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@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=
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
