Choppy Movement
Author
All the games I try to make have choppy movement. I tried to use the framerate to control how something moves, but that just makes it choppy. I was also thinking about blocking loops, I was reading and it said blocking loops only let the game run however many times per second, thus limiting it. Is there someway I could calibrate, or find out how many times the loop is running per second and figure out what is best for the game? Then its not running the loop more than is necesarry. I tried something like that but it was still choppy and it would slow down in parts of the game, thats when I took of the constraint and let it go the fastest it could, now it went to fast. I don't know what to do, I am so confused about frame time movement and blocking loops. If anyone could enlighten me it would be greatly appreciated. thanks
Use something like TickCount. Like, movementPerSecond * TickCount. the number of times the player moves from one square to another in one second. Using loops and restraining your game from running at full speed is bad. If you want, you can make a loop that execute to kill the cycles when the tickcount doesn't change, but that's up to you.
To smooth out user input, you may want to try something like:
If inputInterval is, say 10ms, this will ensure that the user input is only processed 100 times a second, no matter how fast the game runs.
DoGameLoop();if (GetCurrentTime() >= previousTime + inputInterval){ previousTime = GetCurrentTime(); ProcessUserInput();}If inputInterval is, say 10ms, this will ensure that the user input is only processed 100 times a second, no matter how fast the game runs.
Either that, or you can calculate how many game updates should have been performed at a certain time and perform them during each iteration of the main loop.
I used to calculate a time delta and multiply all acceleration and velocitiy additions by that (variable time adjustment), but I've adopted fixed time adjustment by this method instead. It means it will still get a roughly correct update number without a high precision timer and guarantees a certain kind of consistence in the update method.
I've copied the code below from a 2D side scroller I'm doing for my cell phone (Java). Please bear in mind I'm still learning the concept of thread synchronization so it may be a bit dodgy because of that.
TARGETUPS (target updates per second) is a constant set to 30 u/s. It specifies how many game updates are wanted to occur each second.
SAMPLINGTIMEMS (sampling time in miliseconds) is a constant set to 10000 ms = 10 s. This is the time period which is measured to determine update number to comply with the target.
updateCount is a variable external to the loop which keeps track of the number of updates performed this far during the current sample period.
refTime is an external long which specifies when current update period started.
I used to calculate a time delta and multiply all acceleration and velocitiy additions by that (variable time adjustment), but I've adopted fixed time adjustment by this method instead. It means it will still get a roughly correct update number without a high precision timer and guarantees a certain kind of consistence in the update method.
I've copied the code below from a 2D side scroller I'm doing for my cell phone (Java). Please bear in mind I'm still learning the concept of thread synchronization so it may be a bit dodgy because of that.
TARGETUPS (target updates per second) is a constant set to 30 u/s. It specifies how many game updates are wanted to occur each second.
SAMPLINGTIMEMS (sampling time in miliseconds) is a constant set to 10000 ms = 10 s. This is the time period which is measured to determine update number to comply with the target.
updateCount is a variable external to the loop which keeps track of the number of updates performed this far during the current sample period.
refTime is an external long which specifies when current update period started.
//game loopwhile(isRunning){ try { synchronized(this) { if(!isPaused && isPlaying) { //sample time and get difference between it and reference int timeDiff = (int)(System.currentTimeMillis() - refTime); //calculate number of updates required int reqUpdates = ((int) TARGETUPS * timeDiff) / 1000 - updateCount; //adjust for ms by 1000 for(int i = 0; i < reqUpdates; i++) { world.update(); //fixed time } updateCount += reqUpdates; //re-reference time if we reached the end of last long newRefTime = System.currentTimeMillis(); if(newRefTime > (refTime + SAMPLINGTIMEMS)) { refTime = newRefTime; updateCount = 0; } } repaint(); //give the OS some execution time wait(5); } } catch(InterruptedException ie) { }}
Author
For Input I use this function -
GetAsyncKeyState(vknum)
Do I have to call Sleep(0) to give it time to poll the keyboard?
I took out Sleep() and it was very slow to get input. If this is true is this the way it works with Sleep(). I want the game to run as fast as it can. If I do that input interval thing will that work?
GetAsyncKeyState(vknum)
Do I have to call Sleep(0) to give it time to poll the keyboard?
I took out Sleep() and it was very slow to get input. If this is true is this the way it works with Sleep(). I want the game to run as fast as it can. If I do that input interval thing will that work?
I don't have a clue whether it matters in Windows, as long as you process the Windows messages. Evidently the OS does some work even if your application does not give any Sleep()s and tries to loop around as quickly as possible, while only stopping to deal with messages. Someone who knows what Windows does behind the scenes better than I do should really answer this one.
I put Sleep(10) in a Win32 loop of mine, but for the reason my computer fan else would sound like hell and the game take up a good 99% of execution time. Whilst that's gradually adjusted when another application starts, it takes a while and I hate the maximum frames per second = fan goes crazy thing on my computer.
--------------------------------------------
Also, why would you like to limit user input? The only problem is if the OS does not update the keyboard state quick enough, but I don't think calling GetAsyncKeyState() very often would be negative in any way; it would just return old values. Then again, if your game is based on key presses rather than key states (however using GetAsyncKeyState() does not suggest that), limiting the input function can work.
----------------------------------------------
Additionally nr. 2, are you saying your game seemed to run faster? Do what is quickest. :D Though like I said in first paragraph I don't have a clue and only someone more knowledgable or a profiler can tell. I think the native Win32 functions are not the fastest in regards to input response times though, even when querying for key states directly. DirectInput in DirectX would be best for that probably.
I put Sleep(10) in a Win32 loop of mine, but for the reason my computer fan else would sound like hell and the game take up a good 99% of execution time. Whilst that's gradually adjusted when another application starts, it takes a while and I hate the maximum frames per second = fan goes crazy thing on my computer.
--------------------------------------------
Also, why would you like to limit user input? The only problem is if the OS does not update the keyboard state quick enough, but I don't think calling GetAsyncKeyState() very often would be negative in any way; it would just return old values. Then again, if your game is based on key presses rather than key states (however using GetAsyncKeyState() does not suggest that), limiting the input function can work.
----------------------------------------------
Additionally nr. 2, are you saying your game seemed to run faster? Do what is quickest. :D Though like I said in first paragraph I don't have a clue and only someone more knowledgable or a profiler can tell. I think the native Win32 functions are not the fastest in regards to input response times though, even when querying for key states directly. DirectInput in DirectX would be best for that probably.
Author
When I let it run the fastest, the GetAsyncKeyState() functions doesn't bring back that a pushed a button. When I put Sleep() in the loop then it works just fine. I just don't want to limit my game with Sleep(). The reason for the other posters input timer is that when the game goes to fast it will say for example that I pushed the up arrow 100 times when I only push it once. So when you limit the input update it will only push it once.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
