hmmm.. not MAX_NEWTON_ADVANCE nor MIN_NEWTON_ADVANCE declared by default... how do you get it in your code?

sorry, there weren't releases for a long time: now i have some hard work with compound objects

Great job, I will test your wrapper later. I have looked over the newton-files and i looks like you didn't implement the vehicle function yet. It would be great if you could face this next.

no, vechile would be later, now i'm finishing my work on compounds, and working with arcimedian buoyancy.. after them there would be joints and vechile
i think, in a week or two, it would be ready

Sorry, I don't have much practice at quoting code...

I'm defining MAX_NEWTON_ADVANCE earlier in the code:



Do you think this kind of time slicing is useful for the wrapper?

heh, i send you pm and didnt see your message

i'd try to test ever time slicing wich i could find: in my previous demo, boxes falled like in water, too slow... maybe this could help, i'd see..

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

okay, what about my part of work - i had a lot of troubles with compounds, but i'm still work hard on them...

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:


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.

damned, so you again put not all code? can you give me all code to see, how youe slicing works, because i like your idea, but code that you wrote dont works for me..