I am making a video game, which is a pretty small 2D shooter. Recently I noticed that the frame rate drops dramatically when there are about 9 bullets in the scene or more. My laptop can handle advanced 3D games and my game is very very simple so hardware should not be a problem.
So now I have a very big code (at least for one person) and I am pretty confused where I should look for? there are too many functions and classes related to bullets, and for example, I don't know how to analyze if the rendering function has problems or the update function? I could use MVS 2015 debugging tools for other programs, but for a game, it is not practical, for example, if I put a breakpoint before the render function, It should be checked 60 times in a second plus I can't input anything so I will never have bullets to test render function! I tried to use task manager, and I realized that CPU usage goes up really fast for each bullet, but when the game slows down only 10 percent of the CPU is used!
So my questions are:
How can I analyze functions when I can't use debugging tool?
And why game slows down while it still can use system resources?
To see what part consumes most of the processing power, you should use a function profiler. It doesn't "debug", but it creates a report when it's finished.
Valgrind is a good tool for that.
Why the game slows down? Depends on your implementation. I can create a program that divides two numbers and make it take 5 minutes to calculate the result.
We're in the video-game industry as well and we use a very simple tool on PC for CPU profiling: very sleepy.
http://www.codersnotes.com/sleepy/
It is simple, but really helped me out a lot of times. Just fire up the program from IDE and let very sleepy run for a few thousand samples and off you go!
When it comes to memory holes, Valgrind is a good tool, as already noted by The Quantum Physicist.
For timing, I would write my own small tracing/profiling tool (if my IDE does not already have one). Use a text debugging output to write short messages to a log file. Something like that:
void HandleBullet() {
printf("HandleBullet START: %i", GetSysTime());
// do your function stuff
printf("HandleBullet END: %i", GetSysTime()); // or calculate time of function directly
}
Write those debugging messages in all of the functions where you think they could take too long.
After some execution time, you can look into that file and see if something obvious happened (blocking somewhere).
If not, use a high level language of your choice to write a small parser for your created log file to tidy up and analyze your output. Calculate stuff like overall time spent in some function, or chart which functions took the longest. Should not be too difficult, if you stick to a log message style which is easy parsable for you.
Related
I made a basic opengl program and opened it up and I was only getting 2400fps with dips to 700fps in release mode, and I was really confused so I took out everything in the main loop till the code looks like below
while (true)
{
glfwSwapBuffers(window);
}
and now I'm only getting 3400-4000fps (I switched to release mode).
For a bit of context, I've made a game in DirectX 11 where when nothing is drawing it gets 8000fps and that's with input and game logic not an empty loop.
I've tried compiling my own glfw and using precompiled binaries. Im thinking that maybe I need to figure out how to build glfw as apart of my project so I can get more optimization.
I'm really confused, I want to do some heavy stuff in this game but i'm already getting 2-4x less performance when nothing is going on.
Last second addition:
People have talked about glfwswapbuffers having low performance on other threads but in all those cases they are using vysnc. (im using glfwSwapInterval(0))
There might be a multiple reasons to impact the performance of glfwSwapBuffers. Since it works asynchronously, performance might be reduced by synchronizations as v-sync, or monitor refresh rate (60Hz?). Usually you want your engine to be in sync with other processes (even if they are a limiting factor). You might also want to try glfwSwapInterval(0).
I'm trying to make a roguelike game in visual c++ 2010, which involves printing out a screen every time the player makes a move. Unfortunately, it uses 8000 characters, and so it takes a second or so to print them out every refresh. It might not seem like much, but given the number of moves involved in the game, it adds up.
I've tried unsyncing with stdio, compiling all the characters into a string and then printing the string with cout, and printing the characters with _putch();, but there was still a significant printing time for each method. I tried printing out an unchanging string repeatedly to test if it was something else causing the delay, but there was still a delay when the only task was printing.
My question is, is there anything I could try that could potentially speed up the process? A friend of mine suggested ncurses, would that be worth a try? If so, how would I do it, and if not, what else could I try?
I would agree with cornstalks. However if you are looking to make a pure console game I would suggest you take advantage of the built in ctime library. Learn from a library (such as SDL1.2) or a source on how to handle hard-coding time based events with entity systems. There are many efficient ways to store these characters and print them in a jiff. Or you can use SDL and make the game window seem like a console and handle everything as raster-graphics.
The overall program is too complex to display here. Basically, just pay attention to the green highlights in my recent git commit. I am very new to DirectInput, so I expect I've made several errors. I have very carefully studied the MSDN documentation, so I promise I'm not just throwing this out there and stamping FIX IT FOR ME on it. :)
Basically, I think I have narrowed down my problem to the area of code around Engine::getEvent (line 238+). I do not understand how these functions work, and I've messed with certain pieces to achieve different results. My goal here is to simply read in keyboard events directly and output those raw numbers to the screen (I will deal with the numbers' meaning later). The problem here relates to KEYBOARD_BUFFER_SIZE. If I make it small, the program seems to run fine, but it outputs no events. If I make it big, it runs a bit better, but it starts to slow down and then freeze (the OpenGL window just has a rotating color cube). How do I properly capture keyboard events?
I checked the return values on all the setup steps higher in the code. They all return DI_OK just fine.
Your code seems to be okay (according to this tutorial, which I have used in the past). The use of several stack-based arrays is questionable, but shouldn't be too much of an issue (unless you start having lots of concurrent getEvent calls running).
However, your best bet would be to stop using DirectInput and start using Windows Raw Input. It's best to make this switch early (ie, now) rather than realise later on that you really need to use something other than DI to get the results you want.
I am writing a program that needs to run a set of executables and find their execution times.
My first approach was just to run a process, start a timer and see the difference between the start time and the moment when process returns exit value.
Unfortunately, this program will not run on the dedicated machine so many other processes / threads can greatly change the execution time.
I would like to get time in milliseconds / clocks that actually was given to the process by OS. I hope that windows stores that information somewhere but I cannot find anything useful on the msdn.
Sure one solution is to run the process multiple times and calculate the avrage time, but I wont to avoid that.
Thanks.
You can take a look at GetProcessTimes API.
The "High-Performance Counter" might be what you're looking for.
I've used QueryPerformanceCounter/QueryPerformanceFrequency for high-resolution timing in stuff like 3D programming where the stock functionality just doesn't cut it.
You could also try the RDTSC x86 instruction.
short version:
Is there a good time based sampling profiler for Linux?
long version:
I generally use OProfile to optimize my applications. I recently found a shortcoming that has me wondering.
The problem was a tight loop, spawning c++filt to demangle a c++ name. I only stumbled upon the code by accident while chasing down another bottleneck. The OProfile didn't show anything unusual about the code so I almost ignored it but my code sense told me to optimize the call and see what happened. I changed the popen of c++filt to abi::__cxa_demangle. The runtime went from more than a minute to a little over a second. About a x60 speed up.
Is there a way I could have configured OProfile to flag the popen call? As the profile data sits now OProfile thinks the bottle neck was the heap and std::string calls (which BTW once optimized dropped the runtime to less than a second, more than x2 speed up).
Here is my OProfile configuration:
$ sudo opcontrol --status
Daemon not running
Event 0: CPU_CLK_UNHALTED:90000:0:1:1
Separate options: library
vmlinux file: none
Image filter: /path/to/executable
Call-graph depth: 7
Buffer size: 65536
Is there another profiler for Linux that could have found the bottleneck?
I suspect the issue is that OProfile only logs its samples to the currently running process. I'd like it to always log its samples to the process I'm profiling. So if the process is currently switched out (blocking on IO or a popen call) OProfile would just place its sample at the blocked call.
If I can't fix this, OProfile will only be useful when the executable is pushing near 100% CPU. It can't help with executables that have inefficient blocking calls.
Glad you asked. I believe OProfile can be made to do what I consider the right thing, which is to take stack samples on wall-clock time when the program is being slow and, if it won't let you examine individual stack samples, at least summarize for each line of code that appears on samples, the percent of samples the line appears on. That is a direct measure of what would be saved if that line were not there. Here's one discussion. Here's another, and another. And, as Paul said, Zoom should do it.
If your time went from 60 sec to 1 sec, that implies every single stack sample would have had a 59/60 probability of showing you the problem.
Try Zoom - I believe it will let you profile all processes - it would be interesting to know if it highlights your problem in this case.
I wrote this a long time ago, only because I couldn't find anything better: https://github.com/dicej/profile
I just found this, too, though I haven't tried it: https://github.com/oliver/ptrace-sampler
Quickly hacked up trivial sampling profiler for linux: http://vi-server.org/vi/simple_sampling_profiler.html
It appends backtrace(3) to a file on SIGUSR1, and then converts it to annotated source.
After trying everything suggested here (except for the now-defunct Zoom, which is still available as huge file from dropbox), I found that NOTHING does what Mr. Dunlavey recommends. The "quick hacks" listed above in some of the answers wouldn't build for me, or didn't work for me either. Spent all day trying stuff... and nothing could find fseek as a hotspot in an otherwise simple test program that was I/O bound.
So I coded up yet another profiler, this time with no build dependencies, based on GDB, so it should "just work" for almost any debuggable code. A single CPP file.
https://github.com/jasonrohrer/wallClockProfiler
It automates the manual process suggested by Mr. Dunlavey, interrupting the target process with GDB periodically and harvesting a stack trace, and then printing a report at the end about which stack traces are the most common. Those are your true wall-clock hotspots. And it actually works.