As noted in the review code, a single large dt can cause at most only one evolve() step, but the angle of the oscillator/pulse progresses forward as normal (multiple steps' worth of radians). A visual example for smooth oscillation with a 5-second pause on normal settings (much more noticeable before the damping, was hard to time the screenshot):
The sim should cap the dt value (1 second seems appropriate), anything more is overkill. Additionally, if multiple steps would be run if that dt were split into multiple dts, multiple actual evolve() steps should run, and the oscillation should run as expected.
The sim's string should maintain continuity and smoothness in the event of these large dts, so it will work well on slower devices and when users come back to a tab (no steps will ever fire if the user has the tab hidden).
Please use the following code snippet to inject delays for testing purposes (I found it helpful):
function sleep( millis ) {
var date = new Date();
var curDate = null;
do { curDate = new Date(); }
while(curDate-date < millis);
}
As noted in the review code, a single large dt can cause at most only one evolve() step, but the angle of the oscillator/pulse progresses forward as normal (multiple steps' worth of radians). A visual example for smooth oscillation with a 5-second pause on normal settings (much more noticeable before the damping, was hard to time the screenshot):
The sim should cap the dt value (1 second seems appropriate), anything more is overkill. Additionally, if multiple steps would be run if that dt were split into multiple dts, multiple actual evolve() steps should run, and the oscillation should run as expected.
The sim's string should maintain continuity and smoothness in the event of these large dts, so it will work well on slower devices and when users come back to a tab (no steps will ever fire if the user has the tab hidden).
Please use the following code snippet to inject delays for testing purposes (I found it helpful):