the fundamental problem, as already mentioned, is that you do not run update at a fixed speed, IE some fixed number of updates per second.
this is caused by using a standard game loop running at whatever speed it runs at on your PC.
This is often solved by always using the same frame-rate in calculation, Google for "fix your timestep" or "fixed timestep gameloop" and you should find many links on this site alone, as well as others.
well that would require me to rework my entire game as i have not a single physics function seperate from everything else. Not worth it just for friction.
Is there no other way?
there are actually TWO ways to get a fixed update speed.
the first, as already mentioned, is to "fix your timestep" as explained in Gaffer's article online. this algo passes render ET into the update functions, which then "consume" it in specific DT sized chunks of time. both current and previous state are stored, and render does a tween between previous and current states when drawing. the result is render runs as fast as possible, and updates run at a specific speed, such as 30Hz. but as you say,this requires a bit of modding to an already existing game. the algo also needs to include code to handle long render times to avoid becoming un-play-ably unresponsive under heavy graphics load.
the second method is used to keep basic game loops from running too fast on faster PCs. this is the framerate limiter method. this algo uses a timer to time the duration of a single main game loop iteration. at the end of the main loop, it goes into a loop and waits until a specified amount of time has passed since the start of this iteration of the main game loop. so lets say you want to run at 60fps, which means update at 60Hz in a standard game loop. so you do something like this:
while !quitgame
start_timer
process_input
update_all
render_all
while(elapsed_time<15ms)
{
// do nothing
}
}
decide what your desired FPS/update Hz is, and set your framerate limiter time appropriately.
i find this method much easier to implement than "fix your timestep". another advantage is has over "fix your timestep" is that it automatically degrades gracefully under heavy graphics load, without the need for special code to handle long render times.
the downside is that render wont run as fast as possible, so you may surrender some smoothness in animations, depending on the difference between the limited and unlimited frame rates.
three approaches are possible for selecting the limited rate:
1. at the unlimited rate on the target PC. faster PCs will run at the same rate. slower PCs will runs slower. heavy graphics will cause momentary noticeable slowdowns on the target PC.
2. somewhat below the unlimited rate on the target PC. faster PCs will run at the same rate. much slower PCs will runs slower. the heaviest graphics will occasionally cause momentary noticeable slowdowns on the target PC.
3. as low as possible while maintaining sufficient responsiveness on the target PC. basically you run the game as slow as you can. almost all PCs will run at the same speed. even the heaviest graphics will almost never cause slowdowns on the target PC. good for games with complex update methods - leaves more time for simulating everything.
can also be good for games with occasional heavy graphics. a slower but stable framerate is sometimes preferable to a faster but spikey framerate.