[V4.1.x] Fix GL_INVALID_ENUM error in CopyTexture

[kblaschke]

Bumped libprojectM to v4.1.2 as well. Will create a bugfix release as this issue can break integrations checking for GL errors, e.g. GStreamer.

[hack-s]

I was considering checking the texture id instead of the target. I ended up checking the target, because that was the value that directly triggered the GL_INVALID_ENUM. Would it be worth it to check both values ?

[hack-s]

Disregard, just noticed, this is the backport. We should not do anything different here anyways.

[kblaschke]

m_target is, except for the volume noise textures, always set to GL_TEXTURE_2D, even if the texture is empty. I think "target" is a misleading name for the texture's dimensionality, but it's how OpenGL calls it.

What triggered the error was actually m_textureId being zero because the actual texture wasn't initialized at the point when it was first used (copying the previous frame texture into the new preset - naturally, there's no previous texture right after init).

[hack-s]

Works great!

[revmischa]

I don't have anything to add here, don't have much of an idea of what's going on. Adding some comments on the changed lines about why we need these checks or why New instead of Empty is preferable would be grand

[kblaschke]

why New instead of Empty is preferable

I took this consideration because the previous name would be misleading now.

"Empty", in the new naming context, means there is no actual texture allocated at all, e.g. the texture object is 0 or "empty", like a nullptr. The CreateNewTexture() function creates a (blank) texture with a valid, non-zero GL texture ID, but the actual object is no longer considered empty, as a black texture is a texture, despite not a hugely useful one.

Hope this clears it up a bit. The Doxygen comments in the header file also reflect this.