Comparisons with SDL2

[battosaijenkins]

If this has been discussed and already beaten to death well I apologize in advance.

But I was working on collision detection & resolution example through SFML with many objects around 900 circle objects in debug mode when things started to bog down. I know in release mode it's perfectly fine at 60 fps but out of curiosity I wanted to try SDL2 to see if it's anymore efficient.

Unfortunately SDL2 doesn't have circle primitive shapes so I had to go through a bunch of tutorials to get that up and running. There were 2 methods in SDL2 to create a circle shape one was less efficient than the other, while the other one was extremely efficient as it used 1/4 of the circle drawing then used symmetry to mirror the rest and blit textures.

While this managed to cut down the rendering by at least 10-20% in SDL2 alone, SFML was still about 3x faster with sf::CircleShape and that's not even resizing the circle points down to a lesser value!

Needless to say, it most likely means my slowing down issue lies with my collision algorithm and I'm well aware of that. I probably need to use other 'fast square root' alternatives, avoid divisions as much as possible and possibly implement dynamic quadtrees (ohhh boy).

This was quite an adventure for me and I have to say I really enjoy SFML. And after avoiding SDL2 for a very long time I also like SDL2 too but SFML to me feels natural! I'm always wondering why SFML isn't as popular as it should be. It's a terrific tool for learning everything C++ and under the hood game development!

[battosaijenkins]

As I lay down each night and think of nothing but code, I've decided to re-visiting this comparison once again as I may have been biased in 1 important aspect.

On the SDL2 side I should try to point less vertices to see if that will speed up the process even more. And on SFML side I should try sf::VertexArray to see if there's any noticeable difference with sf::Vertex. And then while on that subject check performance with sf::VertexBuffer.

Not sure why I'm so ocd on this but I've gone so far tangent from my original project I might as well examine this before I make my final decision. =)

[battosaijenkins]

Well my final observations after testing... To me sf::VertexBuffer was slower than sf::VertexArray when storing 50,000 objects with sf::TriangleFan using 8 points (octagon).  The difference was roughly 580ms to 110ms .

And within the sf::VertexBuffer options, The speed was fastest with sf::VertexBuffer::Static then Dynamic then Stream respectively.

Comparing sf::Texture to a regular colour fill at around 50,000 objects regular colour fill was slightly faster at about 10% (110ms to 100ms) But anything below 5000 objects the difference is negligible. (11ms to 12ms) And sf::Vertex was faster than sf::VertexArray.

With 50000 objects using sf::Vertex in loop, using textures was 23ms as opposed to around 17ms with color fill. With 5000 objects both resulted about 1 or 2ms each.

Lastly, avoiding divisions and optimizing algorithms did speed up the rendering by another 1-4%. And less points (for instance using an octagon instead of circle) sped things up even more.

Of course, on stackoverflow there was one QuadTree expert who claimed to hit a million particles at 60fps! But I'm happy with 50,000 objects for now, maybe one day I'll tackle dynamic QuadTrees, and re-examine SDL2 as well.

Edit: Running i9-9900k + Nvidia RTX 3090 FE windows 10 x64