Hello!
I'm sorry for being late to the party.
The patch you linked did land in mesa:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=baab345b192d207236253ce67b320fb32fa67625
However, that area of the code has since been altered a lot.
Back then I made sure that KOTOR ran perfectly with Win
It doesn't even play in Windows to be honest.
Brian Paul is taking a look at it, he is a developer of apitrace I believe.
Anyway, a couple of clues that you might find useful:
* Brian found these calls (these are the ones that make apitrace crash):
3158346 glViewport(x = 0, y = -32, width =
On 09/28/2017 11:25 AM, Federico Dossena wrote:
Sorry if I insist on this again, but can someone who knows the internals
of Mesa better than me please tell me which files implement pbuffers in
gallium llvmpipe? Specifically, the parts that are involved in creating
a pbuffer, its texture, framebuf
Sorry if I insist on this again, but can someone who knows the internals
of Mesa better than me please tell me which files implement pbuffers in
gallium llvmpipe? Specifically, the parts that are involved in creating
a pbuffer, its texture, framebuffer, and (I think) copying the screen to it.
I
Yes his work was on radeonsi, but the patch that he says fixes the crash
with framebuffer effects and soft shadows was in the state tracker.
Link: https://patchwork.freedesktop.org/patch/68298/
The patch never made it to master, and the files touched seem to have
changed a lot since he made th
On Wed, Sep 27, 2017 at 10:31 AM, Federico Dossena wrote:
> Yes his work was on radeonsi, but the patch that he says fixes the crash
> with framebuffer effects and soft shadows was in the state tracker. Link:
> https://patchwork.freedesktop.org/patch/68298/
>
> The patch never made it to master, a
Pbuffers are problematic because it's an ancient feature that nobody
cares about anymore.
I think Miklos made KOTOR work on radeonsi or r600.
Marek
On Mon, Sep 25, 2017 at 6:50 PM, Federico Dossena wrote:
> Hello everyone,
> you may remember that a few months ago I was trying to fix KOTOR to wo
The crash is in GLU, and I'm 99% sure that it has to do with the format
of that texture.
I saw a patch from Miklòs Màté a while ago that changed something in
src/mesa/state_tracker/st_atom_sampler.c to fix this (link:
https://patchwork.freedesktop.org/patch/68298/). It never made it to
master,
On 26.09.2017 12:59, Federico Dossena wrote:
The crash is in GLU, and I'm 99% sure that it has to do with the format
of that texture.
So how about a backtrace?
It would be really valuable to have a simple stand-alone reproduction.
Cheers,
Nicolai
I saw a patch from Miklòs Màté a while ago t
On 25.09.2017 18:50, Federico Dossena wrote:
Hello everyone,
you may remember that a few months ago I was trying to fix KOTOR to work
with Mesa to use the Gallium llvmpipe software renderer.
Well, it's been a while and I'm happy to see that things are a bit
better with Mesa 17.2. The game sti
Hello everyone,
you may remember that a few months ago I was trying to fix KOTOR to work
with Mesa to use the Gallium llvmpipe software renderer.
Well, it's been a while and I'm happy to see that things are a bit
better with Mesa 17.2. The game still crashes, but we're closer to
fixing it.
I honestly don't know what's causing it to fail :(
I'm trying to figure it out using IDA pro but I'm really not good at
this stuff.
I will try to see what happens if I leave the current context though,
instead of setting it to null.
Il 2017-03-27 13:32, Jose Fonseca ha scritto:
No, I'm af
Hi, thanks for the suggestions ;)
I was using opengl32.dll as a drop-in replacement. I followed your
instructions to properly load mesa as an opengl driver and got pretty
much the same crash, but on top of that, the game can't change the
resolution, only the desktop resolution seems to be avai
Hi,
I took a look at the wgl code and I think the problem is that
MakeCurrent fails if the pixel format of the context and the pbuffer
don't match. The main window is double-buffered, so I guess the context
is also double-buffered, but the pbuffers are single-buffered and they
have no depth o
Yeah, from my investigation into this game/issue a few years ago, my
finding was that when GL_ATI_fragment_shader is supported, the game uses
a substantially different rendering path involving pbuffers. Calls to
wglMakeContextCurrentARB() fail because the context and pbuffer have
different p
First of all, stop using microsoft opengl32.dll, since it doesn't help.
Using Mesa means you can debug using gdb or something.
But on 2nd thought, rather than using a debugger, a good way to go about
this is to add printfs on every code path that causes WGL (or in Windows
cases, _debug_printf
No, I'm afraid you need to fix whatever is causing make current to fail.
Rebind the old context / drawable, or creating a dummy context, might
avoid the division by zero, but I'm sure it will get you no closer to
make it render correctly. Context/drawables are stateful objects, they
are not i
The trace shows are a lot of wgl calls failing:
$ apitrace dump swkotor_s3tc.trace | grep wgl.*FALSE | grep -v
wglChoosePixelFormatARB
499 wglMakeCurrent(hdc = 0x50010fe2, hglrc = 0x2) = FALSE
510 wglMakeCurrent(hdc = 0xc20117ba, hglrc = 0x2) = FALSE
521 wglMakeCurrent(hdc = 0x3e010301,
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, char
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 G
Hi,
sorry I'm late to the party, now I'll try to answer some of the
questions raised in this thread.
On 11/03/17 12:51, Federico Dossena 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
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
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
0001-st-wgl-add-support-for-WGL_ARB_make_current_read.patch
Description: Binary data
> On Mar 15, 2017, at 12:2
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
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
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 wglCreate
The game still crashes at the same null pointer, but I've seen it use
that function you changed so I guess I'll keep the patch just to be safe.
Are there any patches that touch wglMakeContextCurrentARB and didn't
make it to master?
(Resent the email because thunderbird removed the mesa-dev cc
The game runs smoothly if you decompress the textures, I'm getting 30-40
fps with llvmpipe and no "grass in the sky" artifacts.
The problem is frame buffer effects and soft shadows, were they enabled
when you tested it? If so, how did you make it use llvmpipe?
Il 2017-03-13 22:40, Jan Vesely h
Hello again,
After further investigation it seems to me that wglMakeContextCurrentARB
is not implemented by gallium llvmpipe, that's why it gets a null pointer.
Can we add a stub or something?
Il 2017-03-14 03:44, Brian Paul ha scritto:
Looks like my KOTOR patch never made it to master. I'm
On Tue, 2017-03-14 at 05:22 +0100, Federico Dossena wrote:
> The game runs smoothly if you decompress the textures, I'm getting 30-40
> fps with llvmpipe and no "grass in the sky" artifacts.
> The problem is frame buffer effects and soft shadows, were they enabled
> when you tested it? If so, how
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 ;
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
If I put printf("HELLO MESA\n"); into wglGetProcAddress it prints it, so
some code from Mesa is certainly being executed.
The reason why I suspect that I have a windows dll loaded is that when
it calls wglGetProcAddress("wglMakeContextCurrentARB") it seems to be
inside a small DLL, while mesa
On Mon, 2017-03-13 at 11:40 +0200, Grazvydas Ignotas wrote:
> On Sat, Mar 11, 2017 at 1:51 PM, Federico Dossena
> wrote:
> > This issue is not new: a guy named Miklós Máté, here in the Mesa mailing
> > list somehow managed to fix it in Mesa 11, but his patches do not seem to
> > work anymore
> >
On 13/03/17 11:09, Emil Velikov wrote:
On 11 March 2017 at 11:51, Federico Dossena 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
On 11 March 2017 at 11:51, Federico Dossena 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 textur
On Sat, Mar 11, 2017 at 1:51 PM, Federico Dossena wrote:
> This issue is not new: a guy named Miklós Máté, here in the Mesa mailing
> list somehow managed to fix it in Mesa 11, but his patches do not seem to
> work anymore
> (https://lists.freedesktop.org/archives/mesa-dev/2016-February/106695.htm
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 r
38 matches
Mail list logo
