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.