2
\$\begingroup\$

So, I have this small class with a collision detection function in it, it's called every frame.

When I run the game I get around 8000 FPS, but when the collision function gets called it drops to 2000.

This is what the function looks like (only called 1 time per frame) The second one is just for overriding.

bool DetectCollision(sf::RectangleShape other)
{
    if (entityRect.getGlobalBounds().intersects(other.getGlobalBounds()))
    {
        // Handle collision here
        return true;
    }
    else
    {
        return false;
    }
}

bool DetectCollision(sf::Sprite other)
{
    if (entityRect.getGlobalBounds().intersects(other.getGlobalBounds()))
    {
        // Handle collision here
        return true;
    }
    else
    {
        return false;
    }
}

Not sure why the FPS drops that much, is this way of detecting collisions heavy for the pc? I'm running a pretty high-end pc.

\$\endgroup\$

2 Answers 2

2
\$\begingroup\$

It can be expensive depending on what collision volumes you are using. This is why most of the geometry in games have multiple collision volumes like AABB to convex hull. Testing whether or not two AABB intersect can save a lot of time when objects don't collide as you don't have to perform that e.g. time-consuming convex hull collision detection to get a more accurate collision.

I don't think that's really the problem though, my first reaction was that you were using FPS to messure performance. You should really always use milliseconds per frame instead. 8000FPS = 0.125ms, while 2000FPS = 0.5ms. So 0.5ms - 0.125ms = 0.375ms added to each frame. Now that may or may not be a lot depending again of what collision you are doing.

Just to drive my point in further. If the game ran at 100FPS and you now added your collision calls to each frame it would only drop to 96FPS, not that much. And your probably wouldn't be so worried about it.

\$\endgroup\$
5
  • \$\begingroup\$ Alright, I will look in to those things! Have never heard of them before (I'm pretty new to game programming in c++). \$\endgroup\$
    – BiiX
    Nov 29, 2015 at 22:17
  • \$\begingroup\$ @BiiX Well since you are new to game programming I also recommend looking into quadtrees if you are dealing with 2D or octrees if 3D. It's used to partition up the game space for more efficient collision testing with many objects. Also consider marking the answer as accepted if it actually answered your question. \$\endgroup\$
    – Christer
    Nov 29, 2015 at 22:28
  • \$\begingroup\$ Alright, will look in to the as well! \$\endgroup\$
    – BiiX
    Nov 30, 2015 at 5:54
  • 2
    \$\begingroup\$ Funny, I realized that it wasn't the collision detection that dropped the frame, it was actually the printing "collided" to the screen that dropped the frame. Removed that part and now it barely drops any frames at all when collliding. \$\endgroup\$
    – BiiX
    Nov 30, 2015 at 6:10
  • \$\begingroup\$ @BiiX Haha, I know that too well. I once had an assignment to show how multiple threads can corrupt each-other by accessing the same object at the same time. However it almost never happened, even with 10 or more threads with 1000s of iterations. Turned out it was because I was printing in the loop so each thread would spend 99% of their time printing decreasing how often they would access the object. Removed the printing, problem solved, thousands of corrupted reads. My friend had the exact same problem, shows how easy it is. No one suspects the print function. :P \$\endgroup\$
    – Christer
    Nov 30, 2015 at 13:31
2
\$\begingroup\$

It's pretty much expected to see that kind of frame drop... 8000fps translates to 0.0000125 seconds of computation time, while 2000fps translates to 0.00002s. Subtracting those two values, the difference is as low as 0.000075s, which is way low compared to the 16 milliseconds time span you have to render at 60fps.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .