I'm just trying to make an empty game loop that doesn't lag!
My loop does basically nothing, yet sometimes it lags enough to drop frames (I'm trying to run at 60fps)
I traced the problem to SDL_GL_SwapWindow. I made sure vsync is turned off.
Most of the time SDL_GL_SwapWindow(window); takes <1ms. But sometimes it can take long enough to drop frames. Is this normal? I can't believe my raw C++ empty game loop is sometimes dropping frames!
My code doesn't do anything interesting, I've tried tweaking it quite a bit, but I've seen no improvement. You can see it all here http://pastebin.com/GpLAH8SZ
P.S. I'm on a decent gaming desktop!
I think it is the OS, which may not schedule you 100% of time.
You can change the msdn : process class. But there is going to be intervals where windows does not have resources to keep running your code, and keep running.
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 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.
I am creating a small 2D game library (That's right world, another one!) in C++ using SDL and I finally got around to testing its current state (very much a work in progress) on linux(xubuntu 12.04). Up until now I have mostly been working on my Windows 10 install. Note: My linux and windows 10 installs are on the same machine.
At first I was using the xorg nvidia driver, my code was using hardware accelerated rendering (i.e. using the SDL_RENDERER_ACCELERATED flag when creating the SDL_Renderer) but when I ran my code I was getting poor frame rate ~100FPS, bear in mind that at this point I am only testing it by drawing one little animation on screen and on windows I was getting ~1200FPS.
I had the idea that it may be because of the graphics driver. So I switched to the recommended nvidia proprietary driver for my GPU, restarted, recompiled, and ran my game again. Then an empty window appeared, my computer froze but the FPS counter in the window title reported ~15000 FPS (woohoo!). I sighed, began bashing on my keyboard, ctrl-alt-del logged me out, and I logged back into the same frozen screen as before.
After a hard-restart I examined my test program's log and it reported that it successfully entered the game loop i.e. began rendering frames.
Now, if I add a delay in the main loop or use vsync everything is fine (and faster when using the proprietary nvidia driver), no crashes. Everything as defined.
I am confused as to what is happening, I know that my program is trying to go as fast as it can if I don't have a sleep in there but I wouldn't have thought the scheduler would give it so much processor time as to neglect the rest of the system. I tried looking into the differences between the Windows and linux schedulers but I can find a solid reason as to why my program would runaway on linux.
You can view the library code here: https://github.com/callumW/Howler the library is in Howler/ and the test program is in testsrc/ the main loop being in Game.cpp: run().
(As a side note, if you have any suggestions to the library code I would be glad to receive them).
Does anyone have any ideas as to what is happening?
It is evident that I need to cap the frame rate, and seeing as I'm not short of FPS that is not an issue. I also assume this is good practice as to not use power unnecessarily. But this peaked my interest and I wondered if anyone had an answer for me.
Hint for the future - there is no need to reboot. Enable X kill sequence (usually ctrl-alt-backspace, but disabled by default in modern distros, you have to enable it manually) as last resort, but usually it is just ctrl-alt-f1, login to tty, kill offending process, then return back to X with ctrl-alt-fN (the number of tty where X sits, most often 7). If you're working with graphics you probably will need that sooner or later.
Not sure if your problem was exactly the same as I've seen when running your program, but it is very likely so. You display FPS in window title, sending it to window manager on each frame, 15 thousands times per second. Window manager gets confused by so many window title updates (at least openbox does. Haven't tested with different WMs). Not sure if it will eventually flush accumulated changes or just hang forever; didn't wait.
Basically don't update window title more often than 10 times per second.
I'd add SDL_Delay() inside the main loop. Something like :-
while(running) {
while(SDL_PollEvent(&e) != 0) {
if(e.type == SDL_KEYDOWN) {
if(e.key.keysym.sym == SDLK_ESCAPE) {
running = false;
break;
}
}
else if(e.type == SDL_QUIT) {
running = false;
break;
}
}
update();
frames++;
//Add a delay here
SDL_Delay(0);
}
This is to give the cpu time back to the OS. In some OS (like older Windows if I'm not mistaken) if you infinitely spin loop, your application will freeze, the OS would think your application is unresponsive and will try to kill it. Etc.
I'm not really sure if this is your case, give it a try. You might want to change the value of the parameter (essentially it's the length of time you want to delay, though it's not guaranteed to be exact). I usually use 0 or 1 in the case that I don't want to limit the framerate. 13 will cap your framerate at around 60fps.
I've come across an inexplicable error in SDL 2.0.3 when using hardware rendered graphics. For some reason, around 5 minutes after the program starts my graphical window closes but my console window stays open. There is no error thrown or anything to signify a problem.
When I pause the debugger, the program puts the breakpoint inside of SDL_RenderPresent(). I followed the call stack to a function inside of ntdll.dll called WaitForSingleObject() but I'm not sure what's causing it to hang forever.
Also, this does not happen when I use software rendered graphics. I am running it on an AMD FirePro M5100 FireGL V with the latest drivers installed.
My question is, does anyone know what might cause SDL_RenderPresent() to never return?
From the description seems that there are locks not released by the lower levels of the graphics pipeline.
From the fact that it happens after 5 minutes seems that there is a resource leak somewhere.
All of this is just a wild guess of course, but I'd say that either the application code or the SDL code is leaking resources (handles to textures, vertex buffers and the like) and that part of the code (either at the lower levels of SDL or in the driver) when running out is not behaving nicely (this happens often... in many cases low-resource conditions are not very well tested and handled).
This doesn't happen in software rendering because there resources are basically unlimited. A confirm of this kind of problem would be that when running in software rendering the program works but process memory use keeps growing and growing.
Pay attention also to any code that "catches" any exception/failure and keeps running after that. Writing complex software that works correctly after an abnormal state is extremely difficult (basically impossible beyond trivial cases because exception safety doesn't scale by composition: the only way that doesn't make the complexity explode is to have logical partitioning "walls" and re-initialize whole subsystems).
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.