Lots of sprites or one canvas?

If I have a playing field the size of 2048x2048 and want to build a level out of 64x64 sized blocks, which one is more effective (with collision detection, pathfinding and such)?

• just creating as many sprites as needed, say about 800
• making one large canvas and drawing the tiles on it

I ran some tests and it runs faster with individual sprites. In fact, just having the canvas present seems to slow it down. Of course, they were both running at over 1000 fps, but you might encounter slower speeds at larger sizes(only tested it with 640x480).

I was thinking about the same some time ago and after some tests i made few 640x450 sprites for my background images (my layout is 8x640 width and 7x450 height = 5120x3150) and works fine, maybe my game file is a little bigger then usualy...but who cares?

In fact, just having the canvas present seems to slow it down.

That's because DirectX treats the canvas as one huge texture. A 2048x2048 canvas would take up way more vram.

Use sprites. Actually, for tiles that don't need any animation, use Background Tile objects. BG Tiles are lighter than sprites.

And if you want to squeeze a little more performance out of it, use only one tile that's solid and make it invisible, and have all of your other BG Tiles just decorative. Stretch and place your invisible BG Tiles where they're needed in the layout. You'll get a little more performance out of doing collision checks against just one or two types of solid tile as opposed to making every decorative tile in your game solid.

Another optimization tip: Tiles and sprites draw faster when the same ones are all lined up nicely in Z order. According to Ashley, objects get drawn according to their Z order, so if the tiles are all scrambled up the graphics card has to continuously swap out a new texture to render every time it draws an object. If they're all lined up it only needs to swap the texture once, then draws all the objects, then swaps again at the next object and draws all those. Apparently the texture swapping operation is one of the slower things your graphics card does, so making sure (at least most) of your tiles are z-ordered nicely will make things run a little smoother as well.

Also, you shouldn't have to worry about making sprites "as needed," the island level of This Cursed Rock is 3840x2880 and it's full of static tiles I placed with the layout editor (1225 objects, and I didn't even z-sort them ). So you're really not going to run into any performance issues in that respect, for the most part.

Use tiled backgrounds with a power-of-two square texture wherever possible, which sounds like it'll work well, since you're using 64x64 tiles (which is a power-of-two). Graphics cards can draw tiled power-of-two images in one go, which is really fast, whereas if the texture is not power-of-two, the tiled background draws it the same way it would a series of sprites lined up.

Avoid large canvases. As Deadeye said, they will always create a texture the size of the object, which uses a lot of VRAM. As a rule of thumb, don't create a canvas bigger than the application window.

Okay sometimes I need things spelled out for me. So about this whole z ordering business let me see if I've got this straight.

Let's say within a certain layer of a layout you place all of your decorative scenery. Let's say you've got one tile for dirt, one for grass and one for clouds and you just use multiple copies of those three tiles to decorate the whole level. So if understand this correctly the z ordering means that you would want to say select all of your dirt tiles and send them all to the back. Then select all the grass tiles and send them all to the front. Then select all the cloud tiles and send them all to the front.

Is that what you guys mean by z ordering?

Okay sometimes I need things spelled out for me. So about this whole z ordering business let me see if I've got this straight.

Let's say within a certain layer of a layout you place all of your decorative scenery. Let's say you've got one tile for dirt, one for grass and one for clouds and you just use multiple copies of those three tiles to decorate the whole level. So if understand this correctly the z ordering means that you would want to say select all of your dirt tiles and send them all to the back. Then select all the grass tiles and send them all to the front. Then select all the cloud tiles and send them all to the front.

Is that what you guys mean by z ordering?

Yes, pretty much. You can also do it at runtime by making, say, a z-sort group that runs once at start of layout so you don't have to do it manually.

But this is pretty much just an optimization for lower-end cards if there are lots and lots of tiles, and honestly it's probably not going to give you a huge performance boost on it's own... maybe just a few more fps. But if you're optimizing a large game that's lagging then every frame per second counts, and shaving off a few here and there adds up.

Yeah, you can do that or put all objects with the same texture on their own layer, so even accidental send to front/send to back won't change the layer, and still allows the GPU to keep the same texture loaded.

However, that's probably of the more subtle areas you could optimize. The canvas thing is much more important (don't make them bigger than the screen if you can). I wouldn't bother building your game from the ground up with the Z ordering thing in mind. It won't make any noticable difference unless you're using hundreds, or thousands, of on-screen objects which are intermingled with other objects in the Z order, which is a fairly rare situation.

You're much better off optimising the use of pixel shaders, or not bothering at all, until your framerates prove you actually need to start speeding things up (what's the point if it runs fine anyway?).