Tilesheet to Tilemap guidelines

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.

  1. Mine - https://github.com/restorer/BitmapFont/tree/openfl4 - I forced RENDER_BLIT for openfl >= “4.0”
  2. By flowplay - https://github.com/flowplay/BitmapFont/tree/openfl4 - I don’t try this fork
1 Like

@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 :slight_smile:

Your library is working for me.
Flowplay’s is not.
Do you have any plans updating yours to reinclude tiling support?

Hi Neborya,

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. :slight_smile:

1 Like

You’re welcome : glad it’s useful :slight_smile:

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

1 Like

Hey guys

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 lineTo, 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 TextField.

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-tools & 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.

Other opinions?

I agree that it would be simpler to use a new class, as TextField might have some properties incompatible with bitmap texts (like htmlText).

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. :slight_smile:

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