I'm making a human cannonball simulation in A6.31 by applying a central velocity (phent_addvelcentral) to an entity. For some reason the velocity applied seems to be somewhat inconsistent. Most of the time it is OK but sometimes he massively overshoots the mark.

I have extracted trace data to a file and found that often the velocity that I ask for is not applied. If there is no fricton and no damping, then if I ask for a particular horizontal velocity, that velocity shouldn't change, right? So why isn't it exactly what I asked for? Most of the time it is slightly lower, but sometimes it is much higher, causing him to overshoot horribly. This is amusing to watch, but my human cannonball is getting hurt, and that costs in health insurance premiums. Am I doing something wrong? Is "phent_addvelcentral" unreliable?

The current function is not very reliable. Make sure you set the following variables at the beginning of main() :
time_smooth = 0; fps_lock=on;
ph_fps_max_lock= fps_max;

This should ensure that velocity remains constant and close to what you specified. The next update will have a more reliable version of phent_addvelcentral that's framerate independent.

Post deleted by SteveIRL

I tried it, and it has unleashed a whole new problem. The entity now falls at a speed that is dependent on the value of fps_max. If I lower that value then the thing falls slower, if I raise it, it falls faster. Since I am building a training simulator (as opposed to a normal game) I need things to be as close to reality as possible.

What is the relationship between ticks, time and frame rate? If I know this I should be able to alter the acceleration due to gravity to get things right. I think.

P.S In case this game concept looks a little strange, the simulator isn't for training human cannonballs, it's using the aiming mechanism for training a special kind of steering. I don't think human cannonballs get any kind of specialised training.

Quote:

---

What is the relationship between ticks, time and frame rate?

---

ticks: 1 tick is 1/16 second.
time: duration of the last frame in ticks.
frame rate: Frames per second.

There must be some effect of fps_max on the time things take to happen. Based on the manual I thought that was the case as well, but it would seem that there is something else at work.

I did a little experiment, and now I'm confused. If 1 tick is 1/16 of a second, then changing fps_max should have no effect on how fast something falls. To test this I had a model fall from the sky every time I pressed space bar, incrementing fps_max by 10 each time.


I measured the time using "time" and "time_physics" and the relationship between the two changes as I changed fps_max. I also timed the actual event and found that the time taken to fall the distance was indeed increasing (it got as high as 2.4s to fall a distance that started out taking about 0.8s before I stopped). However, the number of ticks taken remained approximately constant throughout. Here's a graph of what I found
ticksgraph.bmp

Essentially this graph shows that there is a mostly linear relationship between ticks passed and time passed, but that the gradient of this line is governed by fps_max.

So why does fps_max affect the number of ticks in a second? Does anyone know exactly what the relationship is?

P.S. Is there a way to make the image come up on this post? I'm new at this and I couldn't make the "image" UBB code work.

I have had the same type of problem that you have indicated. Basically, I apply a force and once in a while (apparently at random) it "explodes" and applies something like 10x the force that is supposed to be applied.

I don't understand why adding forces is not framerate independent now.

Using:

time_smooth = 0; fps_lock=on;
ph_fps_max_lock= fps_max;

at the beginning of the main function causes issues for me as well. It causes huge slowdown on the rate of things falling for me also.

It is disapppointing is that the physics engine was released nearly two years ago now we are still struggling with several unreliable and/or unfinished functions. The good news is that the physics engine is slowly approaching what it should have been on release.

Jason

Glad to see that I'm not the only one. Is anyone else having this problem? Does anyone have a solution?

Image tags only work for jpgs, png, gif.

Ticks are just a scaled version of seconds used because of historical reasons (timer chip in IBM PCs were set at this frequency).

time_physics is the amount of time spent calculating the new positions (CPU utilization if you want). It is _not_ related to game time or anything else.

FPS_MAX sets the frequency of display updates, PH_FPS_MAX sets the frequency of physics updates. This is easier if you think of it in terms of the inverse though: frame duration. Let's say display frame duration was 0.1 seconds (=10 fps) and physics frame duration was set to 0.01 seconds (=100 fps). In that case the physics engine gets called with a time value of 0.1 seconds and splits this into 10 tiny steps each 0.01 seconds long. At the end of these 10 steps the object is displayed at its new position.
What happens when fps_max is not a multiple of ph_fps_max ? The physics engine stores the remainder and keeps adding/subtracting from this time value in ph_fps_max duration increments. If fps_max was 0.003 threeframes would pass with physics objects not moving and the internal counter being increased to 0.003, 0.006, 0.009. In the fourth frame the value reaches 0.012, one 0.01 physics step is taken and subtracted from the counter which is now left at 0.002.