2

I'm creating a particle simulator using SDL, and I'm rendering rects from a dynamic array/vector. When the simulator reaches 500 particles, I start popping the particles in the vector. at 500 particles, the memory used is at 16 MB. However, SDL is having the worst time trying to render all 500 particles, even though they are 1 pixel in length and width. The framerate goes from 60 fps at 200 particles to 10 fps at 500.

How can I ease the tax on RenderCopy? Here's a snippet:

for (int i = 0; i < DynamicParticles.size(); i++)
{
  //make particles fall 1 pixel each frame
  DynamicParticles.at(i).Advance();
      
           
        
  SDL_RenderCopy(Main_Renderer,
                 DynamicParticles.at(i).particle_texture,
                 NULL, &DynamicParticles.at(i).location);
}

Here DynamicParticles is a vector holding a class Particles. This class takes up about 15 MB when 500 items are present, and RenderCopy only takes the texture member and dstrect member.

enter image description here

Community
  • 1
  • 1
Orange Mushroom
  • 431
  • 4
  • 16
  • Why was I downvoted? If you're here to see this can you explain what is wrong here? – Orange Mushroom Dec 25 '14 at 22:35
  • I just want to know if SDL can handle this much. – Orange Mushroom Dec 25 '14 at 22:51
  • 2
    Not the downvoter but I suspect asking for performance help with secret code might be a little unpopular around here. Maybe producing the simplest case that exhibits your performance trouble would help. – jthill Dec 25 '14 at 22:51
  • 1-pixel elements hardly count as *rectangles*. All of the overhead could be in there (~30K per element!). Is simply plotting single pixels an option? – Jongware Dec 26 '14 at 01:07
  • Well, particles have to be a single pixel. http://www.notdoppler.com/frame/639.html this is what I'm trying to achieve. – Orange Mushroom Dec 26 '14 at 01:16
  • How do you know they are 1 pixel? it only says to advance them 1 pixel. (However, if they are all moving together in one direction, it could just be one texture. Even if they are moving in different directions, they could be drawn onto one texture if the motion is predictable.) – dwn Dec 26 '14 at 01:21
  • @dwn: OP says so in the post, no reason not to believe it. – Jongware Dec 26 '14 at 01:23
  • Ahh, well then, I suppose I'll have to agree :) – dwn Dec 26 '14 at 01:25
  • @dwn What? I said in the question that each particle is a pixel, I'm not sure how I could draw them all on to one texture even if they are moving in the same direction.(they are not, Advance() just applies increasing gravity and random jitters) – Orange Mushroom Dec 26 '14 at 01:26
  • That demo is not running for me in Chrome or IE, which is odd. – dwn Dec 26 '14 at 01:34
  • 1
    Do you have Java enabled? (nevermind i added an image of the demo(30000 particles)) – Orange Mushroom Dec 26 '14 at 01:35
  • I just did a test with 100,000 pixels, directly plotting them. Seems to be no problem so far. Doubling that is visibly slower, but there is still plenty room left for optimization. – Jongware Dec 26 '14 at 01:45
  • 1
    Maybe cf. http://stackoverflow.com/questions/25214556/bad-performance-with-sdl2-and-sdl-rendercopy – dwn Dec 26 '14 at 01:51
  • @Jongware Hmm, did you plot them from an array holding 100,000 SDL_Rects? EDIT: I'm now reading dawn's post, may be helpful. – Orange Mushroom Dec 26 '14 at 01:55
  • @dwn Thanks, the post proved to be helpful for my problem. – Orange Mushroom Dec 26 '14 at 02:12
  • 1
    I don't think that the other post's answer is very helpful for the actual question even if it works for single pixel particles. SDL_RenderCopy is not currently optimized for repeated calls and redundant renderer state changes. It does what it does, but don't ever use it when you want good performance. For that, code to OpenGL directly or use a wrapper that does at least use simple VBO optimizations. – Jonny D Dec 27 '14 at 03:09

0 Answers0