Myst III: 3D box borders visible

[Raziel]

Does anyone else get this behaviour in Myst III, or is it just me?
Right in the first scene of Myst II, just move the mouse around the scenery, there are some borders of a 3D "box" visible, or better, the border aren't correctly seaming together.

[ezekiel000]

I don't get the visible borders like that.

Running on Debian 9 amd64:
ResidualVM 0.4.0git (Feb 13 2019 10:02:36)
Features compiled in: Vorbis MP3 ALSA RGB zLib MPEG2 Theora FreeType2 JPEG PNG

[Raziel]

I'm parroting what i read on another forum:

That looks like a texture clamping issue.

and if it only happens on my platform it must be the OpenGL implementation has another bug (or unsupported feature)

Thanks for checking

[Raziel]

@devs

Since ruling out something fishy in my gfx/3D driver i'm trying to figure out what causes this for me.

So here's a question for you 3D devs (btw, ARB shaders are not available on my platform):

It obviously contains code somewhere for upscaling non-power-of-two-textures, because it uses a texture-size upscaled to the next power of two if NPOT textures are not supported. Are the sky-cube textures NPOT?

If the textures are not power-of-two then the game will apparently scale them to the next higher power-of-two. And that code may be buggy.

I'm talking about this piece of code in engines/myst3/gfx_opengl_texture.cpp

Code: Select all

OpenGLTexture::OpenGLTexture(const Graphics::Surface *surface) {
	width = surface->w;
	height = surface->h;
	format = surface->format;

	// Pad the textures if non power of two support is unavailable
	if (OpenGLContext.NPOTSupported) {
		internalHeight = height;
		internalWidth = width;
	} else {
		internalHeight = upperPowerOfTwo(height);
		internalWidth = upperPowerOfTwo(width);
	}

	if (format.bytesPerPixel == 4) {
		assert(surface->format == getRGBAPixelFormat());

		internalFormat = GL_RGBA;
		sourceFormat = GL_UNSIGNED_BYTE;
	} else if (format.bytesPerPixel == 2) {
		internalFormat = GL_RGB;
		sourceFormat = GL_UNSIGNED_SHORT_5_6_5;
	} else
		error("Unknown pixel format");

	glGenTextures(1, &id);
	glBindTexture(GL_TEXTURE_2D, id);
	glTexImage2D(GL_TEXTURE_2D, 0, internalFormat, internalWidth, internalHeight, 0, internalFormat, sourceFormat, 0);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

	// TODO: If non power of two textures are unavailable this clamping
	// has no effect on the padded sides (resulting in white lines on the edges)
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
	
	update(surface);

}

[Raziel]

Okay, as far as I can see the following happens:

1. if there's an NPOT texture incoming, then the game creates an empty texture with the next power of two edge size. So e.g. a 200x100 texture would become 256x128. So far so good.
2. but the game doesn't scale the texture data accordingly but simply puts the tex-data unscaled at position 0,0.
3. and because the texture was created as an empty texturem, a huge part of it is actually undefined!

Now take all that and add a slightly false texture-coordinate generation, voila: you have a randomly colored (fully black or white are eventually most likely depending on driver) line like the one you see.
And yes, the wrap-mode doesn't really have the expected impact here, because we are in mid of the texture data, not at the edges (although a GL_REPEAT most likely makes things even worse here).