Text rendering broken on my machine when using sf::Shape

[Laurent]

Which seems a bit odd, that the texture thinks it has to set the matrix mode to GL_MODELVIEW, but the RenderTarget itself sets it to GL_TEXTURE in the end.

pushGLStates ends with a call to resetGLStates(), which activates the MODELVIEW matrix.

I noticed that most of the problems on this board are "noob-questions" (yes, sorry, but it's true) where people have similar problems because of stupidity

I was really refering to driver bugs. Beginners questions are a totally different problem
A recent one:
http://en.sfml-dev.org/forums/index.php?topic=9561.msg65858#msg65858

Notice this:

Driver updates have been pretty frequent lately, though.  I wouldn't be surprised if it was something that got borked up recently.

[Laurent]

You guys should really try to use normalized texture coordinates and get rid of the texture matrix. I already had problems with that on ATI cards (that's why Vertex::texCoords is a Vector2f instead of a Vector2i), and this is the most doubtful thing involved in text rendering. If you have no idea what to modify in SFML, I'll probably have more time later this evening to explain what needs to be changed.

[opatut]

Dude, why didn't you link to that earlier? (and why is the search function in this forum so fucked up, of course I searched stuff like "shape text breaking" before posting, but found nothing).

Apparently happens when you do glDrawArrays(GL_TRIANGLE_STRIP) - the next glTexCoordPointer() won't actually happen until after the next glDrawArrays() or something stupid like that, causing texture coordinates to be wrong in that call, which could be a Text, or a Sprite, or something custom... Most annoying. That's 8 hours I could've spent doing something more important for Fuck This Jam!

[Laurent]

Sorry. There were so many similar problems recently, that I'm totally unable to make the connection between bugs and what clues were previously found. I'm really really lost with all these "driver" bug reports and all the stuff that people already found. And since this one is the latest, with many users involved, I thought you already knew/found it.

So... is this the same thing?

[opatut]

I guess so, the symptoms are similar and match my observations, and I found also there was a problem with glTexCoordPointer(), and it is also catalyst 12.9 related.

I am currently trying to change SFML to only normalized texture coordinates, though this may take a while, we may benefit from it. Since normalized coords are usually preferred over texture matrices (they are easier to understand, matrices are brain-fuck for most people), this may be where SFML is going in a different direction. So yes, this might fix it.

Also, the normalization seems like a good idea, since we observe the texture coordinates to me changed from (0,0)/(w,h) to (0,0)/(1,1) and as such only displaying the top left pixel. This is definitely worth trying, IMO.

I will fork SFML on github so you can see my progress, as soon as I have something compiling and working using normalized coords.

[Laurent]

Don't misunderstand me, using non-normalized coordinates is a design choice and I don't want to switch to normalized coordinates in sfml-graphics. Graphical entities deal with pixels (setTextureRect, etc.), so does sf::Vertex.

If you find that non-normalized coordinates are the cause of the problem, that will be a dead end

[opatut]

That is being undiscerning again. Why should SFML not normalize texture coordinates internally while keeping the old API. Really, OpenGL is not designed to be used with non-normalized texture coordinates, or at least mordern graphics programming strongly discourages it. You still get pixel-perfect results, so why not switch to the correct way? The texture matrix stack is long outdated anyway. I wouldn't expect modern drivers in the next 10+ years to still support these legacy ways of OpenGL 1...

Edit: I switched Sprites to normalized coordinates completely, and it changes.... nothing. So keep your texture matrix, I'll wait for a catalyst fix and stop using SFML then.

[Laurent]

Nobody ever complained about setTextureRect taking pixel rectangles instead of normalized ones. What's different with texture coordinates? It's "closer" to OpenGL? (not really)

When I design a class/function I think from the user point of view, not from the underlying technical details. And defining texture mapping with pixel coordinates is what seems more intuitive for someone who doesn't know the low-level 3D APIs -- in my opinion.

The fixed pipeline is already deprecated, not only texture matrices. In the near future everything will have to be done in shaders, and there will be no problem to keep pixel texture coordinates.

But this is a bit off-topic, feel free to open a new thread if you want to discuss it further.

[opatut]

defining texture mapping with pixel coordinates is what seems more intuitive for someone who doesn't know the low-level 3D APIs -- in my opinion.

I agree on the API side, and think you made a great number of design decisions.

The fixed pipeline is already deprecated, not only texture matrices. In the near future everything will have to be done in shaders, and there will be no problem to keep pixel texture coordinates.

Then what keeps you from designing a custom pipeline now? Are you planning on that for the foreseeable future? How much work would it be, and how backwards-compatible would it be?

---

By the way, catalyst 12.11 beta does fix the problem, sadly, I get a stupid "AMD Unsupported Hardware" watermark displayed when using that driver

[Laurent]

Then what keeps you from designing a custom pipeline now? Are you planning on that for the foreseeable future? How much work would it be, and how backwards-compatible would it be?

I'll have to switch to a shader-only pipeline very soon, in order to be compatible with OpenGL ES 2, which is required for mobile devices. Hopefully it can be totally hidden and have no impact on the public API, but I'm not 100% sure yet.

[Laurent]

By the way, catalyst 12.11 beta does fix the problem, sadly, I get a stupid "AMD Unsupported Hardware" watermark displayed when using that driver

"AMD Unsupported Hardware"?
Let's hope that the final version will be ok.

At least the problem is clearly identified now.

[Qix]

I thought I tried updating to 12.11 with no good results. I'll try again on this computer. Current version is 12.6. I'll let you know.

EDIT: Well the small scale works on this now after updating, but the main app doesn't. However, it's kind of mangled from all of the testing. I'm going to do a hard reset back to a commit where it should have worked and test from there.

EDIT2: Still recooping from the reset; since SFML was in a submodule the project configurations were a little different. Before the reset I modified the sample code a bit to do the drawing in a separate thread, much like how the main app does it. Still worked fine, so hopefully going back to a presumed working copy will help.

EDIT3: Alright, back to images working and text not working :/

EDIT4: Just tried on integrated intel card. The version I have is working. Anything I should try? I don't know how the internals of opengl work all that well, so I'm kind of on standby for any suggestions.

EDIT5: I'm going to try from the other way; I'm going to try to recreate the problem with the samples instead of stripping the main program down.

EDIT6: Alright, interesting results. Couldn't re-create the bug going backwards. However, the code that triggers the hierarchy of drawing in the main program was commented out and I replaced it with just a simple draw of a text object. It worked. I'll keep going down the structure until it stops drawing to see where it's fouling up.

EDIT7: I found where the borking is happening. I know it's probably meaningless to anyone, but the following code works:

debug(); // Sets up a test label/font
getBehavior()->onInit(); // Behaviors set up the interface components
 

and the following does not:

getBehavior()->onInit(); // Behaviors set up the interface components
debug(); // Sets up a test label/font
 

I'll do a bit more testing with the code inside of onInit to see what the issue is.

EDIT8: Very strange. onInit() isn't breaking the debug text (which is completely unrelated); the debug text requires the call to onInit(). I'll start commenting out stuff in onInit() to see what breaks it.

[Qix]

Found the bug. Even have a proposed workaround.

This is the wiki page with the entire bugfind log. Reading some of the other pages linked in this thread, it gave me the idea to test a few things.

Tl;dr scroll to very bottom (summary section). I don't know if this is the same bug as others are having, but it may help.

I will try the workaround and get back to you.

EDIT: This bug, whether it be an SFML bug or a driver bug, is indeed mystical. The workaround seems to be:

Load the desired font
Load a dummy font
Create the text object
Apply desired font
Apply dummy font
Apply desired font again
Unload dummy font and desired font (if I'm understanding how the font/text creation system in SFML works, this will leave just the text object. I realize no sizing operations can be carried out after that at the risk of access violations).

This has to be done for each font (yes, load/unload even the same font for each text object) or else glyphs are missing.

If this works, and no other character sizing is done, then the only downside to this would be slower load up times and a ton of file reads. Memory-wise it shouldn't be too intensive.

I'll try this workaround and see if it works.

[Laurent]

I'm glad to see that it was indeed a mystical driver (at least for opatut) bug

Thanks for the detailed report, I'll read the wiki and linked pages later today.

[opatut]

I'm glad to see that it was indeed a mystical driver (at least for opatut) bug

Still, it was a driver bug that only occurs with SFML I'll keep  my eyes open to why that is the case, but I'll rest on it for now.