I kind of had to upgrade to the latest OpenFL, because I had to upgrade MacOS, because iOS compilations stopped working with the latest version of Xcode available for MacOS 10.10.
After the upgrade my old code breaks because apparently openfl.display.Tilesheet disappeared. While this is not ideal because it will require spending time changing working legacy code, the worst consequence of this is that openfl-texturepacker now doesn’t work anymore.
Does anyone knows if there’s any newer libraries to open texturepacker resources that are not using Tilesheet?
Thanks, that looks interesting, and I think Texturepacker does support the Sparrow format.
Another thing I’m considering is fixing the Texturepacker importer library, but the downside to that is that it hasn’t been updated in two years, so I doubt that the original author is going to be accepting pull requests and uploading it to the haxelib repository. That failing I could still fork it and upload the fork to the haxelib repo, but then there will be confusion between which of the two the users need to use, and I’m not exactly looking forward to maintaining a library that we know it’s going to break at any moment (based on the fact that there’s still discussion around how the Tilesets API will look in OpenFL).
A separate problem is that based on the quick look I took at Tileset, using it means that I’ll end up with a bunch of Tiles, rather than Sprites. Which means that it’s now harder to isolate the code that deals with the loading of the assets. If we convert everything to Sprites, we end up with something that is part of a stable API, and that we can use safely. If we let the concept of Tiles leak into the rest of the application, we’re risking that when the same thing that happened to Tilesheet happens to Tileset, we have things breaking all around the application and dozens of places that need changing.
I forgot. It’s on haxelib https://lib.haxe.org/p/openfl-atlas/
If you want to make a custom format reader, don’t hesitate to make a pull request.
I don’t understand your concerns…
You have in one hand Tilemap which can render rectangles from an atlas. Tile is just a wrapper for 2Dtransform (positions, scale, etc.) and which rectangle of your atlas to show. So Tile replace totally Sprite here except for standard display list.
In an other hand you have openfl-atlas which can parse atlas format to create automatically all the rectangles that exist in your atlas so you don’t have to populate Tileset by yourself.
Sorry, I was not clear there. My concern about the PR was regarding the openfl-texturepacker lib, which seems abandoned.
The concern about Tile is that, in the same way as Tilesheet used to, it’s not part of the standard flash API, and can therefore disappear at any point in time. In such a scenario, letting Tile leak into the rest of the application presents the danger that changes to Tile will profoundly affect the application. The same shouldn’t happen with something as fundamental to the flash API as a Sprite, so I have more confidence to use it in my code.
Indeed it’s not part of the flash API but you can look to the different renderers: FlashTilemap uses standard Flash API, GLTilemap uses OpenGL and I don’t think OpenGL will be abandoned soon. Anyway, you could even make a Tilesheet revival using drawTriangles I guess.
But if you prefer to use standard display list (which be less performant) I think you still can. You just have to parse atlas with openfl-atlas and then use copypixels to create Bitmap I guess.
I think it is. But I don’t know if Sprite is optimized as much as Tilemap. With Tilemap you can have many Tiles using the same atlas in one drawCall (upload to GPU). But with Sprite, I think you will have one drawCall per Sprite but I can’t confirm because I never looked the code behind the rendering of Sprites on GL target.
That’s interesting, that would explain the need for a separate type of object then (at least until the Sprites are optimised to behave in a similar way, if possible).
So, just to confirm I understood, even though Tiles are separate objects, they’re still somehow associated with the Tilemap, and if several of them are to be rendered at the same time, they will be rendered in a single draw call?
Thanks, I’m hoping to start going a bit deeper on OpenGL in OpenFL and your replies here have been very helpful.
Yes, it’s one drawCall if you use one atlas. If you use more than one atlas at a time, it’s more complex, it depends on z-ordering and how you have distributed your graphics in your atlases, but basically it’s one drawCall for simple project.
Cool, thanks. Got it. Also found this post that helped me get some clarity on what we’ve been talking about. Here’s the link, to help people who find this thread in the future:
Just mentioning this offhand in case it helps. I haven’t made the switch from “spritesheet” library yet, which is compatible with TexturePacker. From TP you can export to easeljs format and then in the spritesheet lib use spritesheet.importers.ZoeImporter to read it. I had to modify it a little and created my own flavor to get things working exactly as I needed, but has been solid on all versions of openfl. There are a few other importer classes available for other formats.
