-
This is what I have reduced my problem down to (example code) (http://pastie.org/private/hf2ajbez5orvwlhxkfq4a). [Sorry, uses Linux font path, edit to provide your own font for testing.]
I am trying to render text as always using SFML 2.0-rc1 with an sf::Text in an sf::RenderWindow with a specified sf::Font (see the code). On my machine, I get two different results:
First frame, good (http://i.imgur.com/fap0f.png)
(http://i.imgur.com/fap0f.png)
Following frames, bad (http://i.imgur.com/Yhu80.png)
(http://i.imgur.com/Yhu80.png)
All the other machines I tested work fine, they all show the stuff from my first frame in all frames. I am running ArchLinux with an ATI graphics card and catalyst drivers and/or mesa, I tested on several machines with Intel/NVidia chips. I sadly do not have another ATI card to test with.
The problem does not occur when I do not draw the shapes, or when I draw the text first and the shapes afterwards. It does not matter whether they are rectangles, circles, have alpha values or not. Also, only drawing one shape and the text works, more than one (i.e. two and up) break the text.
I have no idea where this may come from or how to solve it. Probably it is a driver problem (ATI on linux, yay) or some OpenGL states that are not reset correctly. I would appreciate any help :)
-
Probably it is a driver problem
Most likely. There were a lot of similar issues with ATI drivers recently (you can search on this forum, there are at least 3 or 4 topics).
-
No luck with LIBGL_ALWAYS_SOFTWARE=1 either - which should mean it is not a catalyst problem, but either an error in the fglrx opengl implementation or SFML. Can you imagine what the problem might be? Seems like the glyph sizes are corrent (so the font is being used as normal), only the glyph rendering fails... is SFML using the old fixed pipeline or custom shaders for rendering text?
-
Can you try the latest sources?
-
Yes, error still occurs with the current git master :(
-
So it's most likely a driver issue.
-
How comes all other libraries render text just fine? While I agree with you on that it is a driver-specific issue, the driver can definitely be used to render text as usual. It must be a problem with the combination of fglrx + SFML, which will probably not be concerned about int fglrx, making SFML the point where it should be addressed.
I would really appreciate this to be fixed real soon, as it probably does not only occur on my machine, and it can definitely be done correctly. Unfortunately I do not understand the problem, so I cannot help fixing it, only provide a testing machine.
Another interesting fact: I have no problem when drawing a sprite instead of a shape, even though one would expect a sprite to work exactly like a shape, only with texture handling on top... I'll keep investigating.
And one more thing: when I create the sf::Text only once before the loop, it is rendered correctly in all frames. Seems like there is a problem when rendering the text to a buffer texture (SFML is doing this, right), not when rendering it out onto the target.
Even more interesting: when rendering the font's texture directly into a Sprite (see code below), I have a nice glyph page in the first frame, and a white square in the following. This happens even when I only create and modify both the font and the sprite before the main loop, so it means the font's texture is being corrupted somehow by something that should not even touch it. And it does not seem to be the sf::Text class, since I can completely uncomment that one, giving me an empty glyph page (only a small white dot in the upper left corner) in the first frame, and again the big white square in the following ones. Uncommenting the draw command of the rectangle(s) however leaves the font texture untouched. Now that is weird, since shapes really don't have anything to do with fonts. My guess: does the shape class "construct" a white texture to use the same rendering mechanisms as the sprite class, but overwrites the font glyph page texture in this case?
sf::Sprite sprite(font.getTexture(20));
And more edits: when I use the font texture twice (e.g. render 2 sf::Texts or render one sf::Text and the sf::Sprite with the font's texture) the second (and third and probably all following) render works fine and displays the correct texture. Only the first render after 2 shapes is broken (so yes, I can break the above chain by drawing two shapes in between), these 2 shapes can be separated by other drawing calls to keep it working (either of sf::Text or sf::Sprite with other texture). Rendering another object (e.g. a test sprite) between the shapes and the text fixes the text, the other object however is not being rendered at all. [Hope you understand all of this ;)]
Shape 1, Shape 2, Text // broken text
Shape 1, Shape 2, Sprite, Shape 3, Text // renders Shape 1-3 and Text, but not Sprite
Shape 1, Sprite, Shape 2, Text // renders everything
Wow, this is confusing. But from my observations above I guess one can see how complicated this problem is, and that is probably has something to do with how textures are handled in SFML.
-
Wow, this is confusing. But from my observations above I guess one can see how complicated this problem is, and that is probably has something to do with how textures are handled in SFML.
To be honest, I don't think so. Because:
1. there have been really a lot of similar problems recently caused by those crappy ATI drivers (have you tried to install a different version by the way?)
2. SFML text rendering works fine for everyone else
If I was you I wouldn't bother trying to understand what happens, because there's nothing to understand. ATI drivers are crappy and cause all kinds of weird bugs. Have a closer look at this forum if you don't trust me.
-
I completely trust you, but... there must be a way to avoid this, even if it means some minor hacks. And since I am really not the only one with an ATI graphics card, I guess it is somehow of interest for a (possibly small but existent) group of people who share this common problem. I don't expect you, Laurent, to fix this right now or in foreseeable future, but I think it should be worked upon in general.
I am not trying to convince you that this is the most important problem in SFML 2 right now, nor do I think switching the driver is a satisfying solution.
Wow, this is confusing. But from my observations above I guess one can see how complicated this problem is, and that is probably has something to do with how textures are handled in SFML.
To be honest, I don't think so.
I am not saying it is your (or SFML's) fault, only it has to do with texture handling in SFML. I've been using SFML for a very long time now, and I admire basically all about SFML. I really believe myself ATI drivers are causing the problem in the first place, but there is not much I or you can do about it. But seeing a lot of other libraries and opengl software working fine, there is definitely another way to do it, which works with the current OpenGL implementation of the ATI drivers.
This is basically my reason for discussing here: I can't go any deeper than SFML at this problem. I could resolve the problem using my above investigations, but only for myself, and the solution would not be satisfying at all. What I do instead is posting here, initiating a discussing with the developers of SFML (you) and users of it, hoping to find a one-fits-all solution for this problem. I could not go onto ATI driver level with this problem, I honestly don't know shit about it and wouldn't even know where to start asking questions or who to address. So I went as deep as I could, at a level where I think the problem could be solved.
I am still happy about suggestions what might probably go wrong here - and hopefully how to fix this.
-
And more observations:
When the font glyph page initializes its texture, it sets the top left 2x2 pixels to white (for the underline style), see src/SFML/Graphics/Font.cpp:581. When I set the top left color to something else (i.e. setPixel(0, 0, Color::Red); ) , the "wrong" square and all the wrong glyph rectangles have this color (red in this case)... Are probably the texture coords broken?
-
Try copy/paste text.hpp and cpp and change namespace to avoid nameclash and put lots of break points in updateGeometry to see if glyps bounds have nonsensical values.
-
I am working directly in SFML code, but anyway.... seems like the texture coordinates are fine, for the first quad I get (0,2) (14x17) on both the broken and the correct glyph...
I also found a workaround by enabling the vertex cache for all cases, even when we have more than 4 vertices. Did this by replacing RenderTarget.cpp:165 with
// bool useVertexCache = (vertexCount <= StatesCache::VertexCacheSize);
bool useVertexCache = true;
I still don't know what is going wrong, but like this it works. I will see into more detail what the vertex cache is doing tomorrow.
-
I also found a workaround by enabling the vertex cache for all cases
Hum... are you really sure?
I was expecting a problem with texture coordinates, and the vertex caches changes nothing to texture coordinates; and more important: storing more than 4 vertices in it is undefined behaviour because it is declared as an array of 4 sf::Vertex...
-
Hum... are you really sure?
Yes, pretty sure. I reset my clone to master and changed only the one line, and it worked.
I was expecting a problem with texture coordinates, and the vertex caches changes nothing to texture coordinates; and more important: storing more than 4 vertices in it is undefined behaviour because it is declared as an array of 4 sf::Vertex...
[I wrote a lot of stuff here, then I found you told me storing more than 4 vertices was undefined behaviour, and so I removed it again... I was thinking stupid :P]
Also, I noticed that Rectangles (and Shapes in general) use triangles (a rectangle has 6 vertices), and sprites and font glyphs only 4. Maybe that is where it breaks...
-
Also, I noticed that Rectangles (and Shapes in general) use triangles (a rectangle has 6 vertices), and sprites and font glyphs only 4. Maybe that is where it breaks...
If it was that, sprites wouldn't work either on your PC.
If only text is broken, the cause is not that trivial.
-
I still don't understand how other libraries do just fine, Laurent. Other OpenGL libraries draw text just fine. While it's true it seems to be an ATI thing it's obviously not an absolute 100% ATI bug; there is a design flaw in SFML somewhere that is being missed. I've been able to do nothing for more than two weeks now because of this. ATI won't respond to my bug report, you don't seem to want to do anything about it; I am at a total deadlock right now.
It's obvious there are numerous (http://en.sfml-dev.org/forums/index.php?topic=6877.0) people (http://en.sfml-dev.org/forums/index.php?topic=8530.0) having issues with text. I hate to be the asshole, but something needs to be done on SFML's part. Ask yourself what you know about your code, Laurent, and why other libraries work just fine and SFML doesn't. Sure, ATI might be to blame, but there has to be something you can do with SFML - even if it's a patch or a hotfix that certain users can download for solving text problems.
As we deduced from the thread I had created, it's not freetype. If it's not freetype, and it's not the code built on top of SFML, and we don't have the ability to magically change the source code of the drivers, the only other component that can be changed in the equation is SFML.
This bug is killing productivity. It needs to be fixed. I really, really don't want to have to switch back to SDL because of this. I'm tired of pushing back release dates because of things that shouldn't be happening. People are asking why and all I can say is "I don't know, it's the graphics library I use. It simply doesn't work".
-
...it's not freedraw. If it's not freedraw...
FreeType I assume... ;)
Although I didn't follow the whole other thread and thus don't have as much insight as Qix, but I agree.
Then again we all know that Laurent has little time on his hands and iirc he has a Nvidia card, so maybe we (as a community) can hunt down the problem and try fixing it and I'm sure he'll try to be as much of a help as possible. ;)
-
...it's not freedraw. If it's not freedraw...
FreeType I assume... ;)
Although I didn't follow the whole other thread and thus don't have as much insight as Qix, but I agree.
Then again we all know that Laurent has little time on his hands and iirc he has a Nvidia card, so maybe we (as a community) can hunt down the problem and try fixing it and I'm sure he'll try to be as much of a help as possible. ;)
Oops, you're right; edited. Was getting confused with "libdrawtext".
I'd be totally up for testing and helping getting this fixed; it's just a matter of Laurent willing to admit there needs to be a fix ;)
I have several systems with ATI cards that I can test on and whatnot, but I honestly don't know where to go as far as testing/debugging from here. I need a little direction.
-
Also, I noticed that Rectangles (and Shapes in general) use triangles (a rectangle has 6 vertices), and sprites and font glyphs only 4. Maybe that is where it breaks...
If it was that, sprites wouldn't work either on your PC.
If only text is broken, the cause is not that trivial.
Well, sprites break as well... if I draw the font page texture using a sprite, it shows as a white square, if I draw a normal sprite, I think the same is happening. I was using a sprite texture that has a transparent pixel on the top left corner, and when drawing that directly after 2 shapes, it does not display anything. I will test it again with a test texture, seeing if only the top left pixel gets drawn across the full size... brb ;)
Edit: yes, definitely same error with sprites. So the problem seems to be only about tex coords (vertices are correct, only the top left pixel of the texture is drawn across all of the mesh).
so maybe we (as a community) can hunt down the problem and try fixing it and I'm sure he'll try to be as much of a help as possible. ;)
...
I have several systems with ATI cards that I can test on and whatnot, but I honestly don't know where to go as far as testing/debugging from here. I need a little direction.
You can start by cloning SFML from github, baking it (cmake etc., see tutorial page), installing it to /usr/local/lib/, taking the test source from the pastebin in my OP, compiling it, and running it with LD_LIBRARY_PATH=/usr/local/lib/...
-
Other OpenGL libraries draw text just fine
Please tell me which ones you've tested, so that I can compare source code.
there is a design flaw in SFML somewhere that is being missed
Don't say this please. Because a driver bug is hard to exhibit, doesn't mean that there's a design flaw in SFML. Driver bugs are usually a combination of several small (and unrelated) things, and all libraries do things differently; unfortunately this time the winner is SFML, but it doesn't mean that my code is wrong (I'm pretty sure it is correct).
yes, definitely same error with sprites. So the problem seems to be only about tex coords
And what about shapes?
An interesting test would be to use normalized coordinates and disable the texture matrix, but there are a few different things to change in the source code, and I can't do it right now. Remind me next week if I haven't done anything ;D
You can also try the "Shader" SFML example, especially the effect which distords text.
-
And more testing was done and I found another solution. I uncommented all the caching stuff from RenderTarget::draw, so every draw call would do all the required OpenGL calls itself, not trusting them to be still present, and added a pushGLStates() on top and popGLStates() on bottom. It worked. So the caching is the problem. Seems like the ATI drivers don't keep the states as others do :( Are you sure you can expect them to do so or is it just undefined behaviour ?
-
And more testing was done and I found another solution. I uncommented all the caching stuff from RenderTarget::draw, so every draw call would do all the required OpenGL calls itself, not trusting them to be still present, and added a pushGLStates() on top and popGLStates() on bottom. It worked.
Great. Now, could you try to find which call or OpenGL state exactly solves the problem? Because what you describe involves a lot of stuff.
So the caching is the problem. Seems like the ATI drivers don't keep the states as others do Are you sure you can expect them to do so or is it just undefined behaviour ?
OpenGL is a state machine. A state keeps its value until it is explicitely changed. It wouldn't make sense if the driver was doing hidden random changes.
I'm not going to explain how OpenGL works, nor explain every single line of my code, so let's first find the exact call/state that solves the problem, and then perhaps I'll be able to figure out what happens in the driver ;)
-
Please tell me which ones you've tested, so that I can compare source code.
SDL, Laurent. I've said this several times. This (http://www.libsdl.org/projects/SDL_ttf/) had been tested before and worked just fine.
Further, all other OpenGL applications that I use have never exhibited any text display issues. Why is it just SFML?
Don't say this please.
What should I say, then, Laurent? It's frustrating to see everything else work but SFML, after I've spent months building major portions of a product I had hoped to release before 2013 around a library that inexplicably refuses to work doing something you seem to think is so mundane. A revamp like switching to SDL means another 3-4 months of development/testing.
Because a driver bug is hard to exhibit, doesn't mean that there's a design flaw in SFML. Driver bugs are usually a combination of several small (and unrelated) things, and all libraries do things differently; unfortunately this time the winner is SFML, but it doesn't mean that my code is wrong (I'm pretty sure it is correct).
Perhaps you should re-read my earlier post. The fact there is a driver bug is irrelevant. SFML isn't working when other OpenGL libraries do the same thing just fine on the same graphics card SFML is broken on.
There is a flaw. I don't know how you can deny it.
What needs to be done to debug and fix this? I can't sit around and wait anymore. I need to know whether or not to ditch SFML.
iirc he has a Nvidia card
Hell, if I lived in France I'd hand-deliver an ATI card to him.
I realize the To-do list is huge and it's not easy to just fix one thing because someone (me) is whining about it. However, I've found similar issues dating back to February of this year (arguably back to December of last year) regarding text.
I don't know what else I can say past this point to persuade you that there is, indeed, something that can be done with SFML to fix text.
You can start by cloning SFML from github, baking it (cmake etc., see tutorial page), installing it to /usr/local/lib/, taking the test source from the pastebin in my OP, compiling it, and running it with LD_LIBRARY_PATH=/usr/local/lib/...
I've done this already. I've gone as far as building all related libraries SFML uses from source. I've tried building dynamically, statically, etc.
-
Please, don't hate each other now because there is a bug somewhere we don't know yet. I am really on it, and I think I have gotten pretty far on this one already. I think Laurent, we all know you'd rather keep SFML as-is and blame everything to ATI drivers, but since we don't understand the problem yet this is a stupid approach. I hope you understand that in our eyes, something can be done from SFML's side. Also, we probably have made it clear that we do not expect you to fix this for us, not only because you don't have the testing capabilities but also because we know you do this in your free time, and you don't have that much free time for issues you don't understand. But please stop trying to convince us to wait for some magic in ATI drivers to happen that fixes the issue.
I understand that some people may be angry with you (maybe Qix is) for not caring about this for a long time now. I don't think that is worth it, since you as the developer of a great piece of free software still have no responsibility for it to work. We should make it work together.
As you may have noticed, I have some basic understanding of what is going on in OpenGL myself, and while I appreciate any help from everyone here to understand the problem, I may need your help to understand what SFML is doing and why. I can't read the whole codebase and understand it, you have designed it and I would rather have some details explained by you than guessing what it is supposed to do and why. So that is what we need you for. I think we can solve the problem if we stay in touch, and you stop trying to blame ATI and forget about this bug.
-
Please, don't hate each other now because there is a bug somewhere we don't know yet. I am really on it, and I think I have gotten pretty far on this one already. I think Laurent, we all know you'd rather keep SFML as-is and blame everything to ATI drivers, but since we don't understand the problem yet this is a stupid approach. I hope you understand that in our eyes, something can be done from SFML's side. Also, we probably have made it clear that we do not expect you to fix this for us, not only because you don't have the testing capabilities but also because we know you do this in your free time, and you don't have that much free time for issues you don't understand. But please stop trying to convince us to wait for some magic in ATI drivers to happen that fixes the issue.
I understand that some people may be angry with you (maybe Qix is) for not caring about this for a long time now. I don't think that is worth it, since you as the developer of a great piece of free software still have no responsibility for it to work. We should make it work together.
As you may have noticed, I have some basic understanding of what is going on in OpenGL myself, and while I appreciate any help from everyone here to understand the problem, I may need your help to understand what SFML is doing and why. I can't read the whole codebase and understand it, you have designed it and I would rather have some details explained by you than guessing what it is supposed to do and why. So that is what we need you for. I think we can solve the problem if we stay in touch, and you stop trying to blame ATI and forget about this bug.
+1
-
SDL, Laurent. I've said this several times. This had been tested before and worked just fine.
Unless you use the not-yet-released SDL 2.0 with the OpenGL back-end, SDL doesn't use OpenGL, it's plain software rendering.
If that's what "all other OpenGL libraries" mean, sorry but this is not a valid argument ;)
Further, all other OpenGL applications that I use have never exhibited any text display issues.
Which ones?
What should I say, then, Laurent?
That ATI drivers are crappy. That's the only thing to say. And until you fully read and understand SFML code, you'll have to trust me.
It's frustrating to see everything else work but SFM
It's frustrating, I know. But again, don't say "everything else" if you can't be more precise on this point.
The fact there is a driver bug is irrelevant
It is, because I'm not supposed to work around driver bugs, and I usually don't unless the modification straight-forward.
If I had a lot of free time I would probably write a test program and start investigating. But I can't. But you can ;)
There is a flaw. I don't know how you can deny it.
As the library maintainer, I know a lot of driver bugs reported by users, and I know my code perfectly. You know none of them (or at least not better than me), so please don't say there is a flaw, unless you can spot it.
Hell, if I lived in France I'd hand-deliver an ATI card to him.
I bought one only to help users with ATI bugs. But I don't have the time too investigate.
I don't know what else I can say past this point to persuade you that there is, indeed, something that can be done with SFML to fix text
I know that something can be done, there is always a ugly workaround to apply to make things work. But ATI won't fix their drivers if everyone works around their bugs.
I'm not angry but I'd like people to focus on technical and relevant details. Saying "there's a flaw" or "it works with all other libraries" without any detail doesn't lead anywhere. Debug stuff on your side, do more tests, try to understand the code, etc. Don't come here every hour to say "there's a flaw". Please.
-
So... I can't help at the moment, I'm really sorry, but you two can continue to investigate and find more interesting things related to this bug. I think that's the best thing to do until I can help more.
Look at the "RenderTexture bug" thread: someone decided that it was time to solve this old problem, and within a few days it was solved. Users did an amazing job.
-
Unless you use the not-yet-released SDL 2.0 with the OpenGL back-end, SDL doesn't use OpenGL, it's plain software rendering.
If that's what "all other OpenGL libraries" mean, sorry but this is not a valid argument ;)
Yes, SDL 2.0. I think I would have noted that before talking about SDL.
Which ones?
All source engine games, all webGL experiments, basically any other application that uses OpenGL and text works perfectly fine.
That ATI drivers are crappy. That's the only thing to say. And until you fully read and understand SFML code, you'll have to trust me.
Laurent, we're both programmers. You and I both know that "trust me" isn't a term that is easily digested.
It's frustrating, I know. But again, don't say "everything else" if you can't be more precise on this point.
I can be precise. I've had no other text drawing issue when using any other OpenGL application other than the samples I use with SFML.
It is, because I'm not supposed to work around driver bugs, and I usually don't unless the modification straight-forward.
If I had a lot of free time I would probably write a test program and start investigating. But I can't. But you can ;)
I have written a test program, and you shot it down as something I shouldn't care about. Now we're here, and you're suggesting I do the same thing. I'm out of options.
As the library maintainer, I know a lot of driver bugs reported by users, and I know my code perfectly. You know none of them (or at least not better than me), so please don't say there is a flaw, unless you can spot it.
That is a really shitty excuse for ignoring an obvious problem.
I bought one only to help users with ATI bugs. But I don't have the time too investigate.
Well we're users, and we're having ATI bugs. You also won't help us fix it, so you must want to fix it on your own.
Perhaps it's time to start investigating.
I know that something can be done, there is always a ugly workaround to apply to make things work. But ATI won't fix their drivers if everyone works around their bugs.
Two retorts to this god awful statement: 1) Please, enlighten us. I'm sure many people would gladly put this "ugly workaround" in as a temporary fix to this gaping hole of a bug. 2) That's like saying "my son won't learn to not play with fire if we keep pouring water on him when he dowses himself in gasoline and decides to have a smoke".
Seriously? ATI doesn't give two shits about SFML. It's ATI. A big, multi-million (possibly multi-billion) dollar corporation. Their intent is to make money their own way. If they had cared the least bit about making sure there weren't any bugs, we wouldn't be having this issue in the first place.
You aren't ATI's father, you can't 'teach them a lesson'. They have a bug that has been present for several versions now, and the next couple of betas they have put out have failed to fix it thus far.
I'm not angry but I'd like people to focus on technical and relevant details. Saying "there's a flaw" or "it works with all other libraries" without any detail doesn't lead anywhere. Debug stuff on your side, do more tests, try to understand the code, etc. Don't come here every hour to say "there's a flaw". Please.
We've given you many, many "technical and relevant details". You're telling us you're not going to explain anything and that SFML is just fine and we should just ignore this bug. I've been debugging this for two weeks. There is no other explanation other than SFML isn't working without some help from you.
I'm not here every hour. I spent a week trying to fix it on my own, and finally made a thread about it. In fact, I've been taking a break from the project for another week now waiting for replies from somebody shedding some light on the matter. You gave up on it telling me that the drivers were mystical and I shouldn't try to understand why there is a bug.
To me, that sounds like you either don't care about SFML working right, just about it being clean. Secondly, it sounds like you're so caught up with the idea that SFML is yours and you want nobody to touch it that you're forgetting that it's open source and ignoring the fact that there is something wrong with it!!
There is a bug that can be fixed in SFML. We've given you all we have so far. We are two users who would rather not have to stop using SFML, which is why we made threads. I have personally spent more time on this than I should have had to spend, and the fact that the only person who seems to know this magical workaround is cock-blocking his user-base is utterly frustrating.
I would advise that instead of attacking us for asking for help, perhaps it's time to break out the ATI, give us some direction with debugging, or tell us about this magical fix from the mystical garden of workarounds...
So... I can't help at the moment, I'm really sorry, but you two can continue to investigate and find more interesting things related to this bug. I think that's the best thing to do until I can help more.
Look at the "RenderTexture bug" thread: someone decided that it was time to solve this old problem, and within a few days it was solved. Users did an amazing job.
Dear god man. We have investigated. We are at a dead end. What the hell do you expect us to do?
Not everyone has an ATI card, and not all ATI cards are affected. The only people who are going to be interested in investigating are us and you, and you seem to be doing a good job at being nonchalant about your own project.
-
Ok ok... we should stop fighting. We could continue, but I don't think it would help to solve this problem ;)
First: no, I don't know this magical workaround (sorry). I just said there's probably a way to make text work, since all other libraries do it successfully, but I have no idea how. All I know is that it could be related to non- normalized texture coordinates, so if you want a starting point to investigate further, this is all I can say for now.
You say you've already debugged it hard , and that's true. You did many tests and provided a lot of details. But the problem is still not clear, and not solved. I'm not a magician, I'm as lost as you. So what do I expect from you? To continue to investigate, try to find what's causing this in SFML, and see if a workaround can be applied. And when it works (as for the RenderTexture bug), then wow, this is really amazing and for a moment I don't feel alone anymore :P
And sorry for being nonchalant, but a lot of problems were solved by just updating to a newer (or older...) version of the driver. So it's really hard to motivate myself to spend time on this problem, if the solution is in the next version of the driver.
-
+1 to the above 2 comments ;)
I have a guess where we might have a little problem. See the following code from Texture.cpp:405
// in void sf::Texture::bind(CoordinateType) const;
// Load the matrix
glCheck(glMatrixMode(GL_TEXTURE));
glCheck(glLoadMatrixf(matrix));
// Go back to model-view mode (sf::RenderTarget relies on it)
glCheck(glMatrixMode(GL_MODELVIEW));
Thing is, RenderTarget::pushGLStates() does the following:
glCheck(glMatrixMode(GL_MODELVIEW));
glCheck(glPushMatrix());
glCheck(glMatrixMode(GL_PROJECTION));
glCheck(glPushMatrix());
glCheck(glMatrixMode(GL_TEXTURE));
glCheck(glPushMatrix());
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.
And sorry for being nonchalant, but a lot of problems were solved by just updating to a newer (or older...) version of the driver. So it's really hard to motivate myself to spend time on this problem, if the solution is in the next version of the driver.
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, but in this case, I can probably say Qix and I have both searched for the problem at our side, then investigated and found weird behavior in the libs/drivers we are using. I can completely understand you, Laurent, denying a problem with SFML in the first place.
-
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.
-
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.
-
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!
-
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?
-
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.
-
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 :)
-
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.
-
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.
-
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 :(
-
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.
-
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"? :o
Let's hope that the final version will be ok.
At least the problem is clearly identified now.
-
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.
-
Found the bug. Even have a proposed workaround.
This is the wiki page with the entire bugfind log. (https://github.com/Natoga/Rippl/wiki/Bug-Talk:-SFML-Text-Drawing) 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.
-
I'm glad to see that it was indeed a mystical driver (at least for opatut) bug :P
Thanks for the detailed report, I'll read the wiki and linked pages later today.
-
I'm glad to see that it was indeed a mystical driver (at least for opatut) bug :P
Still, it was a driver bug that only occurs with SFML :P I'll keep my eyes open to why that is the case, but I'll rest on it for now.
-
Unloading the font after the text object is creating causes an access violation. That's probably expected (I was hoping the texture for the text object actually cloned the glyph-sheet).
I guess I'm going to have to live with just a TON of fonts loaded in.
EDIT: While writing this, another test came into my head, and I tried it, and found a complete workaround for the issue without a ridiculous amount of memory (only one font loaded, as it normally would be).
Regarding the previously listed order of operations for the workaround, only the dummy font needs to be (and can be) unloaded safely. Also, the desired font can be reused.
This achieves the desired functionality.
I'm going to put it into effect and try it as it will be in production to confirm this works. Wish me luck.
-
Unloading the font after the text object is creating causes an access violation.
sf::Font holds the texture that sf::Text uses for rendering, so yes it is expected. It would be a waste to duplicate glyphs inside each sf::Text instance. It's similar to how sf::Sprite and sf::Texture work.
So having a TON of fonts loaded helps to keep the memory consumption low, by sharing glyphs among all sf::Text objects that use it, instead of duplicating them. Remember that only the used glyphs are loaded in a sf::Font instance, nothing else is (the font file is streamed on the fly when a new glyph is needed).
But wait... was it your problem? You were destroying sf::Font instances that were still being used?
-
But wait... was it your problem? You were destroying sf::Font instances that were still being used?
Nonono, that was just a test for a workaround. Read the edit in the post before yours. I found a workaround that seems to fix the problem without having to load the same font multiple times for each Text object.
It seems like the perfect workaround (as perfect as it could get).
Just to reiterate, Upon the label creation, yes the font is re-loaded into memory, but destroyed directly after. This seems to work; I'm going to re-work the issue and re-create the Lua scripts to get rid of all the mangled crap. I'll report back here after I'm done.
-
Ok ok.
I didn't read everything on the wiki yet, but I can see that at the end you talk about font size, and link to a forum topic where threads are involved.
This reminds me two things:
- bigger (and/or more) glyphs need bigger textures; if you reach your graphics card's limit additional glyphs will fail, SFML can't handle multiple textures for the same character size (yet?)
- a font loaded in a thread may not be updated in the rendering thread; in this case you need to call glFinish() after loading the font
This probably doesn't explain your problem, but it may help you to understand better how things work internally.
-
This reminds me two things:
- bigger (and/or more) glyphs need bigger textures; if you reach your graphics card's limit additional glyphs will fail, SFML can't handle multiple textures for the same character size (yet?)
- a font loaded in a thread may not be updated in the rendering thread; in this case you need to call glFinish() after loading the font
Calling glFinish() worked for one font, actually. All subsequent fonts failed to load. It also only works for setting one text object. It's an improvement but not a total fix.
EDIT: CALLING glFinish() AFTER ALL FONTS WORKS. >.> Holy crap.
Are there any implications or warnings/potential side effects with this?
EDIT2: Seems to be a complete fix. Images and text are working fine. Going to test on the Integrated intel (mac)...
-
glFinish() forces all the queued OpenGL commands to execute and finish. The call returns when the driver has executed everything.
If it solves your problem, it means that you use multi-threading, or at least multiple OpenGL contexts (ie. multiple sf::RenderTarget and/or sf::Context). Is that what happens in your program?
-
glFinish() forces all the queued OpenGL commands to execute and finish. The call returns when the driver has executed everything.
If it solves your problem, it means that you use multi-threading, or at least multiple OpenGL contexts (ie. multiple sf::RenderTarget and/or sf::Context). Is that what happens in your program?
Multithreading. :P
-
Ok... so you actually face a well known problem. We could have saved a lost of wasted time and effort ;D
-
Ok... so you actually face a well known problem. We could have saved a lost of wasted time and effort ;D
I've mentioned it was in another thread. I wasn't aware different threads were an issue other than with setActive... >.>
This should be better documented IMHO.
EDIT: I hope to hear from opatut to see if any of this helps solve his issue.
-
I've mentioned it was in another thread
The only reference to the word "thread" is lost in the middle of a sentence, in the middle of your first post, and does not really emphasizes the fact that font loading and text rendering happen in two separate threads ;)
Again it pushes the transforms, etc. and locks (thread and GL states, including setting the target to be active) and draws.
:P
This should be better documented IMHO
This should even be fixed!
I hope to hear from opatut to see if any of this helps solve his issue
I think the ATI bug which is solved by the latest beta drivers has nothing to do with that. Your problem is a logic problem in SFML, his problem is purely a driver bug (which happens in monothreaded applications).
-
I think the ATI bug which is solved by the latest beta drivers has nothing to do with that. Your problem is a logic problem in SFML, his problem is purely a driver bug (which happens in monothreaded applications).
Gah, well I feel useless now.
EDIT: Laurent, should I make a bug report for the glFinish() issue?