Jump to content
  • Advertisement
Sign in to follow this  

SDL game lags. Help to detect a slow part of a code [?++, SDL]

This topic is 2034 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 everyone.


I'm facing the following problem:  when running my game tech demo/proto, there are moments when it suddenly  freezes and I'm not receiving any response from the game. CPU usage  in average is about 10-12%, also, RAM usage is not hight. After some time ( 5-7 sec ) all turns back to normal.  No loading/processing/parsing/etc is performed while the lagging part is running.


Whole project is written in C++ with usage of SDL, SDL_mixer, SDL_image and SDL_ttf;

Compiler - gcc-4.4 (g++-4.4);

OS - Debian 7 x64;

IDE - VIM/Codeblocks 12;


The game consists of 3 modules: self-made GUI lib, self-made game framework lib and the game application itself.


I have created several bash scripts to use Linux powerful tools such as gdb (console mode) and valgrind (don't like the adaptation in C::B).


Valgrind memcheck says (selective smile.png ):



==7424== HEAP SUMMARY:
==7424==     in use at exit: 187,546 bytes in 4,778 blocks
==7424==   total heap usage: 83,588 allocs, 78,810 frees, 32,787,582 bytes allocated
==7424== LEAK SUMMARY:
==7424==    definitely lost: 1,961 bytes in 26 blocks
==7424==    indirectly lost: 3,657 bytes in 99 blocks
==7424==      possibly lost: 133,177 bytes in 4,163 blocks
==7424==    still reachable: 48,751 bytes in 490 blocks
==7424==         suppressed: 0 bytes in 0 blocks
==7424== Reachable blocks (those to which a pointer was found) are not shown.
==7424== To see them, rerun with: --leak-check=full --show-reachable=yes

Valgrind's log is flooded with complains about libasound (a well-known false positive, as far as I know... ).


Also I've performed a callgrind test, but it's seems that I'm seeing nothing. Or just don't know where to look.


Call graph is in the attachment.


Please, help me to track down the source of the problem.

I can post some of the source codes, if needed.

Edited by ashEngineer

Share this post

Link to post
Share on other sites

It's seems that I've managed to deal with this problem by isolating game modules from each other, detecting the one which has generated slowdowns. It was the GUI part with slow virtual table look-ups for rendering functions. Optimizing this out was the solution.  Also my input-handling routine mutated a bit into a faster one. Thank you all for topic views :))

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!