   Big game question
  I'm currently developing a small breakout clone and the code gets bigger and bigger each day. The problem is that sometimes the ball does not move smooth from on position to the next. I'm animating the ball with respect to the time passed.I'm suspecting some bad written code is guilty for this.Today I began questioning myself if I will have to optimize the code so that there are few cache misses and doing other optimizations in order to have smooth animation.If that is the case what should I do, how do you define cache optimization, namely low level optimizations?   
Quote:Original post by DeliveranceI'm currently developing a small breakout clone and the code gets bigger and bigger each day. The problem is that sometimes the ball does not move smooth from on position to the next. I'm animating the ball with respect to the time passed.I'm suspecting some bad written code is guilty for this.Today I began questioning myself if I will have to optimize the code so that there are few cache misses and doing other optimizations in order to have smooth animation.If that is the case what should I do, how do you define cache optimization, namely low level optimizations?Since no one's replied yet, I'll go ahead and say that a) I doubt that the animation glitches you mention are due to cache misses or other such optimization issues, and b) more information would be useful (platform? language? graphics API?).   ;  I'm using C++,opengl and developing for windows xp. It's worth to say that the animation glitches only sometimes not all the time.   ;  You might want to check  yout movement algorithm, maybe there is a calculation that isn't good depending of the values and return a wrong value/position and thus make the ball movement weird.   ;  While optimizing a program to better take advantage of cache coherency is a means of speeding it up, the speed up you'll see is typically VERY small, as is usually the case with low-level optimizations.  DONT WORRY ABOUT LOW-LEVEL/ASSEMBLY-LEVEL OPTIMIZATIONS!  Modern computers are very fast, very well put together, and modern compilers are fantastic at constructing highly optimized code.  I don't mean to sound patronizing, but if you're seeing these problems in a breakout clone, then your problems aren't going to be solved by saving a single clock cycle on a collision test.  Your optimizations should be done at a higher level, focusing on your choice in algorithms instead of how these algorithms are implemented [so long as they are implemented correctly].  Think in terms of 'big-O' time, and for now, forget the constants.Of course, that is only the case if you're seeing actual slow-down.  If it seems to be running smoothly, but acting strangely, then your problem isn't one that can be optimized away.  Instead it is a problem buried in your actual game logic.So.... does it run smoothly, but act strangely?  Does it act how it should, but run poorly [skipping, jerky movement, slow-down]?If it runs smoothly, but acts strangely, examine the code that is responsible for the object updates, responsible for animation updates, and if it is your positions that seem strange, check the code responsible for collision detection/response.If it runs poorly, but behaves properly, describe what you're using to detect collisions, and anything else that is not a linear function [pretty sure a breakout game would only be dealing with collision detection, since there is no path finding, AI, etc].Also, how are you storing/calculating your time deltas, and can your animation updating code accept time steps that are very large [larger than one frame of animation] without breaking down?   ;  This could simply be a performance timer issue. If you are writing windows only (no cross platform) then I would highly recommend the high resolution timer provided by windows: http://www.mtsu.edu/~csjudy/directX/HighPerformanceTimer.htmlVeterans please don't flame me if I'm mistaken ... have only used performance timer a few times and it worked real relly (when it was actually working at all :D)   ;  QueryPerformanceTimer is great [actually, it's what I use in everything], but even the ever-so-lame GetTickCount() will give you accuracy to the nearest 55 milliseconds, which is likely to be a few frames, but it will be consistent.  If the issue is appearing only occasionally, it's more likely an issue with something else, instead being something that is done with these time deltas, or even how these deltas are accumulated.Still though, QueryPerformanceTimer is THE way to go [for windows programming], and is a valid thing to pick up as a general rule.Of course, we don't have enough information to tell for certain [yet].   ;  Okay, I I'm starting to understand, I always had the obsession that it doesn't run smoothly because of the low level optimizations. I'm using the high performance timer and I'm having an update function like thisvoid Update(float dt){if (dt<0.001)dt = 0.001;...}notice the if there. I have to set it this way because sometimes dt is very very small(the fps is above 1000) and the collision code can't handle it. I think this may be the source of the ball moving sometimes jerky.   ;  Well there's your problem!  If you go above 100 frames a second, your game speeds up.  At your claimed fps of 1000, your game is running at a speed 10 times what it should be.  Considering that a multithreaded environment will prioritize different threads for different durations depending on system load, your game's timing was probably all over the map.Whatever is the root thing that calculates the initial time delta, and then calls 'Update()', include something to the effect of dt = 0.0f; while(dt < SMALLEST_TIME_VALUE){   dt += <wherever you're getting your time delta from>;}Update(dt);//Calls ALL updates, calculate the time delta only onceI'd advise the use of either 0.001666 or 0.001333 for your smallest possible time value, which will lock your frame rate to 60 or 75 respectively.  Generally, this is called an 'Accumulator', and it's a rather typical method of regulating frame rate.  Let me guess, the 'symptom' of your problem is your game suddenly and unexplainable experiencing sudden bursts of acceleration.  Funny enough, your problem sounds like it may very well be caused by your game running too FAST, as opposed to too slow.Oh if only we were all so lucky as to have your problem :P   ;Quote:Let me guess, the 'symptom' of your problem is your game suddenly and unexplainable experiencing sudden bursts of acceleration.  Funny enough, your problem sounds like it may very well be caused by your game running too FAST, as opposed to too slow.Yeah, that's exactly what's happening. Thank you all for the friendly answers!