Dispatch method for repeating jobs with interval

[postcasio]

Currently the only way to create repeating dispatch jobs is with onUpdate or onRender. It would be useful to have an additional type, similar to onUpdate, that would allow repeating jobs with a specific interval.

for example:

Dispatch.every(5, callback);

Would behave similarly to onUpdate, but would be called every 5 frames instead of every frame.

[fatcerberus]

You can fake this using Sphere.sleep because Dispatch supports async functions:

Dispatch.onUpdate(async () => {
    /* do stuffs */
    await Sphere.sleep(5);
});

This works because if the callback returns a promise, the engine will consider the job to be busy until after the promise resolves.

That said, might still be worth having this facility built in.

[rhuanjl]

You can do this even more simply with:

function repeatJob(job, frameCount)
{
  job();
  Sphere.sleep(frameCount).then(()=>{repeatJob(job, frameCount);});
}

Only problem with that is that cancelling it would be tricky - though that could be done with a small extra trick.

[fatcerberus]

I don’t know if I’d consider that version simpler... and it also has subtle timing differences in that my version runs during the update phase while yours runs the first job immediately and subsequent iterations in the tick phase (because that’s when promise reactions fire).

Also the cancellation thing, like you already said.

[fatcerberus]

I thought about and I think I’m going to implement this. It seems like a common enough use case for e.g. animations and such that it would be worth having an easily-discoverable built-in function for it.

[fatcerberus]

I started to implement this locally but it turns out there's no code in the engine for handling recurring jobs that fire every N frames - you can either have a recurring job that fires every single frame, or a one-time job that fires once N frames from now. You'd think that wouldn't pose a problem, but it does because one-time jobs are internally handled a bit differently than recurring ones--they go into a separate queue and everything.

I'll need to refactor things a bit internally to support this. Nothing too difficult, just a bit tedious is all.