I’ve returned to openfl, after some months away, updated to the latest version which appears to be missing open.display.Tilesheet , - is this just happening to me ? or has the Tilesheet been removed ?
It has been removed in openfl 4.
@penry You may consider using openfl.display.Tilemap instead, or a custom DisplayObject with your own __renderGL method, depending on how advanced a use-case you are trying to use
1 Like
Strange that you have to go to the forums to see such a large change, and the docs dont seem to specify anything. Yet I’d assume it broke most peoples builds?
2 Likes
Hi, Thanks for the replies. I’ve had a look at Tilemap, and played a little with the newer BunnyMark sample.
Tilemap seems as deficient for the Flash target as Tilesheet was ! , it ignores all scaling and rotation of the Tile!
Tilemap also appears to be missing the ability to set the centrepoint of added rectangles ?
i.e. tileset.addrect(tilerect); , (instead of the Tilesheet Equivalent of tilesheet.addTileRect(tilerect, centerpoint); )
The ability of being able to easily position, rotate and scale, relative to a non 0,0 point was one of the most powerful abilities of Tielsheets, is it something which may be added to Tilemap later? or would i be needing to manipulate the Tile.matrix myself in order to achieve similar results (like rotating an image around its centre, which i use alot) ?
If you desperately need the Tilesheet class, I would suggest downgrading to a version that still supports it. I believe anything pre-3.6 should suffice.
But I’m going to say the same thing I said on the OpenFL Github commit tracker when I first discovered this change:
Removing a class is generally not good practice in a mature project. If I had known about this sooner, I would have suggested that you add a comment to the constructor to say the class is deprecated, as removing classes can break other peoples’ projects when they update OpenFL.
I will reiterate and say that it’s a fundamental API design flaw that can cause issues. Fortunately, this project is small enough (in terms of popularity) that not so many people rant about it, and the haxelib designed in a way that allows people to downgrade in order to be backward compatible with older projects.
That being said, I strongly disagree with that change and if anything should have been changed it should be a comment above the constructor. Something along the lines of:
/**
* This class has been deprecated. Please consider using `Tilemap` for an up-to-date solution.
*/
public function new() {
There is simply no arguing with this approach to API design.
@Penry Tile transforms should be supported, but if we have a bug, by all means, lets fix it!
There is a matrix value exposed as well for complex transforms, such as rotating by a different origin point.
@tienery We have a new GL renderer, which does not support drawTiles. This is not as simple as adding a deprecated note on an existing class, we would have had to rewrite it 
Since this is OpenFL 4, and not a minor point release, I think it is reasonable for there to be breaking changes. In this case, there are big reasons.
drawTiles has been a flawed API from the start, broken on almost all targets, and fundamentally a “promise we cannot keep” in regards to API design. It is important to let it go
Okay, that makes sense. What would make even more sense – at least to me, personally – would be keeping existing code (even if it doesn’t work with newer versions of OpenFL) and keeping it as a typedef to legacy code. At least then, when people target Flash, their Tilesheet usage will remain unchanged and working.
I think the old code could be put in a haxelib, like a standalone GLGraphics class, I can’t support this in the core, but I can’t see why that couldn’t happen – and work with OpenFL or other libraries, even. Making it GL-specific would reduce a lot of the problems that drawTiles created, and also being separate from sprite.graphics, as there would be no expectation that it would work alongside mitered gradient bezier vector graphics in the same API 
I’m not suggesting that Tilemap is a 1:1 replacement for all drawTiles use-cases, but I would love to see if we can evolve it more as a ready-to-use, easy batching API, sort of a replacement for the TileLayer approach of using drawTiles. It’s designed in a way that we can guarantee on all our renderers, and out-performs drawTiles in most tests
1 Like
I thought this might have been what happened, it seems like a good compromise. For now I’ve downgraded to unbreak some code, although I imagine I will just port to Tilemap eventually.
I have just opened a new topic with ideas of alternatives to the current Tilemap API, I would appreciate your thoughts:
So what’s the point to change class name (Tilesheet -> Tilemap) if it is anyway aimed to be an adequate substitution for the old one? Some new implementation bugs are not the same as breaking changes of all the projects that use Tilesheets, for example SpineHaxe. Lots of these libraries are obsolete and doesn’t supported, so they just turn to the pumpkins in midnight.
I will soon fix the renderer for SpriterHaxeEngine. Anyway, depending of your target, there are still some usable renderers within SpriterHaxeEngine. For SpineHaxe, I don’t know.
It’s much more than a class name change – Tilemap is a first-class DisplayObject type, with a totally different API than drawTiles. drawTiles is in a word, unsuitable, and has needed to change. We have another topic discussing the Tilemap API