So, I’m making a HTML5 RPG just for fun. The map is a <canvas> (512px width, 352px height | 16 tiles across, 11 tiles top to bottom). I want to know if there’s a more efficient way to paint the <canvas>.
Here’s how I have it right now:
How tiles are loaded and painted on map
The map is being painted by tiles (32×32) using the Image() piece. The image files are loaded through a simple for loop and put into an array called tiles[] to be PAINTED on using drawImage().
First, we load the tiles…
and here’s how it’s being done:
// SET UP THE & DRAW THE MAP TILES
tiles = [];
var loadedImagesCount = 0;
for (x = 0; x <= NUM_OF_TILES; x++) {
var imageObj = new Image(); // new instance for each image
imageObj.src = "js/tiles/t" + x + ".png";
imageObj.onload = function () {
console.log("Added tile ... " + loadedImagesCount);
loadedImagesCount++;
if (loadedImagesCount == NUM_OF_TILES) {
// Onces all tiles are loaded ...
// We paint the map
for (y = 0; y <= 15; y++) {
for (x = 0; x <= 10; x++) {
theX = x * 32;
theY = y * 32;
context.drawImage(tiles[5], theY, theX, 32, 32);
}
}
}
};
tiles.push(imageObj);
}
Naturally, when a player starts a game it loads the map they last left off. But for here, it an all-grass map.
Right now, the maps use 2D arrays. Here’s an example map.
[[4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 4, 1, 1, 1, 1, 1],
[1, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 1],
[13, 13, 13, 13, 1, 1, 1, 1, 13, 13, 13, 13, 13, 13, 13, 1],
[13, 13, 13, 13, 1, 13, 13, 1, 13, 13, 13, 13, 13, 13, 13, 1],
[13, 13, 13, 13, 1, 13, 13, 1, 13, 13, 13, 13, 13, 13, 13, 1],
[13, 13, 13, 13, 1, 13, 13, 1, 13, 13, 13, 13, 13, 13, 13, 1],
[13, 13, 13, 13, 1, 1, 1, 1, 13, 13, 13, 13, 13, 13, 13, 1],
[13, 13, 13, 13, 13, 13, 13, 1, 13, 13, 13, 13, 13, 13, 13, 1],
[13, 13, 13, 13, 13, 11, 11, 11, 13, 13, 13, 13, 13, 13, 13, 1],
[13, 13, 13, 1, 1, 1, 1, 1, 1, 1, 13, 13, 13, 13, 13, 1],
[1, 1, 1, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 1, 1, 1]];
I get different maps using a simple if structure. Once the 2d array above is return, the corresponding number in each array will be painted according to Image() stored inside tile[]. Then drawImage() will occur and paint according to the x and y and times it by 32 to paint on the correct x-y coordinate.
How multiple map switching occurs
With my game, maps have five things to keep track of: currentID, leftID, rightID, upID, and bottomID.
- currentID: The current ID of the map you are on.
- leftID: What ID of
currentIDto load when you exit on the left of current map. - rightID: What ID of
currentIDto load when you exit on the right of
current map. - downID: What ID of
currentIDto load when you exit on
the bottom of current map. - upID: What ID of
currentIDto load when
you exit on the top of current map.
Something to note: If either leftID, rightID, upID, or bottomID are NOT specific, that means they are a 0. That means they cannot leave that side of the map. It is merely an invisible blockade.
So, once a person exits a side of the map, depending on where they exited… for example if they exited on the bottom, bottomID will the number of the map to load and thus be painted on the map.
Here’s a representational .GIF to help you better visualize:
As you can see, sooner or later, with many maps I will be dealing with many IDs. And that can possibly get a little confusing and hectic.
The obvious pros is that it load 176 tiles at a time, refresh a small 512×352 canvas, and handles one map at time. The con is that the MAP ids, when dealing with many maps, may get confusing at times.
My question
- Is this an efficient way to store maps (given the usage of tiles), or is there a better way to handle maps?
I was thinking along the lines of a giant map. The map-size is big and it’s all one 2D array. The viewport, however, is still 512×352 pixels.
Here’s another .gif I made (for this question) to help visualize:
Sorry if you cannot understand my English. Please ask anything you have trouble understanding. Hopefully, I made it clear. Thanks.
Well there’s a few things here so I’ll respond to them in order.
…521 SEPARATE PNG FILES?
Use one. Just one. Maybe six, tops. Think about it, you’re making every client do 500 GET requests just to get the tiles for the game? That’s bonkers.
Almost every major site ever uses spritemaps to reduce requests. Youtube, for instance, uses this one image for all of its buttons:
You should do the same.
Your concept of using the canvas as a viewport is correct from a performance perspective. Definitely don’t make it bigger than it needs to be!
As to your map performance question, giant arrays ought to be just fine to start. This is a fine way of dealing with it and I wouldn’t bother exploring other options unless your word is very, very large. If it is massive, you could have “chunks” of the world that are 400×400 (or so) and when you come to the 400th row you start to use row 0 of the next array. The most arrays “in use” at any time will be four, of course, when your hero would be on a good old four corners sort of location.
Player location wouldn’t be hard. If he was at tile 822, 20 that would mean he is in the chunk represented by
(2, 0)(if we’re starting from(0, 0)). Specifically, he’d be in tile 22, 20 of that chunk. No complex math, no ID’s. There is no need to keep track of ID’s. You don’t even have to keep track of which chunk is the last chunk. You can just know that the total map size is (say) 1200×1200, and if he tries to move to (1201, 50), you don’t even have to see if chunk(4, 0)exists. You know right away he can’t move there, the map is only 1200 tiles wide!Performance should be fine either way and will really depend on a large number of other things before you have to worry about this particular array. My advice is to worry about making the game before worrying about performance. Revisit performance once the game gets slow.
Once you get to performance, I would worry about everything except this issue first. In a canvas game its really unlikely to be the bottleneck. Reading from arrays is fast. Large arrays already in memory ought to be fast. There shouldn’t be a problem, and I wouldn’t spend time anticipating one until it actually presents itself.
EDIT: Example of viewport moving with player: http://jsfiddle.net/kmHZt/10/