My goal is to create an efficient game loop that uses requestAnimationFrame
for updating the display canvas and setTimeout
for updating the game logic. My question is should I put all the drawing operations inside the requestAnimationFrame
loop or only the main drawing operation that updates the html canvas?
What I mean by "all the drawing operations" is all of the buffering. For instance, I'd draw all my sprites to the buffer and then draw the buffer to the main canvas. On the one hand, if I put all the buffering into requestAnimationFrame
I won't be wasting cpu drawing on each logic update, on the other hand, drawing is cpu heavy and could cause requestAniomationFrame
to wait until all those operations are finished... The point of separating logic updates from drawing is so that requestAnimationFrame
doesn't get bogged down by non-drawing processing.
Does anyone have any experience with this approach to creating a game loop? And don't say "just put it all in requestAnimationFrame
," because this does slow down rendering. I'm convinced that separating logic from drawing is the way to go. Here's an example of what I'm talking about:
/* The drawing loop. */
function render(time_stamp_){//First parameter of RAF callback is timestamp.
window.requestAnimationFrame(render);
/* Draw all my sprites in the render function? */
/* Or should I move this to the logic loop? */
for (var i=sprites.length-1;i>-1;i--){
sprites[i].drawTo(buffer);
}
/* Update the on screen canvas. */
display.drawImage(buffer.canvas,0,0,100,100,0,0,100,100);
}
/* The logic loop. */
function update(){
window.setTimeout(update,20);
/* Update all my sprites. */
for (var i=sprites.length-1;i>-1;i--){
sprites[i].update();
}
}
Thanks!
Edit:
I've decided to go with web workers to completely separate the game logic from the drawing, which from what I understand, must take place in the main script loaded by the DOM.
So, I never found a great way to separate logic and drawing because JavaScript uses a single thread. No matter what I do the execution of the draw function may get in the way of the logic or vis versa. What I did do was find a way to execute them in the most timely manner possible while also ensuring constant time updates to the logic and optimized drawing using requestAnimation Frame. This system is set up to interpolate animations to make up for skipped frames should the device be too slow to draw at the desired frame rate. Anyway, here's my code.
var engine = {
/* FUNCTIONS. */
/* Starts the engine. */
/* interval_ is the number of milliseconds to wait between updating the logic. */
start : function(interval_) {
/* The accumulated_time is how much time has passed between the last logic update and the most recent call to render. */
var accumulated_time = interval_;
/* The current time is the current time of the most recent call to render. */
var current_time = undefined;
/* The amount of time between the second most recent call to render and the most recent call to render. */
var elapsed_time = undefined;
/* You need a reference to this in order to keep track of timeout and requestAnimationFrame ids inside the loop. */
var handle = this;
/* The last time render was called, as in the time that the second most recent call to render was made. */
var last_time = Date.now();
/* Here are the functions to be looped. */
/* They loop by setting up callbacks to themselves inside their own execution, thus creating a string of endless callbacks unless intentionally stopped. */
/* Each function is defined and called immediately using those fancy parenthesis. This keeps the functions totally private. Any scope above them won't know they exist! */
/* You want to call the logic function first so the drawing function will have something to work with. */
(function logic() {
/* Set up the next callback to logic to perpetuate the loop! */
handle.timeout = window.setTimeout(logic, interval_);
/* This is all pretty much just used to add onto the accumulated time since the last update. */
current_time = Date.now();
/* Really, I don't even need an elapsed time variable. I could just add the computation right onto accumulated time and save some allocation. */
elapsed_time = current_time - last_time;
last_time = current_time;
accumulated_time += elapsed_time;
/* Now you want to update once for every time interval_ can fit into accumulated_time. */
while (accumulated_time >= interval_) {
/* Update the logic!!!!!!!!!!!!!!!! */
red_square.update();
accumulated_time -= interval_;
}
})();
/* The reason for keeping the logic and drawing loops separate even though they're executing in the same thread asynchronously is because of the nature of timer based updates in an asynchronously updating environment. */
/* You don't want to waste any time when it comes to updating; any "naps" taken by the processor should be at the very end of a cycle after everything has already been processed. */
/* So, say your logic is wrapped in your RAF loop: it's only going to run whenever RAF says it's ready to draw. */
/* If you want your logic to run as consistently as possible on a set interval, it's best to keep it separate, because even if it has to wait for the RAF or input events to be processed, it still might naturally happen before or after those events, and we don't want to force it to occur at an earlier or later time if we don't have to. */
/* Ultimately, keeping these separate will allow them to execute in a more efficient manner rather than waiting when they don't have to. */
/* And since logic is way faster to update than drawing, drawing won't have to wait that long for updates to finish, should they happen before RAF. */
/* time_stamp_ is an argument accepted by the callback function of RAF. It records a high resolution time stamp of when the function was first executed. */
(function render(time_stamp_) {
/* Set up the next callback to RAF to perpetuate the loop! */
handle.animation_frame = window.requestAnimationFrame(render);
/* You don't want to render if your accumulated time is greater than interval_. */
/* This is dropping a frame when your refresh rate is faster than your logic can update. */
/* But it's dropped for a good reason. If interval > accumulated_time, then no new updates have occurred recently, so you'd just be redrawing the same old scene, anyway. */
if (accumulated_time < interval_) {
buffer.clearRect(0, 0, buffer.canvas.width, buffer.canvas.height);
/* accumulated_time/interval_ is the time step. */
/* It should always be less than 1. */
red_square.draw(accumulated_time / interval_);
html.output.innerHTML = "Number of warps: " + red_square.number_of_warps;
/* Always do this last. */
/* This updates the actual display canvas. */
display.clearRect(0, 0, display.canvas.width, display.canvas.height);
display.drawImage(buffer.canvas, 0, 0, buffer.canvas.width, buffer.canvas.height, 0, 0, display.canvas.width, display.canvas.height);
}
})();
},
/* Stops the engine by killing the timeout and the RAF. */
stop : function() {
window.cancelAnimationFrame(this.animation_frame);
window.clearTimeout(this.timeout);
this.animation_frame = this.timeout = undefined;
},
/* VARIABLES. */
animation_frame : undefined,
timeout : undefined
};
This is ripped straight out of one of my projects so there are a few variables in there that are defined elsewhere in code. red_square is one of those variables. If you want to check out the full example, take a look at my github page! userpoth.github.io Also, a side note, I tried using web workers to separate out logic and it was a miserable failure. Web workers are great when you have a lot of math to do and very few objects to pass between threads, but they can't do drawing and they are slow with big data transfers, at least in the context of game logic.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With