Tiled denotes objects lined up together, next to each other, and not overlapping each other.

If it is rotated..

Would tiles line up together? Yes

Would tiles be next to each other? Yes

Would tiles overlap? No

By your rules, it is still a tilemap.

It would still be tiles, and it would be tiled. I don't understand why it wouldn't be.

This is a quote from the chipmunk thread: "when the animation frame is changed the collision shape is recreated. The only way for it to know if the collision polygons of two different frames are the same is to compare all the points, which may be slower than just recreating it. Also note changing size also causes the collision shape to recreated as well."

I don't understand why it would need a different name if it ultimately would function the same way. A map is a map- what the map is used for or how it is oriented doesn't change the fact it is a map.

It doesn't matter why someone would want to rotate a tilemap- it should be something that is possible to do because it would give more options and freedom to design a game the way you want it. I've wanted to do it various times in the past.

Also, rotating a layer with a tilemap messes up the tilemap's collision cells- the collision cells don't rotate with it.

I've wanted to rotate tilemaps as well in the past, but there aren't any good way to do it, unfortunately. And because it's difficult for people to see the benefit in doing so, because it isn't popular design choice, it probably will remain not implemented.

it may not be used often, but the fact that you can reference instances by doing: Sprite(1).x for example.. or Sprite(-1).x can come in handy sometimes.

I did a test, I still use vista

but couldn't reproduce. I use r237 and nwjs 0.15 i think, and i get these errors:

The things that bother me most about c2 are small things, like not being able to set size of layers width and height separately, or not being able to rotate tilemaps with their collisions also, or things not having expressions for properties you can set elsewhere. Also shader support is lacking- you can't make shaders that use multiple textures for reading/writing data, for example.

Also, there could be a lot of area for improvement in ways of organizing your eventsheets/events to be more readable, like color-coding groups. Also tracking where undo/redos are made would be useful. A way to see where functions are being called- basically ways to help see the flow better so you can jump between eventsheets and not get lost.

Also, families could be improved- It is often annoying if you have a variable in one family and need it in another, and have to rename the first one and then add it in the other, then go into the eventsheet and change which events use the old variable to the new one.

Sprite animation system could be improved- spritesheets for example, tiled sprites, etc.

Also, would like to see more support for in-game menu systems, as that is a very important aspect of games that engines overlook.

Also it is annoying with the export problems, yes, but I believe that will improve.

The more tools, the better I'll probably be testing a lot of them to see how they stack up against each other.

thanks for breaking it all down, — - makes things less confusing, and also more hopeful that it'll be sorted out.

Are there any downsides for a single process?

From how I understand it, a parallax of 0,0 means that the layer will not pan when the scrollx or scrolly positions change. So if an object on that layer is located at 0,0 for example, then it will always be 0,0 pixels from the top left of the viewport regardless of the scrollx,scrolly positions. If the parallax is 50,50, then if the scrollx,scrolly are at 50% (middle of the layout), then the object will appear positioned halfway from the 0,0 origin of the layout and the topleft of viewport. If parallax is 100,100, then it will be at 0,0 of the layout.