Floor Rainbow

[Phytotron]

Here's something interesting that happened. How'd I do it?

[pie goes moo]

Does it have to do with the moviepack? The floor.png?

[Word]

yes, and he probably changed the setting for its size (i know that effect from some of my mps)

[ender]

Thats rad!

[Z-Man]

The mipmaps for the floor get calculated wrongly. Not our fault, we delegate that to GLU

[Jonathan]

I think I got something like that with grayscale textures once. But not always. Don't remember much more.

[Phytotron]

No, nothing to do with floor.png or the GRID_SIZE[_MOVIEPACK], and occurs with both moviepack and regular textures. It's apparently caused solely by the floor_a/b.png's that are involved, with "dual texture plane" and alpha blending enabled. I guess it's something to do with what Z-Man and Jonathan are describing.

What I don't get is this: With the default floor_a/b.png's, changing [MOVIEPACK_]FLOOR_RGB only affects the gridlines—the space in between remains black. On the other hand, with the floor_a/b.png's I've used, changing floor color affects the entire floor. That's with "dual texture plane" and alpha blending enabled, as mentioned.

Here are a few more shots, plus the floor_a/b textures involved.

[Phytotron]

And here's what happens with the floor_a/b that I've included here. If you take a look at the floor lines, you'll see they didn't quite work out the way I had anticipated. The only difference between these two sets of pics is with the MOVIEPACK_FLOOR_RGB—all 0.5 in the darker ones, and 1 in the lighter.

[Phytotron]

And with reflections, just for the heck of it. Upload limit up there.

[Jonathan]

What I don't get is this: With the default floor_a/b.png's, changing [MOVIEPACK_]FLOOR_RGB only affects the gridlines—the space in between remains black. On the other hand, with the floor_a/b.png's I've used, changing floor color affects the entire floor. That's with "dual texture plane" and alpha blending enabled, as mentioned.

The coloring of the floor works by component-wise multiplication in normalized RGB. So if part of the floor is white, the floor color will show through unmodified. If the texture is gray like your textures, it'll be darkened. If the texture is black like most of the default textures, you'd better like black because nothing will change it (perhaps a division by zero, if that gets your hopes up). If the texture is red, you're filtering the red channel of the floor color, and you'll just get brighter or darker red (down to black) depending only on the red part of the floor color. Walls are exactly the same, except the input color can be modified a bit if the game thinks it might work as camouflage. Cycle textures work a bit differently; they're blended over the (again possibly tweaked) cycle color using the alpha channel.

Okay, back to business before I get to real color management.

Summary of PNG types:
floor lines/floor_a.png: 8-bit RGB
floor lines/floor_b.png: 8-bit RGB
otherlines/floor_a.png: 8-bit RGBA
otherlines/floor_b.png: 8-bit RGB

Seeing this, the grayscale problem might actually be the reverse.

/me is too lazy to go testing.

[Jonathan]

There, happened again. This time I think I figured it out, and it turns out mipmaps are more of a victim than a cause. Try getting your glPixelStorei(GL_UNPACK_ALIGNMENT, ...) right, as well as your GL_PACK_ALIGNMENT. Testing in my own code confirmed that's how it works, both for glTexImage2D and gluBuild2DMipmaps. Only the dual floor was affected because floor_a is the only texture < 4 wide, rendering it vulnerable if each pixel is smaller than 4 bytes.

[Phytotron]

Right on. It would mean more to me if I knew what any of that...meant. But, is the upshot that you've found that this is something that could be avoided in some manner, be it through code correction or something the user can do?

[Jonathan]

If I'm reading the code correctly, as texture maker you should make an RGBA or gray-alpha texture, and enable truecolor textures, to work around the problem. In more detail:
RGB/grayscale with truecolor textures enabled: width should be a multiple of 4
RGBA/gray-alpha with truecolor textures enabled: width should be a multiple of 1 (anything is fine)
Anything with truecolor textures disabled: width should be a multiple of 2

Edit: Scratch that. I was reading the wrong part and ignored how it didn't make sense. This looks more correct and is what I suspected before investigating Arma's side:
Grayscale: 4
Gray-alpha: 2
RGB: 4
RGBA: 1

Some spec hunting to confirm GLU uses GL's unpack mode:

gluScaleImage will scale an image using the appropriate pixel store modes to unpack data from the input image and pack the result into the output image.

That's clear. Only it's the wrong function.

target, internalFormat, format, type, width, height, depth, and data define the level 0 texture, and have the same meaning as the corresponding arguments to glTexImage1D, glTexImage2D, and glTexImage3D.

A bit vague. "The same meaning" should imply the unpack mode is used. Which makes sense; just wanted to confirm.

Hmmm, I wonder about SDL_Surface now. Edit: Alignment bytes are apparently supported, but the docs don't tell if IMG_Load does any alignment. Another edit: SDL surfaces are, guess what, aligned to 4 bytes, the same as OpenGL's default. This is becoming confusing.

[Jonathan]

Some more testing. I've linked it to SDL_Image 1.2.3 which shipped with 0.2.8.2.1. Plopping in the current SDL_Image 1.2.10 fixes it. Oh well.

Still, the screenshots. make_screenshot (the flipping part, which is redundantly executed when saving PNG, by the way) and SDL_SavePNG (an Arma function which, because it flips, doesn't only not deserve that name because it isn't SDL) don't use the pitch (bytes per row) of the surface. At least in 0.2.8.2.1; there's a chance this was also fixed in the meantime. I should learn to check current versions.

[Phytotron]

So, you're saying that, at least in the case of my rainbows above, it's because the floor_a/b textures are in plain RGB (no alpha channel), but only 1 pixel [wide or high, respectively] when it should have been 4 pixels?