EMI: Dark lines in the intro with TinyGL, clamping not supported

[aquadran]

I think that's not new but I haven't found an issue here.

Reading an old post related to a GSoC, it was pointed to this commit: a539832

With more specifically in our TinyGL case:

FIXME: TinyGL only supports TGL_REPEAT
Remove darkened lines in EMI intro

if (g_grim->getGameType() == GType_MONKEY4 && clamp) {
tglTexParameteri(TGL_TEXTURE_2D, TGL_TEXTURE_WRAP_S, TGL_CLAMP);
tglTexParameteri(TGL_TEXTURE_2D, TGL_TEXTURE_WRAP_T, TGL_CLAMP);
} else {

tglTexParameteri(TGL_TEXTURE_2D, TGL_TEXTURE_WRAP_S, TGL_REPEAT);
tglTexParameteri(TGL_TEXTURE_2D, TGL_TEXTURE_WRAP_T, TGL_REPEAT);

}
But in the current code (0.4.0git), in gfx_tinygl.cpp, there is:

TinyGL doesn't have issues with dark lines in EMI intro so doesn't need TGL_CLAMP_TO_EDGE
tglTexParameteri(TGL_TEXTURE_2D, TGL_TEXTURE_WRAP_S, TGL_REPEAT);
tglTexParameteri(TGL_TEXTURE_2D, TGL_TEXTURE_WRAP_T, TGL_REPEAT);

I believe this is not a clamping issue, but probably an alpha issue: black borders only appear when the texture is being blended. There may also be a coordinate issue, as when the title screen (visible in above screenshot) is being scaled, some borders are black but others brighter than normal, suggesting triangle N+1 is drawing over triangle N for at least one pixel's width.

I just tried implementing texture clamping, but it did not make any change that I could see (I may also have done a mistake somewhere). EDIT: pushed in my fork

It seems I was wrong to think alpha was a factor: if I understand correctly, the intro scene works by fading-out triangles textured with previous screen content over an image containing the whole next panel. So I think this issue is about triangle coordinates rather than texture coordinates.

I suspect it may be related to GfxTinyGL::drawBitmap's:

adding '+ 1' fixing broken lines at edges of bitmaps
example: EMI ship scene
in the sense that once this issue fixed, that hack may not be necessary anymore.

I have a fix. Half of it seems good to me, the other half is more dodgy, and causes a small glitch in GRIM's load screen.

The probably-good half: vertical and diagonal edges of adjacent triangles in the intro while the fading effect is running are drawn twice. To avoid this, I bias the triangle renderer against drawing that last pixel:

diff --git a/graphics/tinygl/ztriangle.cpp b/graphics/tinygl/ztriangle.cpp
index d16e92ad4..877b95ea5 100644
--- a/graphics/tinygl/ztriangle.cpp
+++ b/graphics/tinygl/ztriangle.cpp
@@ -365,7 +365,7 @@ void FrameBuffer::fillTriangle(ZBufferPoint *p0, ZBufferPoint *p1, ZBufferPoint

dx2dy2 = (dx2 << 16) / dy2;

else

dx2dy2 = 0;

• x2 = pr1->x << 16;

+ x2 = (pr1->x << 16) - 1;

}

we draw all the scan line of the part

The important bit here is subtracting after the shift, so it is on the fractional part of resulting fixed-point value.

The more dodgy one: there are horizontal lines too. This seems to be a similar issue, but there is no fixed-point value here, only a line counter. So the best I could do was to truncate triangles by one row in screen space. Models still look fine to me after this (just a few scenes in GRIM and EMI, and a very quick look at MYST3 but I do not remember if it uses this codepath), but GRIM load screen has a non-darkened line at the bottom of its load screen fresco. Anyway, here it is:

--- a/graphics/tinygl/ztriangle.cpp
+++ b/graphics/tinygl/ztriangle.cpp
@@ -303,7 +303,7 @@ void FrameBuffer::fillTriangle(ZBufferPoint *p0, ZBufferPoint *p1, ZBufferPoint

l1 = p1;
l2 = p2;

}

• nb_lines = p2->y - p1->y + 1;

+ nb_lines = p2->y - p1->y;

}

compute the values for the left edge

I did not push them anywhere for now, because they are trivial to recreate, and I'm not even sure what to put in the commit message...

If these look like good ideas, please give idea for the commit message.

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