Tiles won't scale when I scale the tilemap

[johnsbro]

I'm trying to get my tilemap to scale and I'm basically following the example here: https://github.com/pixijs/pixi-tilemap/blob/master/demo/main.js#L17

 

However, what ends up happening is the tilemap itself will scale but the frames won't.  I can't record a GIF because for some reason the screen randomly flashes white when running the PIXI app, but here are some screenshots which may be helpful:

 

[johnsbro]

Here is the after pic, it was too large for the initial post.  You can see how the top left sidewalk tile has been "scaled" up to the top left a bit, but it looks more like you have a deck of cards laid out next to each other and you push them together until they start overlapping each other.  Overall they take up less surface area, but it isn't true scaling/zooming.

 

I'm not sure what's causing this, and it happens regardless of if I'm setting the width/height or the scale.  Any ideas?

[ivan.popelyshev]

//third parameter is "true" ONLY IF YOUR TILES ARE SQUARES
	var tilemap = new PIXI.tilemap.CompositeRectTileLayer(0, [resources['atlas_image'].texture], true);

Do you use "true" there?

[johnsbro]

Yes, the third parameter is true.  These tiles are 512x512, is the size an issue?

[ivan.popelyshev]

Use "false" there please.

I need more info on your scaling method. I used "scale" there both on tilemap and parent container ("stage" in that demo).

[johnsbro]

            tilemap.width = (renderer.width + 2*tilemap._margin) * scale;
            tilemap.height = (renderer.height + 2*tilemap._margin) * scale;
            tilemap.scale.x *= scale
            tilemap.scale.y *= scale

This is what I'm trying at the moment.  I'm trying to scale the tilemap directly rather than the entire stage, but the only visible difference between `tilemap.scale.x *= scale` and `stage.scale.x *= scale` is that when I scale the stage I'm left with the encroaching visibility frame you saw in the after pic.

 

Also, this is what I get when I use "false" instead of "true" in the tilemap:

[ivan.popelyshev]

From now on use "square=false" unless you need extra performance, "true" is using "gl.POINT" which isnt always working correctly. You didnt specify whether it helped or not

"tilemap.width" or "tilemap.height" are rpgmaker-specific properties, dont use them, because in our case they are actually changing "scale". And you change scale two lines below, so its kinda pointless

OK, i think i know the problem:

Inside the tilemap (in addRect) you have to choose coords that are 1:1 pixels of the texture. Suppose you have that code:

tilemap.addFrame("grass.png", 32, 32, 32, 32);
tilemap.addFrame("grass.png", 64, 32, 32, 32);
tilemap.addFrame("grass.png", 32, 64, 32, 32);
tilemap.addFrame("grass.png", 64, 64, 32, 32);

When you apply scale, you dont have to change those numbers.

I know that my answer isn't full, please give me more info, create a fiddle to show whats wrong there. I saw problem on screenshots but its not enough.

[johnsbro]

Sorry, I should've explained more, but I've figured out how to fix it!  Using "false" helped but then I had to change the size.  When using "true" I had to set the size as 256 otherwise there were huge gaps between the tiles, so changing it to 512 fixed the rendering issue.  In the previous pic only half of the tile was shown, which was the issue that I didn't explain.

 

I still don't quite understand what the animX and animY parameters are for in the addFrame() function.  I've tried it with and without them and I don't notice a difference - am I supposed to be using them?

[ivan.popelyshev]

Suppose we have texture coords (x,y) and anim (animX, animY), and you set "renderer.plugins.tilemap.tileAnim[]" to (framesX, framesY) , then instead of (x,y) it will be rendered at (x+animX*framesX, y+animY*framesY). That allows us to add some animations without actually clearing and re-filling tilemap. It doesn't cost anything, its just an extra param for the shader. This was made to be compatible with rpgmaker, look at the water in the demo.

[johnsbro]

That makes sense, thank you!