Possible glTexCoordPointer issue

[anthnich]

Hi.

In reference to this commit: https://github.com/SFML/SFML/commit/973ac8ddcd5eea22a01556405e16c554c7dd9788

With commit: https://i.imgur.com/a1llfMb.jpg (notice incorrect coords with camera and pc console)

Without commit: https://i.imgur.com/4bJX1EY.jpg

When I comment out the code (as seen in pic #2), everything is fine.

The actors that affected are sf::Sprites.  Anyone else encounter this issue?

[binary1248]

What OS? Hardware? Driver version?
Does this happen consistently, i.e. across restarts of the game?
Does it happen with exactly the same sprite(s) every time?
What happens if sprites are added or removed from the set of objects that you draw on the screen?
Are you making any raw calls to OpenGL somewhere in your code?
Are you making use of multi-threading?
If you have access to them, have you run sanitizers over your code?

[anthnich]

* Win 10. GTX 1080. 385.69.
* Yes. Restarts of game + restarts of PC. Happened in my Win, Linux, and Mac builds.
* No, it affects a a number of sprites in the game, but these particular sprites I can get happening repeatably. I haven't run into this issue until recently. I was testing some changes when I saw it happening. I keep backup of all of my built library revisions, so I kept stepping back until I came upon this commit. Commented out code and everything is fine.
* Keeps happening on and off with other ones.
* No.
* No.
* I haven't, but I'll look into it if you want.

[binary1248]

Actually, upon closer inspection of the sf::RenderTarget::draw() function, I can think of a possible edge case that would lead to stale texture coordinates from previous draws being re-used instead of fresh data. This effect is highly dependent on what is being drawn and in what order, which is probably the reason not many have noticed it yet. I'll try to reproduce the issue using a minimal example when I have time tomorrow.

[FRex]

I believe this is an example: https://gist.github.com/FRex/b04a5de124d2ce82a2a859bc345ae1a1

Basically what you gotta do is:
One) draw something that doesn't use cache but uses texturing.
Two) draw something that uses cache but doesn't use texturing.
Tri) draw something that uses both texturing and cache.

Using the cache just means drawing 4 or less vertices.

The first time a call is using the cache it will set all the pointers to cache, but if it's not using textures it'll not set the cache.
Next calls that use the cache will not set any pointers and thus reuse the stale pointer from before first cache call.

And if you only use cached drawings and never do a call that uses texturing (i.e. comment out 'one' in my example) then you don't ever set the texturing pointer but have texturing enabled.

If you comment out 'two' and leave 'one' and 'tri' in then it works.

You can try adding a call like 'one' before drawing a spirte or something else that's 4 or less vertices as a quick fix in game code if you want.

By the way, what is that game and when is it coming out, is it a stealth game?

[anthnich]

I use sf::VertexArrays and append 4 sf::Vertexs to create quads to populate it. I also use sf::Sprites. They all have textures applied. I apply the texture to the sprite prior to drawing, and I draw the VertexArrays by passing them to the draw function of a RenderTexture, along with the texture.

The game is called Turnover. I released it at the end of 2015. Just doing my best to keep it updated and as bug free as possible.

[binary1248]

Should be fixed with #1297.

[anthnich]

Yup, that fixed it! Very nice job. Thank you.

[FRex]

Can you add std::printf("CLEAR------------------\n"); to clear and std::printf("RenderTarget::draw %p %u %p %p\n", vertices, (unsigned)vertexCount, states.texture, states.shader); to draw?
You said you always use texturing so it shouldn't be this bug but you also said the fix worked so I'd like to see the output of that and see what exactly did that.

[anthnich]

I did a little more snooping, and the level in which I could replicate this bug does have a VertexArray that is not given a texture, so I was incorrect in my original statement. Sorry about that!

[FRex]

Alright then, it was this edge case then.

[eXpl0it3r]

Merged in 516678fe