3 registered members (Ayumi, Akow, AndrewAMD),
1,505
guests, and 9
spiders. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Newton 2 wrapper
[Re: VeT]
#225301
09/03/08 21:44
09/03/08 21:44
|
Joined: Oct 2006
Posts: 36
BigM
Newbie
|
Newbie
Joined: Oct 2006
Posts: 36
|
Sorry, I don't have much practice at quoting code... I'm defining MAX_NEWTON_ADVANCE earlier in the code: #define MAX_NEWTON_ADVANCE 0.01 Do you think this kind of time slicing is useful for the wrapper?
|
|
|
Re: Newton 2 wrapper
[Re: VeT]
#225375
09/04/08 08:35
09/04/08 08:35
|
Joined: Aug 2004
Posts: 1,345 Kyiv, Ukraine
VeT
OP
Serious User
|
OP
Serious User
Joined: Aug 2004
Posts: 1,345
Kyiv, Ukraine
|
fitst, can you tell one more time, why you are using proc_mode = PROC_LATE; ? in this way all grapfical entities are moving a little bit "after" then physical bodies, where is the "plus" of this method? second, using "slices" would be good for "slow-mo", i think i tried another variables(not 0.01, but 1 or 1000), but i dont see any difference between this, so i'll think about your formula
int advance = time_frame/16;
int slices = integer((advance / MAX_NEWTON_ADVANCE) + 1);
int slices_left;
for (slices_left = slices; slices_left > 0; slices_left--){
NewtonUpdate(nworld, advance/slices);
}
|
|
|
Re: Newton 2 wrapper
[Re: VeT]
#225379
09/04/08 09:41
09/04/08 09:41
|
Joined: Oct 2006
Posts: 36
BigM
Newbie
|
Newbie
Joined: Oct 2006
Posts: 36
|
Ok, regarding proc_mode = PROC_LATE: The way I understand the engine processes stuff normally (without setting proc_mode) is by processing each loop that is waiting in the order in which they appear. So the first is the newton update loop and second the loop in main. Afterwards the engine will update the screen. 1- newton update loop 2- main loop 3- update screen I understand that the time variables are relative to the period between screen updates, so, at any given point in the code execution, time_frame will always refer to the time between the previous two screen updates. A (usually small) problem arises when you use the loop in main to calculate something that will be used in the newton simulation. Take, for example, a reaction to a mouse displacement that I want to convert into a target velocity and a required acceleration: target_velocity = mickey.y/(time_frame/16)
acceleration = (target_velocity - actual_velocity)/(time_frame/16) I then apply the required acceleration in a newton callback. However, because the NewtonUpdate loop is updated first, it will have access to a brand new time_frame value, which differs from the one used to calculate the desired acceleration. The result is that the body will be accelerated for a different time period and have a final velocity different from what is expected. By moving the newton update loop to last you can be sure that not only it is more in sync with what is processed in main, but you also get a marginally faster response to input (user moves mouse and sees result in the following screen update instead of having to wait for two screen updates). Of course I could move the whole calculation process inside the callback and it would be ok then, but I think that is besides the point as other kinds of calculations might not be feasible in the callback, especially if it is something heavy and you donīt want to repeat it for all sub updates newton may have to perform. This is how I interpret the flow of the engine, and indeed, in my case, the differences between desired velocities and resultant velocities did get smaller. Maybe someone has something to add/correct.
|
|
|
|