Jump to content

Recommended Posts

Hi all I'm CodingButter

I have been developing a 2d game engine from scratch. I wanted to get some opinions about the tick and render loops. I currently have my render loop executing as fast as requestAnimationframes will let me. And I've also trigger my ticks with setTimeout. I've noticed by doing this I am consistently getting 200 ticks per second. I was wondering what the drawbacks would be for using setTimeout in this way. I personally don't seem to see anything but improvement to my game behavior. but I'm sure there is something big i'm overlooking performance wise. Any thoughts. Also Excited to find a community to chat with.

Codesandbox.io Link Twitch Discord

 

Link to post
Share on other sites

For your loop you should implement a frame rate.

var throttle = 0;

var frameRate = 60;
var frameTime = (1000/60) * (60 / (frameRate) ) - (1000/60) * 0.5;

var progression;

loop(time) {

       if(throttle === 0) throttle = time;
       progression = time - throttle;

       if(progression >= frameTime) { //progression is going to be 16.something in this case,
             //and frameTime is about 8 when frameRate is 60. Less than 60 will slow the loop.

             //do loop stuff


             throttle = time;          

      }   

      requestAnimationFrame(loop);

}

 

Link to post
Share on other sites

Welcome @codingbutter!

As you may know, whether using setTimeout or requestAnimationFrame the delivered framerate will be limited based upon what is attempted to be done between each redraw (because single thread).  Hitting the CPU bottleneck was more commonplace a few years ago for HTML5 games, these days less so but it's still relevant to the design question.  So a follow-up question might be whether work(ers) can be done off the main thread - and would that help anyway?  Another question is whether inputs can (or should) be resolved on update, or whether they should be resolved (potentially multiple times) between updates.  But back to the original question ... RAF is synchronised with the display, it's almost perfect for a main render loop.  setTimeout may, theoretically, trigger faster, but to what actual benefit (if it can't be seen?), and at what cost in terms of clean up and resync?  There's nothing stopping running the main loop multiple times within a single RAF call - or more usefully running some aspects of the game logic that benefit from fidelity (e.g. physics iterations).  But most physics engines do that by default.  So ... how about embrace RAF and then dig into the finer points on workers, inputs, iterations, etc?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...