Are you experiencing performance problems now?
Personally if I was making that bullet shooter, I'd just use a super large static array to store all the possible bullets. Even say 64,000 is still not that much, if each bullet only has a position and colour, or whatever. Maybe then use a circular buffer acting on that array, then cap the max life of a bullet so you can always move the start pointer to chase the end pointer. Everything being so close in memory means that you can iterate over them really fast, so it doesn't matter if there are holes.
Do a quick calculation of the memory required and see if that fits your target machine.
My class has an x amount of bullets, a vector of polar vectors (with size x) and a whole lot of control variables.Why aren't these vectors stored in the bullets?
Personally if I was making that bullet shooter, I'd just use a super large static array to store all the possible bullets. Even say 64,000 is still not that much, if each bullet only has a position and colour, or whatever. Maybe then use a circular buffer acting on that array, then cap the max life of a bullet so you can always move the start pointer to chase the end pointer. Everything being so close in memory means that you can iterate over them really fast, so it doesn't matter if there are holes.Why not simply a std::vector? Reallocations happen rarely, and you can even prevent them with reserve(). Elements can be removed with the swap()-and-pop_back() idiom in constant time. This makes your whole logic much easier: You don't have invalid bullets (holes) which you have to case-differentiate, you don't waste memory, you can easily count the current number of bullets, and so on. And probably, in the end it won't even be slow.
Why aren't these vectors stored in the bullets?
How many bullet placers will there be? Because "even 500 bullets" is not much, computation shouldn't be a problem. Don't make your life unnecessarily complicated with threads, see if optimizations are necessary at all.
can't wait to see those bullets fly! 8)
It doesn't happen when using only one texture, so I know that when trying to get things colorful there's an invisible limit to the amount of bullets I can use.Use a tileset :) All bullets in one big texture, so you'll be able to achieve both colors and mass-bullet :)
In one of my old test cases I had 1600 bullets on screen with four different textures, that got me a lag of 10-20 FPS. It doesn't happen when using only one texture, so I know that when trying to get things colorful there's an invisible limit to the amount of bullets I can use.Okay, but then clearly the rendering is the bottleneck, and not the bullet data structure or the vector calculations. The conclusion is therefore to optimize the rendering part, and not everything. I doubt that threads will bring a significant change if everything else is fast. But they will for sure complicate your code.
Do not use sf::Sprite, but sf::VertexArray to draw the bullets. Make sure you draw all bullets with the same texture at once. Like this, you can minimize the amount of draw calls and texture switches (expensive).
And also gyscos idea is a good one: If you can combine the bullets in a single file, that will be faster, too.
but as far as I know VertexArrays are good for set tilemaps and generally things that don't get transformedThat is not their only application field, just a good example. I use vertex arrays in Thor to draw particles.
so I don't know if the in the end the solution will end up being more trouble than it's worth.And with threads, this problem doesn't exist? Of course you don't need to use vertex arrays if performances are okay. But if your graphics are on the limits and you have done everything on the high-level API so far (sprites with same textures are drawn together, maybe even use multiple texture rects in a single texture), then vertex arrays are the next step to look at.
I was thinking however in drawing everything into a rendertexture and then drawing it to the window.So you draw everything twice instead of once. I'm sure this will improve performance :P
That way I get to draw only one textureWrong, you draw all the bullets + 1 render texture. What do you expect sf::RenderTexture::draw() to do?
That would mean at least 8000 calculations per frame in that caseWhich are completely irrelevant if the bottleneck is the amount of draw calls and texture switches. And how do you think does sf::Sprite its vertices compute? With magic? ;)
I had already fixed most of my FPS problems a while ago. [...] So I can't say that I still have the same performance I had before.You just spoke about 10-20 FPS. Can you please explain exactly what the status quo is and which problems you actually face?
So you draw everything twice instead of once. I'm sure this will improve performance :P
You just spoke about 10-20 FPS. Can you please explain exactly what the status quo is and which problems you actually face?
Which are completely irrelevant if the bottleneck is the amount of draw calls and texture switches. And how do you think does sf::Sprite its vertices compute? With magic? ;)
Personally if I was making that bullet shooter, I'd just use a super large static array to store all the possible bullets.Why not simply a std::vector? Reallocations happen rarely, and you can even prevent them with reserve(). Elements can be removed with the swap()-and-pop_back() idiom in constant time. This makes your whole logic much easier: You don't have invalid bullets (holes) which you have to case-differentiate, you don't waste memory, you can easily count the current number of bullets, and so on. And probably, in the end it won't even be slow.
...
I have the impression that you both do premature optimization here. Keep things simple and generic, so you can change the system with few effort.