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

Started by
0 comments, last by knd 10 years, 11 months ago

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.

Advertisement

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 :))

This topic is closed to new replies.

Advertisement