Add "Repeat ..." properties to Image Layers

[krukai]

Introduce the boolean properties "Repeat Horizontally" and "Repeat Vertically" to Image Layers. This mirrors GamerMaker's "Horizontal Tile" and "Vertical Tile" options.
The YY plugin will export these properties accordingly. For backwards compatibility however, the respective custom properties "htiled" and "vtiled" take precedence over the built-in ones.

I am currently still tinkering with the drawing to actually behave as described in the commit message. I may also have to touch the changes for the bounds again. There is also some room for more consistency I still want to tackle.
Finally, I am planning to move these two new properties above "Offset X", if that feels right to you as well.

Until then, feel free to review the rest. I hope I did not overlook anything serious; I only started working with the source code yesterday.

Cheers!

[bjorn]

Thanks for working on this feature! I did no testing yet, but left some comments on the changes. :-)

[krukai]

I resolved most of the review comments.
Originally, I wanted to move the properties above Offset X and Y because that would feel natural for Image Layers, IMHO. However, that would require to insert properties into the overall layer group of properties. I am not sure if we want to do that.

I also still have to tinker with the actual drawing. It works fine until offsets are set, but then the drawing rectangle would have to be adjusted to fill the space created by the offset within the overall bounds. I am not entirely sure yet where to make the adjustments, but I will look into it further.

[bjorn]

Originally, I wanted to move the properties above Offset X and Y because that would feel natural for Image Layers, IMHO. However, that would require to insert properties into the overall layer group of properties. I am not sure if we want to do that.

In the end the attribute order does not matter in XML, and I think it's fine to have the repeat attributes follow after the parallax ones.

I also still have to tinker with the actual drawing. It works fine until offsets are set, but then the drawing rectangle would have to be adjusted to fill the space created by the offset within the overall bounds. I am not entirely sure yet where to make the adjustments, but I will look into it further.

Yes, to handle the offset you'd need to call QBrush::setTransform with a transform created with QTransform::fromTranslate.

[bjorn]

Ah, handling the offset will be a little more complicated, because currently that's done by simply moving the ImageLayerItem around.

Hmm, is it really important that when repetition is used, the layer is clipped to the map boundaries? It's rather inconsistent with the way image layers have worked so far, and actually nothing else is clipped to the map boundaries. If it would be alright if the layer expands beyond the map boundaries then we'd just need to increase the bounding rect of the ImageLayerItem to be practically infinite.

[krukai]

In the end the attribute order does not matter in XML, and I think it's fine to have the repeat attributes follow after the parallax ones

I was referring to the properties panel. My bad.

Hmm, is it really important that when repetition is used, the layer is clipped to the map boundaries? It's rather inconsistent with the way image layers have worked so far, and actually nothing else is clipped to the map boundaries. If it would be alright if the layer expands beyond the map boundaries then we'd just need to increase the bounding rect of the ImageLayerItem to be practically infinite.

Would infinity actually be acceptable here or would that screw with other features relying on the bounds?

While I see your point, I would prefer if it was cut off at the overall bounds at least optionally, assuming we would not have to jump through too many hoops to achieve that. Otherwise, the overall view would get extremely noisy and it might be difficult to see at a glance where the actual level bounds begin.
But I realize while typing this that arguing for allowing an inconsistency here is pretty close to arguing for a "show me what the player would see" mode, which would include cutting off images with an offset but no repetition as well. This would also help when fiddling with parallax parameters.
So perhaps this would be a feature on its own and not within scope here.

[bjorn]

Otherwise, the overall view would get extremely noisy and it might be difficult to see at a glance where the actual level bounds begin.

Right, I think visualizing the map boundaries more effectively is a different problem. Maybe darkening the area outside of the map would help, for example.

But I realize while typing this that arguing for allowing an inconsistency here is pretty close to arguing for a "show me what the player would see" mode, which would include cutting off images with an offset but no repetition as well. This would also help when fiddling with parallax parameters.
So perhaps this would be a feature on its own and not within scope here.

Yeah, this really sounds like issue #2962.

Btw, another option to consider, is to add a repetition mode to tile objects. They already have a size that would naturally be used to clip the repetition. Generally image layers are mostly an inferior version of the tile objects, with their only advantage being (at least until this PR) that you did not have to first add the image to a tileset.

[krukai]

Added scripting support (I hope). Everything should work as expected with "infinite" repeating now, I hope.

I also refactored the Use the same pattern as ChangeImageLayerProperties as requested, albeit in a separate commit. I am also leaving renaming the class to singular to another commit as otherwise the diff would not be very useful. If you want to squash any of that, please let me know.

That being said, is there anything else to take care of? Do my changes warrant modifying some header comment or anything?

[bjorn]

I found some minor issues and a bug that need addressing, but I think this will be the last review! :-)

[krukai]

I implemented all review comments, updated the documentation, and added support for JSON and Lua export.
Please just squash everything into one commit; I just kept the latter commits separate for easier reviewing and at this point, I do not think it makes much sense to separate anything into individual commits.

If there is anything else, let me know!

[bjorn]

@krukai Thanks a lot for implementing this very welcome feature!

[krukai]

Thank you! My bad for missing the changed filename in the comments.