[Solved] Ways to raise FPS

[FRex]

Well yes, vertex arrays and single texture sheet performance improvements are, frankly speaking, completely insane.
Laurent said that drawing things with one texture first, then other ect. may improve performance.
I think it's related to these lines but that's borderline too low level for me, I don't know open gl.

Uint64 textureId = states.texture ? states.texture->m_cacheId : 0;
if (textureId != m_cache.lastTextureId)
applyTexture(states.texture);

Last line ends up in gl's bind which (apparenly) is so heavy that creating tilesheets is worthwhile task peformance wise, but this really may not be true.
Also keep in mind size of texture matters(at least in my case). I got almost 2x more time usage with 1024x1024 texture instead of 32x32 one with around 6-9 untransformed vertex arrays, each with 1024 vertices(but still extremely ahead of required time cap).

[masskiller]

And now I am confused, for a moment I had the wrong idea that a vertexarray was a container like a std::vector that worked faster only because it was designed for drawable stuff only. After some reading I have understood a bit more about them, but I am still in awe when trying to make something that works. How exactly do you use a vertexarray for moving sprites? After some reading I see the utility for them in making tile maps, and some types of backgrounds, but I don't see how using them in my case may raise my FPS.

I know this may be a dumb question that might keep the thread alive further, but I want to understand entirely how do VertexArrays work and how should I use them in this case.

[FRex]

I wrote example code for tilemap with them because I didn't want to write redundant vertex array tutorial since the sfml official(not-yet-written ) one explains everything perfectly.

How exactly do you use a vertexarray for moving sprites? After some reading I see the utility for them in making tile maps, and some types of backgrounds, but I don't see how using them in my case may raise my FPS.

You can't, but if few sprites don't move in relation to each other, then you can merge them into one entity.

[masskiller]

In that case then at least for this part of the program VertexArrays are for no use to me, I can merge all bullets in to one whole something, but I need to calculate collisions with them afterwards and in the future I'll generate more complex patterns that will actually need positioning based on other bullet's position. It wasn't all that clear in the doc so I had a very different picture in mind. Still, now I know with what I'll do some backgrounds with. For now I'm better off with using the std::vector.

Thanks for that last bit of information.

[FRex]

For now I'm better off with using the std::vector.

Probably, since using vertex array for sprites that will move relative to each other would require evil hacks and they may or may not be efficient. And you don't have a real performance problem yet so heavy optimizations are pointless.

I can merge all bullets in to one whole something, but I need to calculate collisions with them afterwards

Not merge all bullets, just few into groups that move together contained within array.