gl verts only decrease if the tilemap is out off screen on the left

[rudiHammad]

Hi,
I was wondering if this is normal. In the video you can see the gl verts decreasing when the tilemap is off screen on the left side. But if it is off screen on the right side, the display stats show all the gl verts as if the tilemap is still on screen.
Is normal?

cheers.

2025-02-17.01-46-18.mp4

[rudiHammad]

Actually, I tried the cpp test again, and if I keep pushing the tilemap off screen much further to the right, it gets to a point where the gl verts also start decreasing. But you have to push much more than you do to the left.

[rh101]

This is definitely a bug. The calculation for the visible area rectangle in FastTMXLayer::draw() is the source of the problem.

I managed to get it working correctly, but I'm not sure if it is the correct fix, since I'm not familiar with that code.

If you want to test it out, then in FastTMXLayer::draw(), change this:

    if (flags != 0 || _dirty || _quadsDirty || !_cameraPositionDirty.fuzzyEquals(cam->getPosition(), _tileSet->_tileSize.x) ||
        _cameraZoomDirty != cam->getZoom())
    {
        _cameraPositionDirty = cam->getPosition();
        auto zoom            = _cameraZoomDirty = cam->getZoom();
        Vec2 s               = _director->getVisibleSize();
        const Vec2& anchor   = getAnchorPoint();
        auto rect            = Rect(cam->getPositionX() - s.width * zoom * (anchor.x == 0.0f ? 0.5f : anchor.x),
                                    cam->getPositionY() - s.height * zoom * (anchor.y == 0.0f ? 0.5f : anchor.y),
                                    s.width * zoom, s.height * zoom);

        rect.origin.x -= _tileSet->_tileSize.x;
        rect.origin.y -= _tileSet->_tileSize.y;
        rect.size.x += s.x * zoom / 2 + _tileSet->_tileSize.x * zoom;
        rect.size.y += s.y * zoom / 2 + _tileSet->_tileSize.y * zoom;

        Mat4 inv = transform;
        inv.inverse();
        rect = RectApplyTransform(rect, inv);

        updateTiles(rect);
        updateIndexBuffer();
        updatePrimitives();
        _dirty = false;
    }

to this:

    if (flags != 0 || _dirty || _quadsDirty || !_cameraPositionDirty.fuzzyEquals(cam->getPosition(), _tileSet->_tileSize.x) ||
        _cameraZoomDirty != cam->getZoom())
    {
        _cameraPositionDirty = cam->getPosition();
        auto zoom            = _cameraZoomDirty = cam->getZoom();
        Vec2 s               = _director->getVisibleSize();
        const Vec2& anchor   = getAnchorPoint();

        auto rect = Rect(cam->getPositionX() - s.width * zoom * (anchor.x == 0.0f ? 0.5f : anchor.x),
                         cam->getPositionY() - s.height * zoom * (anchor.y == 0.0f ? 0.5f : anchor.y),
                         s.width * zoom * 0.5f, s.height * zoom * 0.5f);

        rect.origin.x -= _tileSet->_tileSize.x;
        rect.origin.y -= _tileSet->_tileSize.y;
        rect.size.width += _tileSet->_tileSize.x;
        rect.size.height += _tileSet->_tileSize.y;

        Mat4 inv = transform;
        inv.inverse();
        rect = RectApplyTransform(rect, inv);

        updateTiles(rect);
        updateIndexBuffer();
        updatePrimitives();
        _dirty = false;
    }

[DelinWorks]

@rh101 I'll have a look at it,

[DelinWorks]

I can confirm that the GPU is drawing off screen vertices, 1.5 the camera size top and right, kinda odd

[DelinWorks]

it works now, the four lines I added were pointless as the rect already spans the origin and size, my bad
also everything seems to break when anchor is not 0,0 I'll try to fix it somehow

[rudiHammad]

cool, thx for having look. So besides removing those lines is there anything else? or should we just revert to the version before that commit?

[DelinWorks]

wait, I will create proper test case and PR

[rh101]

@rudiHammad Would you know why a TMX layer anchor point would ever be something other than Vec2(0, 0)? I understand the map anchor point being set, but I'm not sure I understand why a map layer would have this value changed.

[rudiHammad]

Not sure. I've never worried about anchor points in Layers or Tilemaps. I always use them as they are by default.
Maybe you have a option menu UI in a layer that you want to bring on screen when you pause the game with a rotation effect and for that you want to center the anchor point? Or maybe you are making a game where you step on something that makes the level layer rotates 90 degrees. I don't know.

[rh101]

Or maybe you are making a game where you step on something that makes the level layer rotates 90 degrees. I don't know.

Would you rotate the entire map or a specific layer though? I've never had to work with tile maps, so my knowledge is limited in that area. The reason I'm asking this is because the calculation in that method I posted above factors in the layer anchor point, not the map anchor point, and I'm just trying to figure out if that is correct. If it is correct, then the only way to verify that any fix works to the issue you posted about would require testing layers at different anchor points.

I've tested the camera zoom at different values, and it works correctly with the code above. So, the only thing left is to test out the anchor points of the layers.

[rudiHammad]

I use tilemap with layer, but I never had to rotate any of them, so I can't thing of a scenario right now.

[DelinWorks]

just for peace of mind knowing that it works, the blue lines are your hypothetical camera bounds

video_2025-02-18_01-45-14.mp4

[rh101]

Should it padded by an extra block all around, or will that not be required? And would this ever be affected by the speed of the movement?

[DelinWorks]

no not needed, it used to with the content scale factor massacre but now it works perfectly, putting the camera 1:1 with the screen instead of 0.5:1 in the video, it doesn't show any blinking or anything

[rudiHammad]

Cool. Looks good. Just in case, can you check that tiles are stable if we move in vertical or diagonal? For instance:
auto sequence = Sequence::create(MoveBy::create(5, Vec2(-1300, -600)), MoveBy::create(5, Vec2(1300, 600)), nullptr);
Or even adding a scale to the sequence
auto sequence = Sequence::create(ScaleBy::create(3, 0.7) ,MoveBy::create(5, Vec2(-1300, -600)), MoveBy::create(5, Vec2(1300, 600)), nullptr);

(I tried that removing the four lines we mentioned in my axmol and it works)

[rudiHammad]

I have updated the repo using a camera node. I never used a camera node because I didn't really understood o trusted the legacy code, that's why I usually create a Node* acting as a camera. Any way, this is me probably not using properly the node, but I commented the zoom section code because either it has not effect or simple show the screen in black depending on the factor applied. In case you want to uncomment it and check it out.

[DelinWorks]

this is a valid approach, a camera is just a view matrix, you're better off creating it and it will be good for the long run with big projects

[DelinWorks]

I made an editor called rebound editor and I needed a fixable camera system for the editor to work properly and easily with my own implementations, it made it easy to group world based objects to that camera and then render it as a render texture, the main camera displays the ui which is also a relief because the ui doesn't have to be buggy because of following the main camera around

[rudiHammad]

yeah it is valid method to create a camera. The thing is that to create a zoom using a normal Node acting as a camera (the camera being the parent of the tilemap, and sprites representing the player, enemies, etc...), we can simply scale the camera and the children follow. This should be fine, but the problem is that it could mess up some calculations like bounding boxes, etc... for instance, if you have a sprite with a width of 100, and you scale its parent to 0.5, when you check the boundingBox().size.width the sprite is still considered to be 100 because that method doesn't consider the scale transformation of the hierarchy.
Therefor you have to multiply by the parent scale, etc... which is a bit annoying.

So I was wondering if the zoom in the camera was done if a way that if would not affect the scale. I'll try to check it when I have some time.