[Mesa-dev] MESA and KOTOR

[Federico Dossena]

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, and that function has changed quite a bit since his patch. I 
don't really understand what it does since I don't know mesa very well, 
do you know how I could do the same thing in the new st_convert_sampler 
function?

Thanks


Il 2017-09-26 12:56, Nicolai Hähnle ha scritto:
> 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 still crashes, but we're closer to 
>> fixing it.
>>
>> Here's what I found using 17.2.1:
>> With frame buffer effects and soft shadows the game crashes at the 
>> end of loading; the crash is inside a function that amongst other 
>> things, generates mipmaps for a texture used in a pbuffer (function 
>> at offset 2FB37D in my exe).
>> The crash happens when gluBuild2DMipmaps is called, however doesn't 
>> seem to be a null pointer like it was back in march: it's an access 
>> violation alright but no longer a null pointer. So I think it's a 
>> different, hopefully simpler, problem.
>
> So is it a crash in KOTOR, in glu, or in Mesa? If it's in one of the 
> last two, then you should be able to compile both glu and Mesa from 
> source with debugging info to help you narrow things down. A backtrace 
> would be a good start.
>
> If it's in KOTOR itself, then I'm afraid we're probably not going to 
> be a lot of help here...
>
> Cheers,
> Nicolai
>
>>
>> Back in march, Miklòs Màté suggested that changing the checks for the 
>> pixel format could fix the problem, and he was right; without those 
>> checks we definitely got a step closer to fixing it.
>>
>> My first thought was to just NOP the entire section that generates 
>> mipmaps and a bit of code later that uses it. The game no longer 
>> crashes, however it displays nothing, but I can hear it running in 
>> background. So this is the last issue! We're almost there!
>>
>> Now, I'm bothering you again because I think that at this point it's 
>> just a problem with the texture format used there. The call to 
>> gluBuild2DMipmaps uses LuminanceAlpha' as texture format as well as 
>> internal format (0x190a). I tried changing it to RGB and RGBA just to 
>> try something, but that didn't work because I guess the texture was 
>> already generated with another format.
>>
>> What could I do to investigate this further? And where should I look 
>> inside Mesa if I wanted to say... force a specific texture format for 
>> pbuffers?
>>
>> I feel that we're very close to fixing this. Your help would mean the 
>> world to me and the whole KOTOR community.
>>
>> Thank you ;)
>>
>> P.S.
>> This has nothing to do with mesa, but you should know that KOTOR is 
>> slowly dieing. It is currently unplayable on Intel and AMD graphics, 
>> and recent nVidia driver updates have introduced a glitch with 
>> transparencies (it can be fixed, but still, no one can play KOTOR on 
>> modern hardware properly and we have to keep old computers as 
>> dedicated "shrines" for KOTOR, that's why I insist so much on Mesa)
>>
>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>