4 ms·

> The ticker updates the game loop at 60 frames per second. From the project readme: “If the main game object or a game entity has an update() function, it will

by tieTYT 13y ago

> The ticker updates the game loop at 60 frames per second. From the project readme: “If the main game object or a game entity has an update() function, it will get called on each tick. If the main game object or a game entity has adraw() function, it will get called on each tick.” I'm not much of a game dev, but doesn't this imply a faulty game loop? Maybe this quote is just hand waving the minute details. This is my reference: http://gafferongames.com/game-physics/fix-your-timestep/ http://gafferongames.com/game-physics/fix-your-timestep/ The final implementation of the game loop in that article doesn't always update and render at the same rate.

sethvincent 13y ago
You're right about that. For simple games this might not cause issues. For complex games things might get messy. This could be a good thing to work on for a pull request.
lewispollard 13y ago
Modern browsers can use requestAnimationFrame to allow the browser to handle render loops differently from update loops. How this works between browsers isn't always the same, but the description tends to be along the lines of allowing the browser to use another thread for those calls, use GPU acceleration, pause rendering if the page isn't visible etc. In an engine I've been building, I've been using setInterval(1000/60) for the update loop with a delta time calculation, and requestAnimationFrame for the renderer calls, seems to work very well.
- tieTYT 13y ago
  I'm making a JS game right now and I'm using requestAnimationFrame in one loop that both updates and renders. I basically implemented that "fix your timestep" article with requestAnimationFrame as the call that does the looping for me. Is that a bad idea? Do you have any sample code showing your two separate loops or did you get this from some webpage you could show me? My first reaction to what you said is, "won't that cause threading issues because your update could be half done while you're rendering?" Then I remembered JS is single threaded.
  - lewispollard 13y ago
    I think that will work fine for the most part, but the problem is you can't be sure of what optimizations the browser is making (or will make in future builds of the browser) when using requestAnimationFrame - it's designed to allow browsers to do weird stuff to keep the loop in sync with the monitor, which isn't really what you want when processing game logic. JS is of course single threaded but requestAnimationFrame can give browsers the option to batch stuff up and do it outside of the regular javascript execution - I don't know if any browsers actually do this but it's possible. The main thing is that if your rendering FPS is low due to a lot of elements/sprites/whatever on the screen, your game logic loop could potentially still be run at full speed while requestAnimationFrame stumbles along at a lower rate. End result being that you could actually increase your FPS, because the game logic isn't sitting around waiting as long between render frames to update. Of course, setInterval doesn't guarantee a constant speed loop either, but it's at least designed to be as consistent as possible. Here's a relevant article: http://www.chandlerprall.com/2012/06/requestanimationframe-is-not-your-logics-friend/ http://www.chandlerprall.com/2012/06/requestanimationframe-i...

by tieTYT 13y ago

sethvincent 13y ago

You're right about that. For simple games this might not cause issues. For complex games things might get messy. This could be a good thing to work on for a pull request.

lewispollard 13y ago

Modern browsers can use requestAnimationFrame to allow the browser to handle render loops differently from update loops. How this works between browsers isn't always the same, but the description tends to be along the lines of allowing the browser to use another thread for those calls, use GPU acceleration, pause rendering if the page isn't visible etc. In an engine I've been building, I've been using setInterval(1000/60) for the update loop with a delta time calculation, and requestAnimationFrame for the renderer calls, seems to work very well.

tieTYT 13y ago
I'm making a JS game right now and I'm using requestAnimationFrame in one loop that both updates and renders. I basically implemented that "fix your timestep" article with requestAnimationFrame as the call that does the looping for me. Is that a bad idea? Do you have any sample code showing your two separate loops or did you get this from some webpage you could show me? My first reaction to what you said is, "won't that cause threading issues because your update could be half done while you're rendering?" Then I remembered JS is single threaded.
- lewispollard 13y ago
  I think that will work fine for the most part, but the problem is you can't be sure of what optimizations the browser is making (or will make in future builds of the browser) when using requestAnimationFrame - it's designed to allow browsers to do weird stuff to keep the loop in sync with the monitor, which isn't really what you want when processing game logic. JS is of course single threaded but requestAnimationFrame can give browsers the option to batch stuff up and do it outside of the regular javascript execution - I don't know if any browsers actually do this but it's possible. The main thing is that if your rendering FPS is low due to a lot of elements/sprites/whatever on the screen, your game logic loop could potentially still be run at full speed while requestAnimationFrame stumbles along at a lower rate. End result being that you could actually increase your FPS, because the game logic isn't sitting around waiting as long between render frames to update. Of course, setInterval doesn't guarantee a constant speed loop either, but it's at least designed to be as consistent as possible. Here's a relevant article: http://www.chandlerprall.com/2012/06/requestanimationframe-is-not-your-logics-friend/ http://www.chandlerprall.com/2012/06/requestanimationframe-i...