Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Rendertexture versus many sprites  (Read 2542 times)

0 Members and 2 Guests are viewing this topic.

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Rendertexture versus many sprites
« on: May 07, 2015, 05:29:45 pm »
I'm trying to make a game at the moment where I have objects which have many independent small animations, such as the extension/contraction of small pistons. Is it more efficient to have many sprites held in a container (one sprite per animated part) which are all drawn to the screen individually, or should I draw them all onto a rendertexture first, so that the entire object is on one texture, and then draw it to the screen in one go?

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Rendertexture versus many sprites
« Reply #1 on: May 07, 2015, 06:34:49 pm »
sf::VertexArray would be faster than many sf::Sprite instances. But it's also more difficult to use, so don't optimize prematurely.

I don't see how sf::RenderTexture would help if you have a lot of animations and thus need to update it every frame. It's not "rendering to the screen" which is expensive on the graphics card, but "rendering" -- also to render textures. And "expensive" usually only matters when you're doing heavy work in shaders or drawing millions of objects.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re: Rendertexture versus many sprites
« Reply #2 on: May 07, 2015, 06:37:14 pm »
Ah thank you. I've never been particularly sure of the purpose of rendertextures, I always assumed it was so that you could draw many textures to the screen in one go. Would it be relatively easy to convert between using many sprites and a vertex array when I've made a functional program?

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Rendertexture versus many sprites
« Reply #3 on: May 07, 2015, 06:41:32 pm »
Depends on your architecture. Of course, the bruteforce approach "put 4 vertices into the vertex array instead of using a sprite" usually works (given they use a common texture), but if the objects are persistent for a longer time, it might be worthwhile to keep them in the array. I mean it doesn't hurt to use sf::VertexArray from the beginning, code will just be slightly more verbose. But if you design it cleverly, you can abstract everything away and handle vertex array manipulations in one place.

Out of interest, how many objects are we talking about?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

shadowmouse

  • Sr. Member
  • ****
  • Posts: 302
    • View Profile
Re: Rendertexture versus many sprites
« Reply #4 on: May 07, 2015, 06:44:28 pm »
I'm making a scaled up tetris style game where there are between 4 and 12 animated parts per individual square, but it might go beyond that. So that would be up to about 1200 when nearing the end game, although if the game size were to be increased, the amount would go up massively (I'm making it as a square where all the blocks move towards the centre so near the end of the game you'll have a block of between 10x10 and 15x15 squares.
« Last Edit: May 07, 2015, 06:48:57 pm by shadowmouse »

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Rendertexture versus many sprites
« Reply #5 on: May 07, 2015, 06:47:40 pm »
So there will be in the order of hundreds? That shouldn't be a big problem for sprites.

I suggest you have a look at both sf::Sprite and sf::VertexArray tutorials and API docs, and then decide for yourself ;)
The latter may not be needed here, but it's definitely good to know.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: