Jump to content
  • Advertisement
Sign in to follow this  
Thirthe

[C++] pleasant but unexpected surprise

This topic is 3882 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, all! Ok, so i'm doing just another 2D action platform which takes some computation in order to make it right. More computation means less FPS, essentially, right? Anyway, i decided to implement a feature, which allows the player to shoot more than one bullet(whoa, what a feature...) and some more advanced(not really) collision detection methods. But before i implemented all that, i checked my current FPS counter and it said:"117" Now i implement these things in my Engine class and the FPS drops down to 105. So i say... okay, i didn't use the best algorithm and i probably implemented it wrong(read: not efficient). And now i move all the variables and data structures to the Player class, since it belongs there anyway, and i write ~10 get/set functions for access back in Engine class. Now i only have to replace all the var names with get/set functions and it will work. In the mean time i was thinking:"omg, this will be so slow :x". So i fixed all the compiler errors, and ran the app. I got 115-117 FPS :o My question: How can this be possible? shouldn't all those calls to other class' methods be slower? I mean, i have a new Bullet object being created every time the user clicks on LMB and then that object is being passed onto one of those method to finally push_back into a list data structure. I even have a new Bullet object created every iteration(when i check for collision). isn't that wasteful and slow? am i missing something? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
FPS is a bad measure of performance, because it incorporates too many factors. A small modification might increase performance here but decrease it there, or vice versa. People generally use a profiler to determine performance limitations in code and target them for optimization individually.

You can generally call thousands or tens of thousands of functions without noticing a reduction in performance. And if the function is inlined, there will be no reduction at all.

Share this post


Link to post
Share on other sites
why is drop of 117 to 105 , which is less than a millisecond a frame, performance slow down since you added features that require overhead? As far as the other changes you made restoring performance, I couldn't tell you with out a profiler. More than likely you are being limited by other code not the code in question, probably the blitter. Second since the getter/setter were so small they probably got inlined meaning no function call overhead.

Share this post


Link to post
Share on other sites
That is a little unclear, perhaps with some code we could see what happened... For the moment I have no idea about how it was implemented in the first time.
Perhaps your had something running in the background when you got 105 fps, perhaps your code did it, but without any code it will be hard to tell.

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
FPS is a bad measure of performance...

actually, i never thought of that, but now it seems logical to me, heh.

i have profiled a bit, and it seems that the collision checks take 40% of the time, whilst before all the changes, the Input system took most of the time.
also, all the bullet-related stuff was pretty low on the list, so i guess the problem was elsewhere!

Share this post


Link to post
Share on other sites
Perhaps you are doing something less often now? Its also possible that before, something was being constantly paged in and out (if you have a large number of projectiles this can happen) but its being paged out a lot less now.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!