Physics update rate

[Mumbles]

Afternoon all. Here's another rare case where I actually make one of my own threads. Hopefully this one however, will not an answer that could have been found in a matter of seconds by simply searching for different keywords.

 

I got a bit bored recently, and just for a nostalgic moment, I loaded up an app on my computer called Arculator. For those that don't know, it's an emulator for old Acorn Archimedes computers. At primary school, we had loads of such computers - so any time not in lessons, would usually be spent on one of these computers. Indeed, I had little to no interest in 'normal' activities for someone of that age (5 - 11).

 

However, there's one thing that was missing from those computers, which is present in the emulator - and that's the fraps FPS counter. Unusually, it seemed that the frame rate was locked at 50 fps, which in my mind was a bit of an unusual number, after all, isn't it normally 60? I didn't take long to realise, that this was quite deliberate, and will probably have been a limitation hard coded into RiscOS itself. Why? Because it was a British computer, thus using our 50i TV frame rate, rather than the U.S. standard of 60i (59.94).

 

Indeed, I only really find frame rates of <20 to be really unplayable, so, with a bit of tweaking, I simply edited my current rendering code to 50 fps instead. After all, the time between renders is a perfect 20 ms, rather than [50/3] ms, so it's easier to calculate.

 

Also, I changed my UpdateWorld() call to reflect the new trial frame-rate.

UpdateWorld(NumUpdates);

to

UpdateWorld(NumUpdates * (1.2f));

 

 

Unfortunately, this new change does make the physics stutter a bit. Before, the values were always whole numbers (usually only ever 1 - occaisionally 2) and it was quite smooth, even when more than one update was required due to slow processing. Now, it's multiples 1.2 - and even with about 2 - 4% cpu usage, and a very constant 50 fps, it jumps about quite a bit.

 

So is this 60 updates thing a limit imposed by the engine, by newton or is there a hidden option to change the update world timestep to something else? Additionally, am I the only one who would prefer to work with numbers that are much easier to scale, like 1, 10, 50, 100, or even 1000? [Edit] What's the chance I'll be told that the 2.3 update which I passed on, would have given such a possibility?

 

 

And just for the sake of nostalgia for anyone else to, uh, enjoy (maybe?) here's a pic of some nice little explosions.

[Canardia]

UpdateWorld() doesn't affect FPS at all, only UPS. I would just add a Sleep() after Flip(0) which makes the FPS drop to 50. You will need to find some formula how the value for Sleep relates to the actual FPS, something like Sleep( wantedFPS / currentFPS * curvemaybe * somethingelsemaybe );.

[Mumbles]

I'm not meaning fps, according to fraps, it's nicely locked at 50 already. Not that I would force anyone to have 50 frames, that's their choice. I just prefer to update my world in 20 ms batches (and personally, I don't see any need to re-render if no updating has taken place, but I will always provide an option of 60 fps - or no frame-rate lock, so people can choose whichever they prefer). Pseudo-code I have so far, is:

 

//Setting up game

while not QuitGame
 Get current time
 result = (last render time) - (current time)
 if result < 20
   //World not ready to be updated - sleep, to reduce CPU usage, then test again
   sleep 1
   continue //as in, its c++ meaning, rather than sleep 1 ms before proceeding
 end if

 //Capture input

 //Apply forces to physics bodies

 NumUpdates = result / 20
 UpdateWorld(NumUpdates * 1.2) //Remove multiplication for 60 updates per second

 //Render

 last render time = current time
wend

 

with passing 1.2 or 2.4 to update world you can see that every couple of frames, the controller appears to move, just fractionally further than it does at other times. I'm guessing that this happens when for example, the world time is increased from 4.8, to 6 - maybe the engine is internally doing two updates here: once to bring it up from from 4 to 5, and then again from 5 to 6. Whereas from the previous update would just go from 3 to 4 (because 3.6 is less than 4). Of course, without knowing the internals of what Josh has done, it's purely a guess, but I know that this doesn't happen when the * 1.2 is omitted.

 

Also, that's not quite how I determine if the world is ready to be updated or not. After all, if it was 39 ms between frames, the next update should occur only 1 ms later - but with that pseudo-code, it will wait another 20. My real code will take such a situation into account, and only wait 1 ms. I just simplified it, because that's not where I'm having a minor-issue.

 

 

I should also add that this isn't a bug-report or a feature request. Just pointing out that, It would be nice if I could provide a value like 20 ms and it be totally smooth... The stutter is not that large, so most people would probably not find it to be a huge problem - but in the strive to perfection, you know...

[Canardia]

Blitz3D has a cool feature that is called frame tweening. I wish LE would have that too. It makes games which run at 5 FPS look ultra smooth, as if they were running at 60 FPS

Frame tweening needs basically 3 functions:

1) CaptureWorld() // missing from LE

2) UpdateWorld()

3) RenderWorld(tween) // tween parameter missing from LE

[Pixel Perfect]

Blitz3D has a cool feature that is called frame tweening. I wish LE would have that too. It makes games which run at 5 FPS look ultra smooth, as if they were running at 60 FPS

Timing techniques can be used to ensure movement in games remains a constant regardless of frame rate which prevents the obvious speed differences you tend to see otherwise with low frame rates. However, I fail to see how movement in a game running at 5 fps will ever look smooth like a game running at 60fps. The very reason your hardware is running the game at 5 fps is because it's taking it that long to calculate each new frames data and render it. It may still run in real time speed but the animation will look awfully choppy!

[Canardia]

It would look choppy if it would run at 5 FPS without tweening but still keeping the game speed up. I don't know exactly how it works, but I've tried the Blitz3D demos and it works (I made 10000 animated characters (some Q2 model from polycount) and it ran at 5 FPS but smoothly without choppiness). I think what it does differently with tweening is that it calculates the essential frames better than without tweening. So you get the same amount of frames, but more relevant ones which reduce the choppiness. http://en.wikipedia.org/wiki/Inbetweening

[Pixel Perfect]

But 5 FPS means that the rendered frames are only being updated 5 times a second. How can that produce smooth animation which generally requires at least 20 FPS to be acceptable (but not comfortable) to the human eye (30 being generally regarded as the minimum these days).

[Canardia]

I think it's the same effect as if you wave your finger quickly, and then you can either take some random frames which are running in different frequency than your finger's movement, so you would get sometimes images where the finger is almost at the lower end, sometimes halfway up, etc...

With tweening you would get synced frames like when the finger is exactly at the topmost position, the middle position and the lowest position, so you can do a much smoother movement by choosing more relevant frames at the same FPS.

[Pixel Perfect]

Granted carefull syncing of key frames at that low frequency may help with the continuity of percieved motion but it will never look like it being animated at 60FPS and must still look jerky as most of the between animated frames (or hardware interpolated frames) will be missing!

 

That could be a useful technique for improving the effect of animation in the region between 20 and 30 FPS though. I am quite intrigued as to how they would calculate the neccessary frame syncs! Are they simply ensuring that only key frames are presented at each available frame window ?

[Mumbles]

Presumably this only affects animations. perhaps picking the closest key frame to the tween value? I would suppose that camera motion stuttering would be completely ignored by this tweening thing as there is no keyframing. Just that maybe 1 in possibly every 5 frames, the camera appears to be moving forward by 0.5 instead of 0.25 - that's the issue I'm getting while using 1.2 multiples to effectively update the physics 50 times per second. It's not ..that.. noticeable, but still something I'd like to see go away.

 

I remember reading that the official line was simply to give AppSpeed() as the update world parameter, but I'm trying not to do that, as I can only picture the horrors of what could happen when my project turns into multiplayer - there'd be absolute hell trying to synchronise everyone. That's how I see it at this time, and so would prefer to have a fixed number of world updates that every client must adhere to, which should prevent the server from having to do to much frame interpolation when verifying the integrity of a client's instructions. 50 is more scalable than 60 and it was only today when I say the Acorn's frame rate of 50 that I had the idea. Whilst locking the frame rate at 50 is no problem at all, updating the physics at 50 seems to be more problematic. So, perhaps variable physics update speed would be something for LE 3.0 in however many months/years it's ready?

[Pixel Perfect]

I would suppose that camera motion stuttering would be completely ignored by this tweening thing as there is no keyframing.

Exactly, I can't see how this could be done with anything other than key framed animation and then would only provide partial improvement. Sorry for hi-jacking your thread btw

 

I seem to recollect Josh saying somthing about Newton liking to run at a set internal speed but I don't remember the detail, so maybe the effects you are seeing are as a result of a clash with that. Josh would throw some better light on this!

[Mumbles]

I seem to recollect Josh saying somthing about Newton liking to run at a set internal speed but I don't remember the detail, so maybe the effects you are seeing are as a result of a clash with that. Josh would throw some better light on this!

 

Maybe with the new version of Newton... In my earlier dev days with DBP (Seems like so long ago) I was using the 1.32 Newton wrapper by one of the users, by the name of Kjelle. For that version, I was actually updating the physics 100 times per second, as that seemed like a nice easy number to scale. Now, that seems a bit over-kill, but everything was smooth. But with that version. the update parameter was instead a raw figure, a float containing the number of seconds to update the world by (I used 0.01). Now it's a fraction of 50/3 milliseconds. So whilst 1.2 does give a perfect 20, I don't think this Newton likes that...

 

As much as I don't really want to, I'll probably move the physics ticker back to 60, and remove the *1.2 from the update world. Although the figures should have added up to the same, per second - it just seems smoother when sticking with 60 fps.

[Pixel Perfect]

Yes, sometimes when we don't have knowledge of the inner workings we just have to derive solutions empirically