|
|
Strange inconsistencies
#42728
03/16/05 09:36
03/16/05 09:36
|
Joined: Jan 2005
Posts: 22 New Zealand
SteveIRL
OP
Newbie
|
OP
Newbie
Joined: Jan 2005
Posts: 22
New Zealand
|
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?
Steve
I'm on a diet of black coffee and prozac buttered toast.
|
|
|
Re: Strange inconsistencies
[Re: SteveIRL]
#42731
03/18/05 09:06
03/18/05 09:06
|
Joined: Jan 2005
Posts: 22 New Zealand
SteveIRL
OP
Newbie
|
OP
Newbie
Joined: Jan 2005
Posts: 22
New Zealand
|
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.
Steve
I'm on a diet of black coffee and prozac buttered toast.
|
|
|
Re: Strange inconsistencies
[Re: SteveIRL]
#42732
03/19/05 20:08
03/19/05 20:08
|
Joined: Jan 2004
Posts: 2,013 The Netherlands
Excessus
Expert
|
Expert
Joined: Jan 2004
Posts: 2,013
The Netherlands
|
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.
|
|
|
Re: Strange inconsistencies
[Re: Excessus]
#42733
03/21/05 10:09
03/21/05 10:09
|
Joined: Jan 2005
Posts: 22 New Zealand
SteveIRL
OP
Newbie
|
OP
Newbie
Joined: Jan 2005
Posts: 22
New Zealand
|
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.
Last edited by Marco_Grubert; 03/26/05 11:41.
|
|
|
Re: Strange inconsistencies
[Re: SteveIRL]
#42735
03/22/05 09:47
03/22/05 09:47
|
Joined: Aug 2004
Posts: 2,215
ISG

Expert
|

Expert
Joined: Aug 2004
Posts: 2,215
|
Quote:
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.
Yes,
[ img ] URL OF IMAGE HERE [ /img ]
Hope that helps!
|
|
|
Re: Strange inconsistencies
[Re: SteveIRL]
#42737
03/26/05 12:12
03/26/05 12:12
|
Joined: Sep 2003
Posts: 3,236 San Diego, CA
Marco_Grubert
Expert
|
Expert
Joined: Sep 2003
Posts: 3,236
San Diego, CA
|
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.
|
|
|
|