is anyone building a guide to upgrade from TileSheet to TileMap => OpenFL 3 to OpenFL 4?
I will soon have to upgrade our libraries to use the new Openfl/Lime versions, and I won’t have much time to experiment, so if someone had the good idea to write down some guidelines or tutorials it would be greatly appreciated, as I don’t have a clou about how to do it.
Were you using
drawTiles directly, or did you use a library such as “TileLayer”?
I am using heavily Spritesheet and BitmapFonts libraries, so I am not using those methods directly, I will have to modify them.
There are at least two forks of BitmapFont which should work with OpenFL 4.
- Mine - https://github.com/restorer/BitmapFont/tree/openfl4 - I forced RENDER_BLIT for openfl >= “4.0”
- By flowplay - https://github.com/flowplay/BitmapFont/tree/openfl4 - I don’t try this fork
@restorer , thank you! I will give them a try for sure when upgrading to Openfl 4 (Next?).
But… what about Spritesheet library?
I need to know if there is a sheet/topic/url somewhere explaining the differences between the old and the new approach to spritesheets.
Looking for the same thing. Has anyone done some work on this?
Are you porting from Tilesheet/drawTiles, or are you trying to understand Tilemap for something new?
I succeeded in porting Spritesheet library to Tiles, and created a new Tilesheet library: I think an explanation of what Tiles and Tilemaps are would be very useful, as the concept is pretty different from what (at least me) I was used to, and all the advantages/disadvantages respect to (i.e.) Spritesheets are not completely clear yet.
Tilemap is sort of like a display list. It performs quad batching, it should be pretty straightforward to use.
drawTiles was an old API that was not reliable on many platforms, but on C++ in certain use cases, gave you access to quad batch performance, which was good. Some code is designed to preserve any state for rendering. If this is the case, the upcoming
TileArray API may be useful.
The “BunnyMark” sample with OpenFL uses
Tilemap, so start there for a usage example. If you already have
drawTiles code you need to port,
FlxTilesheet in my pull request here is a useful reference (
TileArray is not available in release versions of OpenFL, but is a beta upcoming API): https://github.com/jgranick/flixel/blob/88773ca475854ab30a1edae18f6fb2c2ee40b71b/flixel/graphics/tile/FlxTilesheet.hx#L107
Happy to help answer any questions you might have
Your library is working for me.
Flowplay’s is not.
Do you have any plans updating yours to reinclude tiling support?
I modified the old BitmapFont library to use Tilemap some months ago : https://github.com/MatseFR/BitmapFont
I submitted a pull request to the original author of BitmapFont but never heard back from him.
This is, in fact, such a handy thing (considering it also utilizes Tilemap), that is should become a core part of OpenFL.
You’re welcome : glad it’s useful
I don’t know if it should become a core part of openFL but since the original author doesn’t seem active anymore I think the old BitmapFont haxelib should be updated somehow… I’m not sure what’s the way to do this, maybe @singmajesty can give directions ?
I mostly do games and plan to stick with using haxe so I will definetely maintain my version
I’d love to see bitmap fonts supported at the core of OpenFL, a few questions:
- Are there multiple standard formats for generating bitmap fonts?
- Would it be better to have a solution (within
TextField) that is strictly non-Flash, or to have an alternative solution (outside
TextField) that works for all targets?
- If we did introduce a new class name, what would it be called?
Embedded fonts in Flash work by embedding shape geometry (like
curveTo) for each font glyph, then rendering these as requested by the
TextField. We could pass geometry for a bitmap font in Flash (each one is a square) but we could not force Flash Player to set the fill style properly – each would be the color of the
To extend AS3 capabilities while keeping the core untouched Openfl should offer extended function by
openflPlus library, for example, that would be external to the main openfl library but strictly linked at the same time. An alternative could be
openfl-addons, like Flixel does.
The supported standard formats for bitmap fonts can be added later.
Let’s keep the original
TextField class untouched.
The new classname could be
BMPTextField or simply
BitmapTextField, to be as clear as possible.
I agree that it would be simpler to use a new class, as
TextField might have some properties incompatible with bitmap texts (like
Yes, but looks like that free bitmap font tools tend to use the “AngelCode format” - it’s either a text, XML or binary file with information for each glyph on the texture atlas.
Additionally, there are monospaced fonts, but these don’t come with any description files, as their glyphs are all of the same size.
I’m open to this idea, please feel free to join the OpenFL Discord (https://discord.gg/tDgq8EE) and chat if anyone is interested in helping implement this functionality
I’d be happy to, but I doubt I have enough knowledge of OpenFL.
If I’m able to understand how text fields work, at least in HTML5, I’ll start by contributing a fix for the non-bitmap version.
From scratch or starting from BitmapFont library?
I don’t see a license for BitmapFont, so I’m not sure.
We would need a paper trail that shows that Beeblerox is gifting it to OpenFL as part of our MIT license