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

Author Topic: [SOLVED] Best approach for rendering footprints  (Read 2089 times)

0 Members and 1 Guest are viewing this topic.

Martin Sand

  • Newbie
  • *
  • Posts: 24
    • View Profile
    • Email
[SOLVED] Best approach for rendering footprints
« on: February 18, 2018, 09:28:58 am »
I am currently working on an implementation for footprints etc.

To get this working I have created a struct which I keep in a vector and let it render every frame.
Since the texture does not change but is kept in the GPU memory, I assume it is quite fast although the game will produce thousands of footprints during a level. Every footprint is 1 sprite.

int vectorsize = m_Tracks.size();
for(int iterator = 0; iterator < vectorsize; ++iterator;){
  m_Window.draw(m_Tracks[iterator]->getComponent<RenderComponent>()->getSprite());
}

What is the best optimization (rendering time) for this?
  • Create an image and add the footprint every frame (direct manipulation of the pixel via getPixel, setPixel) and apply the image to the render texture of 1 sprite?
  • Use a texturerender instead of direct pixel manipulation?
  • Keep the current implementation and optimize to only render sprites in current view rect?

I coudl not find any good result in the forum search.

Best regards
Martin
« Last Edit: February 21, 2018, 11:58:34 pm by Martin Sand »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Best approach for rendering footprints
« Reply #1 on: February 18, 2018, 09:42:15 am »
Use a single vertex array with all the footprints inside.
Laurent Gomila - SFML developer

Martin Sand

  • Newbie
  • *
  • Posts: 24
    • View Profile
    • Email
Re: Best approach for rendering footprints
« Reply #2 on: February 21, 2018, 11:58:15 pm »
Perfect, did the job  :)

I measured the difference. By design my m_Tracks vector was faster than the VertexArray when it was below ~ 3k sprites. The VertexArray always stayed at the constant render time (at least what I measured through sf::Clock in microseconds). The vector was getting slower and slower beyond 3k sprites (sprite is 21x3 px).