[SOLVED][SFML 2.0RC] Issue with sf::Text::getGlobalBounds()

[Minkihn]

Hello,

I'm encountering an issue while rendering a Text on a RenderTexture, then binding it to a Sprite before drawing it on a RenderWindow. I'm not sure if I'm doing something wrong here or if I should file a bug report.

This is basically what I'm doing (this is a condensed version of my GitHub hosted project) :

#include <iostream>
#include <string>
#include <SFML/Graphics/RenderWindow.hpp>
#include <SFML/Window/Event.hpp>
#include <SFML/Graphics/RenderTexture.hpp>
#include <SFML/Graphics/Sprite.hpp>
#include <SFML/Graphics/Text.hpp>

using namespace std;

int main()
{
  sf::RenderWindow  m_window;
  sf::Event         m_event;
  sf::RenderTexture m_texture;
  sf::Sprite        m_sprite;
  sf::Text          m_text;
  string            m_title;
  bool run;

  run = true;
  m_title = "Conversation";

  m_window.create(sf::VideoMode(800,
                                600),
                  m_title);

  m_window.setFramerateLimit(60);
  m_window.setKeyRepeatEnabled(false);

  m_text.setString(m_title);
  m_text.setCharacterSize(60);
  m_text.setColor(sf::Color(255, 127, 0));
  m_text.setStyle(sf::Text::Regular);

  // getGlobalBounds() does not return sufficient values.
  m_texture.create(m_text.getGlobalBounds().width, m_text.getGlobalBounds().height);
  m_texture.clear();
  m_texture.draw(m_text);
  m_texture.display();

  m_sprite.setTexture(m_texture.getTexture(), true);
  m_sprite.move(0, 0);

  cout << "Text height : " << m_text.getGlobalBounds().height << std::endl;
  cout << "Texture height : " << m_texture.getSize().y << std::endl;
  cout << "Sprite height : " << m_sprite.getGlobalBounds().height << std::endl;

  while (run)
    {
      m_window.clear();

      while (m_window.pollEvent(m_event))
        {
          if (m_event.type == sf::Event::Closed)
            {
              run = false;
            }
        }

      m_window.draw(m_sprite);
      m_window.display();
    }

  return EXIT_SUCCESS;
}
 

Here is a screenshot showing the issue (I'm on a dual screen setup with boosted accessibility options turned on, don't be afraid)

As you can see, text is cut off, and there is even rendering glitches between "s" and "a". I'm using the default font though (and already tried others - such as Neverwinter.ttf - and saw the same remaining issue anyway).
I already saw bug reports about get{Local|Global}Bounds() not handling trailing white spaces, but I'm not sure this is related.

I'm using Arch Linux with Nvidia official driver, in case that would matters.

Thanks.

[eXpl0it3r]

As you can see, text is cut off, and there is even rendering glitches between "s" and "a". I'm using the default font though (and already tried others - such as Neverwinter.ttf - and saw the same remaining issue anyway).
I already saw bug reports about get{Local|Global}Bounds() not handling trailing white spaces, but I'm not sure this is related.

So I guess you're refering to the issue #216, I guess it could be related since it also states "it depends on single character heights".

Also see here and Nexus solution proposal here.

The text artefact unfortunatly happens often, I'm not sure anymore how it can be fixed...

Btw. you could also just include SFML/Graphics.hpp instead of all of those 5 diffrent headers.

[Minkihn]

I guess it could be related since it also states "it depends on single character heights".

Well, shouldn't the primary letter be rendered entirely then?

Btw. you could also just include SFML/Graphics.hpp instead of all of those 5 diffrent headers.

Absolutely. I just cut/pasted previously written includes and as I originally decided to do single includes for libs, I just try to stick to this principle. I might reconsider it eventually.

Thanks for the links. I already went through those but I guess I'll have to write external bits such as Nexus' snippet meanwhile :-/

Despite this bug, SFML is a very clean and convenient library to use, but bad rendered text is quite blocking for user interface layers.

[texus]

Is your text drawn fully when including the left and top of the text?

m_texture.create(m_text.getGlobalBounds().width + m_text.getGlobalBounds().left, m_text.getGlobalBounds().height + m_text.getGlobalBounds().top);

[Minkihn]

Actually, yes, and the size of the RenderTexture seems to perfectly fit.

The thing is that there is some space between actual sf::Text coordinates and its rendered characters. I wonder why I haven't had it in mind. May'be this is something that should be pointed up in the doc.

Thanks for the tip :-)

[Nexus]

Absolutely. I just cut/pasted previously written includes and as I originally decided to do single includes for libs, I just try to stick to this principle. I might reconsider it eventually.

I wouldn't.

If you know specifically which functionality you need, include it (and only it). Like this, you directly see the dependencies of the implementation at the beginning of the file. Additionally, the compile time can largely decrease when using selective include directives.

[eXpl0it3r]

I wouldn't.

You wouldn't what exactly? Reconsider his principle or stick to his principle?

If you know specifically which functionality you need, include it (and only it). Like this, you directly see the dependencies of the implementation at the beginning of the file. Additionally, the compile time can largely decrease when using selective include directives.

I agree!
I'm just often to lazy to gather all the needed headers and for small projects it doesn't matter that much.

[Minkihn]

I wouldn't.

If you know specifically which functionality you need, include it (and only it). Like this, you directly see the dependencies of the implementation at the beginning of the file. Additionally, the compile time can largely decrease when using selective include directives.

That was my concern to begin with, and QtCreator is handy for a lot of things. Proper autocompletion on includes helps a lot.
I was thinking some files may end up with a huge list of includes, but that would probably mean my design suck anyway.