EMI: Animated sea surface texture looks clamped instead of repeated in set "shi" with TinyGL

[aquadran]

I am investigating the cause of this issue, but so far I understand little of it.

I read this as: we see texture's edge, the texture being centered somewhere below camera position. Lines going towards Guybrush move along with the pixels near the edge. The solid-colored area on top-right changes color periodically, likely extending from texture's corner.

Here the texture looks mostly fine. There are flashes in the shadow (the bottom of one pole is lighter in this screenshot), which I assume are the underlying solid color showing through. There is a likely-unrelated issue on this scene that the see looks darker when I load the save than after the first camera angle change. Texture issue being present both before and after.

And here we see another border and corner area, plus flickering glitches (the darker rectangular patch in the distance).

To me, this looks as if this texture was configured for GL_CLAMP_TO_EDGE, but TinyGL only supports GL_REPEAT (and by applying a factor to s & t coordinates on vertices, I could confirm textures do get repeated).

I have found a handy illustration of GL wrapping modes.

I think I understand a tiny bit more: this is "uniwaterhilite.cosb" costume with mostly transparent textures "hilites???.tga" (declared in "hilites.sur") and a mesh, "uniwaterhilite.meshb".

I should have mentionned opengl and opengl_shaders do not have the main described issue, so it seems unlikely to be a data or parsing issue, but really something specific to tinygl.

And for completeness about opengl modes, they do have the dark-water-on-load (including the "set_renderer" implicit save/load) which become lighter when camera angle changes, and opengl_shaders has the row boat partly in the water. But these are other bugs.

The mesh has texture coordinates going from 0 to 8, hence forcing the texture to repeat itself.
I changed it to 64 and hacked the software renderer to show texture coordinates as colors. We would expect the square pattern in the bottom left to repeat for the entire quad, but this is not the case.

Slowly rotating the shi.water3 actor causes the lines at the top to jump around erratically. I ran out of time yesterday, but my next step would be to reposition the camera above, looking down.
If viewing the entire quad at once works properly, the issue might be due to clipping...

I lack the skill to play with scenes like that, but I like a lot the idea of coloring according to u and v. I also suspect clipping may be the issue, and am working my way back from ztriangle.cpp, simplifying code by dropping optimisation to get a better understanding of what happens where.

Something surprising I noticed when viewing the scene with all its components but the uv hack is that the wideness of these "rays" to horizon changes, meaning xyz coordinates are involved in uv errors.

Tested this morning with glOrtho camera setup and a quad perpendicular to the camera angle: no issues.
Next up: perspective-correct rendering with glFrustum and/or giving the quad a slight tilt.

Having done a bit of reading this week-end on texture mapping, I wonder now if this would be "just" the effect of perspective-incorrect texture mapping. I'm still having trouble wrapping my head around the code, but it looks like it does (try to ?) adjust texture mapping for perspective correctness: runs of 8 pixels with linear(?) interpolation, and z adapted between each.

​https://github.com/residualvm/residualvm/issues/1336