Alright, so I noticed two behaviors that seem a little weird to me and I’m not sure if it’s the correct behavior or if they are bugs.
First, when I choose the color of an objectgroup, it allows me to set the alpha channel and I see the visible results, however, when exporting to JSON (didn’t try with TMX), the saved color contains only red, green and blue channels ("#RRGGBB" instead of “#AARRGGBB”).
The second is that for orthogonal maps, objects that have a set gid are anchored on the bottom-left corner. However, rectangular objects with no gid set are anchored to the top-left corner. Is this correct behavior? It would seem cumbersome to have to treat the two cases in separate ways (especially for collision detection and rendering) instead of anchoring all objects to the bottom-left corner, leading to a consistent behavior.
Just wanted to know if these are bugs that will be fixed or if it is intended behavior, so I know how should I go around these in my game engine. Thanks!
Right, this is wrong. Though, the problem is either that you can select an alpha value at all, or that it isn’t saved. Since layers already have a separate opacity value, do you think it makes sense to support alpha on the color as well?
Unfortunately, yes. The reason is that traditionally I used Tiled only for top-down RPG style games, where it made sense to have rectangular regions start in top-left, but have “sprite objects” be bottom-left aligned (and sort them on their y coordinate for rendering). In addition, doing it this way kept the tile rendering consistent, since on tile layers the tiles are also bottom-left aligned in their cell.
In hindsight, I’d really like for the objects to be consistent, but for compatibility reasons it’s difficult to change this. I think now I’ll have to introduce an object alignment or origin option, which would override the compatibility mode when specified.
Regarding the color, I understand the redundancy. If you do allow alpha on colors, I think the simplest solution is to alpha-composite the color alpha value and the layer opacity. This would lead to consistent color codes across the entire tool, and handle the color alpha/layer opacity in a predictable manner. I think this choice would require very little effort to implement, as I guess only a few lines in calculating the alpha for rendering and a few lines when saving the color would need to be changed. The other choice would be to not allow choosing alpha value for objectgroup color, but I’m not sure how much effort this would require to change in the editor itself. Either seems a valid solution.
Regarding the object anchor point, as far as I know, all non-tile objects (rectangles, ellipses, polygons) are anchored on the top-left corner, and all tile objects and tiles are anchored on the bottom-left corner. Maybe you could add an option on objectgroups, “objectanchor” / “objectorigin” with a default value of “top-left”, and other values for each corner (or even “center”, for isometric maps? after introducing the option, it may be extended to multiple values if needed). This option wouldn’t apply on tile-objects, to not break the existing format, but only to rectangle/ellipse/polygon objects.
Let me know when you decide which choices you make, so I can implement them in my engine in advance. Thanks!
So, I’ve just chosen to fix the saving of object layer color alpha. It is anyway not exactly the same as the layer opacity, since the color does not apply to tile objects while the opacity does.
About the inconsistency with the anchor point, this is really a tricky issue. Just look at how different actually the rectangle and tile object behave for an isometric map:
This is another area where actually I’m struggling a bit. Because maybe somebody would like to use circles or polygons are don’t lay flat on the ground, and currently for isometric maps Tiled does not support that. Other map types support it implicitly because there is no difference in the transformation.
Just to add to this, that actually I think most people who want to change the origin, want to change it for tile objects. So an option just to change it for the others isn’t very useful I think.
Thanks a lot for solving the color issue, it was a really fast fix!
Regarding the anchor origin, indeed it seemsto be more complicated than at first sight. As I can see the problem, it’s mainly how to determine the behavior of non-tile objects for the isometric case. It would be comfortable to edit, for example, collision data in simple 2D orthogonal coordinates and have the renderer project everything into an isometric view (including rectangles, polygons, ellipses). On the other hand, it is also common to want to add a non-projected rectangle or polygon. Indeed, not having an option for tile-object anchors might be troublesome, however, the bad partis that there can’t be a single uniform option for both types of objects, since they have different defaults.
The way I see things now (although there might come up a lot more things I don’t realize, this definetily has to be very well thought out before taking any decisions) is that objectgroups should have 3 more properties: tileobjectanchor, objectanchor, isometricprojection (bool). This seems to allow a great deal of customization. However, I don’t know what rendering engine you use, so implementing the last property might be as easy as manually computing a matrix, or as complicated as having to manually compute meshes and opengl calls…
Let me know if I’m still missing anything and keep me up-to-date with this issue. Thanks for the great editor and the hard work to further improve it!
