As I understand it, what Peter suggests should not be necessary. If the update round takes longer than 1/60 s, then the AnimationFrame subscriptions will fire fewer events. In other words, for a consumer of the subscription, it always fires on the *next* frame that the browser wants to draw. If the previous run of the Elm update function has not yet completed, then one browser frame will be ignored and effectively the frame rate will automatically scale down to 30 fps. In other words, Wil, don’t worry about this at all. Just program your update function and make it react to one of the two AnimationFrame subscriptions. The rest is taken care of for you.
2016-05-17 14:51 GMT+02:00 Peter Damoc <pda...@gmail.com>: Oh well, you can always use an accumulator like `timeSinceLastFrame` and > check it against some timePerFrame that you want. > If the time is greater than timePerFrame, reset to > (timeSinceLastFrame-timePerFrame) and update the module state. If not, just > add the delta to timeSinceLastFrame. > > You won't get the precision of a specific FPS but you should get a > consistent behavior. > > > > > On Tue, May 17, 2016 at 3:37 PM, Wil C <iam...@gmail.com> wrote: > >> Good questions. Maybe I should state the problem first. >> >> I'm writing a simple game, which makes me think that using >> AnimationFrame.diff is the right way to go, since it lines up with the >> browser's rendering. I want to spend less time rendering, and use that time >> for other things, like calculating next enemy movements. Since I think my >> game would still be fun at 30fps, I'd want to run it at half speed. >> >> Wil >> >> >> On Monday, May 16, 2016 at 11:01:46 PM UTC-7, Max Goldstein wrote: >>> >>> You can use Time.every to get deltas if you store the old one in the >>> model. The best use, other than the actual time, is things you want to >>> happen periodically but the exact millisecond doesn't matter. If you're >>> doing animation, I'll echo Peter: what's wrong with animating on the >>> browser's exact frames? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elm-discuss+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
