<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - NV46 (G72) Full screen artifacts in Freespace 2 SW OT mod" href="https://bugs.freedesktop.org/show_bug.cgi?id=95095#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - NV46 (G72) Full screen artifacts in Freespace 2 SW OT mod" href="https://bugs.freedesktop.org/show_bug.cgi?id=95095">bug 95095</a> from <a class="email" href="mailto:issor.oruam@gmail.com" title="Mauro Rossi <issor.oruam@gmail.com>"> Mauro Rossi</a> <pre> The attachment was related to a freeze-lockup, even if it's most probably a different problem. > If you are involved with the development of this application, could you > verify that it never uses a 32-bit color buffer with a 16-bit depth buffer, > or a 16-bit color buffer with a 24-bit depth buffer? (That's RGBA8 + Z16 or > RGB565 + Z24.) Those combinations, while perfectly legal in GL, are not > actually supported by the hardware, and the driver "works around it" by just > disabling depth, which results in broken rendering (but at least no > hangs...). I'm not involved in fs2_open project, I'm contributing to Star Wars mod testing on Linux, but I found something interesting, using the NV30_SWTNL=1 parameter, I could cycle all models and get trace to qapitrate retrace all the sequence with hwtnl and ... ... just some specific 3D models produce z-culling artifacts, where parts of the 3D model, like the X-Wind hull, are put extremely "in the front" hiding everything, while other 3D models are perfectly rendered. I'm going to check with 3D model owners if there is a way to correct the impacted 3D models. Thanks a lot Ilia! I'll report back when I found the exact cause of the problem. > Lastly, please ensure you're using a semi-recent mesa... I'm testing with mesa git (oibaf ppa)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>