Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


SFML RenderTexture slow performance


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Equivalent   Members   -  Reputation: 101

Like
0Likes
Like

Posted 06 April 2013 - 10:20 AM

Hey guys, I just started with the C++ library: SFML and while making my game-loop I noticed something disturbing.
 
Relevant part of the Header:
public:
    virtual const sf::Texture Draw();
protected:
    sf::RenderTexture sb;
 
When I try to call the "Draw" method I use this code:
currentRenderScreen->Draw();
 
Which do this:
const sf::Texture RenderScreen::Draw() {
    return sb.getTexture();
}
 
The reason I use a RenderTexture is because I want to draw multiple sprites and images on a texture, and then display the texture as it's whole (I think it's called backbuffer?). And I need to return a "Texture" to be able to draw it in my window.
However it's extremely slow if my "RenderTexture sb" is normally big (800 width 600 height), around 200 milliseconds per call (110 on my friend's computer), if the object sb is 100 px wide and 100 high or smaller it only takes a handful milliseconds to call.
 
I'm pretty sure I'm doing something wrong as using a RenderTexture should be the optimal way to draw stuff in a game?
If it really is this heavy to use, is there any better alternative?

Edited by phantom, 06 April 2013 - 11:17 AM.
Reverting this back to the main post as it has an answer.


Sponsor:

#2 Cornstalks   Crossbones+   -  Reputation: 6991

Like
1Likes
Like

Posted 06 April 2013 - 10:58 AM

Look at your Draw method. It's returning a copy of a sf::Texture. Copying textures around is expensive. You should return a const reference (sf::RenderTexture::getTexture() returns a const reference to a texture).

In other words, don't copy the texture around. Use references. And be careful, so that you don't hold a reference to the texture if it gets destroyed.

Edit: on second thought, I'm actually not sure this is a slow operation. I know you said it doesn't affect your performance, but I just wanted to add that after thinking about it (and failing to find specific documentation) I'm not sure if it actually copies the texture (that is, it might just reference the same texture in the video card), and if it does copy the texture, it should be pretty quick (if unnecessary) because it should be a graphics card operation.
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#3 Equivalent   Members   -  Reputation: 101

Like
0Likes
Like

Posted 06 April 2013 - 11:06 AM

Ah, found it, thank you


Edited by Equivalent, 06 April 2013 - 11:23 AM.


#4 AngryPlatypus   Members   -  Reputation: 232

Like
-1Likes
Like

Posted 06 April 2013 - 06:20 PM

The SFML RenderWindow is already double buffered. The method draw(...) draws to the backbuffer and display() swaps the buffers. So there is no need for a RenderTexture in this case.

 

The texture's copy constructor loads the texture from the gpu in an image and creates a new texture from that image. Both done per pixel and as cpu operation which is definitely slow.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS