More efficient to remove or recycle the sprites in a container?

For a pentamino type game I want to add a cursor with blocks.


The player can select different blocks, so the cursor block will change, with different shapes and different ammount of tiles. So there are blocks that consist of 5 tiles, but also with 4 tiles or 3 tiles.

The current block has to move all together, all tiles at once, as a whole. So I use a Phaser.Container.
The tiles are added to the container and then move the container with the mouse cursor.

The problem is every time I call blockGetNext there are more sprites added. So the existing tiles from the previous block and all tiles from the next block.

Now I know you can call removeAll(true), but this will either remove the sprites from the container (and leave them in memory?) or destroy all sprites. During the game it will then constantly be creating and destroying sprites, which doesn’t seem very efficient(?).

So my question is, what is the best way to remove sprites from a container, or is it better to recycle/re-use the same sprites, but just on different positions?

// call once at start of game
blockInit: function() {

	// container for block sprites
	this._cntBlock = this.add.container(0, 0);


	this._cntBlock.x = 100;
	this._cntBlock.y = 100;


// call every time player wants to change block
blockGetNext: function(idx) {

	// all shapes
	var shapes = [
	               [ [1,0,0,0,0], //   [][] = S shape
	                 [1,1,0,0,0], //   [] 
	                 [1,0,0,0,0], // [][]
	                 [0,0,0,0,0] ],
	               [ [0,0,0,1,1], // [][][] = T shape
	                 [0,0,0,0,1], //   [] 
	                 [0,0,0,0,1], //   []
	                 [0,0,0,0,0] ],
	               [ [0,0,1,0,0], //   []
	                 [0,0,1,1,0], //   [][] =tetris block
	                 [0,0,1,0,0], //   []
	                 [0,0,0,0,0] ]
	// select the shape
	var shape = shapes[idx];

	// add tiles to build block
	for (var y = 0; y < shape.length; y++) {
		for (var x = 0; x < shape[y].length; x++) {
			var b = shape[y][x];
			if (b == 1) {
				// position
				var xpos = x * TILE_SIZE;
				var ypos = y * TILE_SIZE;
				// add sprite to group
				var spr = this.add.sprite(xpos, ypos, "sprites", "coin_white");
				// remember grid position for later when rotating 
				spr.setData("xgrid", x);
				spr.setData("ygrid", y);

// place block in puzzle
examineBlock: function() {

	for (var i=0; i < this._cntBlock.list.length; i++) {
		var xgrid = this._cntBlock.list[i].getData("xgrid");
		var xgrid = this._cntBlock.list[i].getData("ygrid");

		console.log("examineBlock x,y = " + xpos + ", " + ypos);

		// check grid positions etc.

You shouldn’t keep creating shapes.
Prerender all shapes with renderTextures, and reference them with a saveTexture key.

Thanks for the suggestion, but the advantage of individual sprites is that it keeps the memory footsprint low (good for mobile). But also if you use renderTextures, you would need to keep separate “collision maps” for all the blocks.

If you use individual sprites you have the data element to keep the positions of each tile, so that you can easily rotate those positions (both in values and on screen) and also use those values to check and see if the tiles fit in the puzzle.

So create a shape Class that holds the data and its renderTexture.
Seems to me a lot more memory friendly then going through creating shapes every time. Definitely a lot friendlier on the garbage collection.

I would probably keep one pool for all the tiles and then clear and refill the container as needed.

1: remove and reuse: I’d make a single container once with 9 sprite tiles (3x3) and simply add and remove these from the container as needed, but never destroy them or change their attributes, positions, listeners, etc…

2: why do you have a 5x5 array (shape[][]) to hold a 3x3 pattern?

3: This is a waste of your time. Efficiency of an operation that involves a few sprites every 10,000 msec will make no perceivable performance change (unless you miscode a memory leak (remove but don’t destroy) - and even then the players would need to play the game continuously for weeks before it might be an issue.)