{"id":141,"date":"2014-06-18T18:38:55","date_gmt":"2014-06-18T18:38:55","guid":{"rendered":"https:\/\/blogs.scummvm.org\/josejx\/?p=141"},"modified":"2022-05-21T18:40:58","modified_gmt":"2022-05-21T18:40:58","slug":"revisiting-the-lava-texturing-problem","status":"publish","type":"post","link":"https:\/\/blogs.scummvm.org\/josejx\/2014\/06\/18\/revisiting-the-lava-texturing-problem\/","title":{"rendered":"Revisiting the Lava Texturing Problem"},"content":{"rendered":"

In a previous post<\/a>, I commented on a texturing problem with the lava in the scene lav<\/i>. As I indicated in that post, while the work around that I submitted did fix the problem for the scenes with issues, the workaround itself was sort of a hack. I had assumed that if a texture was larger than 128 pixels on a side, then that texture should be clamped at the edges. Clamping prevents the OpenGL renderer from repeating the texture over the surface, resulting in lines when the textures don’t repeat cleanly. So why not just always use clamping? Well, in many cases we DO<\/b> want the texture to repeat. Think of a typical grass pattern or a sandy beach texture, or in this case, the lava!<\/p>\n

Although my approach did fix the problem, the solution was a hack. There’s nothing that really indicates that that is a cutoff for which approach to take. To investigate possible solutions, I used apitrace<\/a><\/i>, a tool that records OpenGL state information, allowing you to replay, investigate and examine what OpenGL calls a program is executing to render the screen.<\/p>\n

To capture a trace, we’ll use this command with the retail version:<\/p>\n