OpenFL - TileMap advices?

Hello everybody !
I’m currently asking the limit of TileMap system of OpenFl.
And whatever I read I remain a little confused between 3D, graphical card enhancement or not.
So maybe, your experience on that subject may help me to orient well my graphic stepwork on a project of mine.

Assuming I have proper files prepared to, with TileMap, I may be able to duplicate Bitmap data on a “projector”, (or several projectors) of the scene size, behind all other general display like UI, sprites and so forth…

Am I right ?

With such a presomption, I tried to visualize what role could fullfill each projector layer, for example :
• one for the grounded carot of earth.
• one for the ground vegetals,
• one for the vertical vegetals (that I may obfuscate on user mouseover by example)
• one for the UI,

…example of intended result…

For that,
• I may load external files, like textures one
• Assemblate them in TileMap
• Duplicate them on their respective projector
• May I alter one elements brightness for example, without touching another one, and tried some random effects for the corners of the scene, like blur, scale, colorize, and so forth ?!

Thanks for your time !

Tilemap runs in one of two modes:


On the Flash target, or when running a Cairo renderer (native platforms) or HTML5 canvas (on HTML5) it works in software. This is not the default on native or HTML5, which default to using OpenGL rendering.

The width and height of your Tilemap will be the size of a BitmapData-like surface. Rendering tiles works using software blitting. Square operations that do not include rotation, alpha or other special effects will perform faster.


When OpenGL is being used (default on all targets except Flash) no surface is allocated, and it is rendered directly to the screen buffer. Rotation, scale and alpha are practically no cost. The cost primarily comes from the number of draw calls made. When possible, all objects will be drawn in in the same call. There are some things that can cause additional calls:

  • Changing the source Tileset object to render from
  • Changing between different custom shader types

Adding a post-process filter (tilemap.filters) will result in rendering first to a texture, then rendering again with the filter. Some filters (like blur) require multiple passes.

Using two Tilemaps will require at least two draw calls, but that’s not unreasonable

Flash is no more a viable target.
If I could embed all that for windows/iOS with file systems/network and maybe one day android, it would be marvelous !
One step after one step.

But I’m really happy of your personal interest SingMajesty.
If I understand well :
• my primary targets are currently openGL, interfaced by OpenFL and his Tilemap system.
• all I have to do is to project where/when/which part of a TileSheet appears in his projector, with more or less compatible effect.
• but I have no need at that level, to speculate with true 3D projection, but I may whatever benefit of the hardware stimulation by loading, on the fly, files converted in bitmap and decomposated in Tilemap.

Am I still right ?

That sounds about right.

So your targets are hardware accelerated (using OpenGL) by default, but you can use Tilemap + Tileset to optimize 2D rendering without having to write 3D rendering code.

The fewer Tilesets, the fewer calls, but things should still run well even if you do need a few

Thanks a lot !
I will try that.
Regroup ground carrot and grounded vegetals.
Another one for vertical vegetals, and see what happens.
Thanks again.

A bit complex to determine which component of Visual Studio Community are needed !

Within console, I get :

openfl build windows
Creating C:/HaxeToolkit/haxe/Role/BunnyMark/Export/windows/obj/obj/msvc19-ncxp/__pch/haxe/hxcpp.pch…

Compiling group: haxe
cl.exe -Iinclude -nologo /WX- /fp:precise -DHX_WINDOWS -GR -O2(optim-std) -Zi(debug) -FdC:\HaxeToolkit\haxe\Role\BunnyMark\Export\windows\obj\obj/msvc19-ncxp/vc.pdb(debug) -Od(debug) -O2(release) -Os(optim-size) -FS -Oy- -c -EHs -GS- -arch:SSE2 -IC:/HaxeToolkit/haxe/lib/hxcpp/3,4,188/include -DHXCPP_VISIT_ALLOCS(haxe) -DHXCPP_API_LEVEL=331(haxe) -D_CRT_SECURE_NO_DEPRECATE -D_ALLOW_MSC_VER_MISMATCH -D_ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH -DHX_WIN_MAIN(main) -wd4996 … tags=[haxe,static]

  • src/lime/utils/ObjectPool.cpp [haxe,release]
  • src/lime/utils/Log.cpp [haxe,release]
  • src/lime/utils/ObjectPool_openfl_geom_Point.cpp
  • src/lime/utils/ObjectPool_openfl__internal_renderer_ShaderBuffer.cpp
  • src/lime/utils/ObjectPool_openfl__internal_TouchData.cpp
  • src/lime/utils/ObjectPool_openfl_geom_Rectangle.cpp
  • src/lime/utils/ObjectPool_openfl_geom_Matrix.cpp
  • src/lime/utils/AssetCache.cpp [haxe,release]
  • src/Main.cpp
  • src/lime/utils/ObjectPool_openfl_Vector_openfl_display_DisplayObject.cpp
  • src/ApplicationMain.cpp
    Link: ApplicationMain.exe
    LINK : l’éditeur de liens 32 bits (C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x86\link.exe) n’a pas pu effectuer d’E/S de fichier mappé en mémoire sur ‘obj\msvc19-ncxp\d2e3f31c_NativeCFFI.obj’ et va redémarrer l’édition des liens avec un éditeur de liens 64 bits pour un meilleur débit
    LINK : échec de la localisation d’un éditeur de liens 64 bits sur %PATH% ; poursuite de l’édition des liens ; passez à un éditeur de liens 64 bits
    obj\msvc19-ncxp\d2e3f31c_NativeCFFI.obj : fatal error LNK1136: fichier non valide ou endommagé

But with Haxedevelop and only debug > windows mode, I can get a personalized BunnyMark work.

And really, I have to admit.
Amazing !!! I can really see my GraphicalCard works and keep an amazing FPS !

Congratulations for the work “behind the scene”.

1 Like

If you’re getting errors like this, can you try doing a -clean build? It might help?

openfl test windows -clean

It didn’t work yesterday, but today it does.!
No more windows compilation problem.

1 Like


Before all, I am diving with an intense pleasure in your amazing tile system. Really, it rocks.
Thousands of tile, moving, colorically altered, with such an impressive FPS.
I am really amazed.

Congratulations to all the concerned and involved people.

Consequently with diving into the tile system, it corrects my former orientations, a frame generated so quickly, I was now wondering the limits that you may have experienced, and the best way to adopt it.

For example, in my minds, at long terme, I’m currently seeing an application of the tilesystem layer like a :

• Compactor of different bitmapData (loaded textures/assets) in a lonely BitmapData.
• This one is associated with a Tileset.
• The view is generated.

But at that point…

How to include a new tile elements (let’s say with mobility) at his logical Depth index (changing from coordinates), without swapping all front element, further in front ?

I was looking at the TileContainer, child of Tile (but possible container of various Tiles at the same depth index, if I understand well.

Could I swap a current Tile, with a more reactive TileContainer ?
Animate the depth between elements within that TileContainer.
The API documentation is pretty concise on that point.
And swapping back to a single Tile when that “square” is no more used ?

Or TileContainer has another use ?


You should use TileContainer if you need the extra flexibility of grouping tiles together. The rendering will be flattened, but children of a TileContainer inherit the attributes of the container as well as their own, this makes more convenient to manipulate tiles together, or can be good for logical separation.

 - tile
 - tile
 - tile container
   - tile
   - tile
 - tile

You should be able to use addTileAt to move a tile within a container (Tilemap is also an ITileContainer) at the new depth you want.

You certainly could swap out a tile for a tile container instead, and swap back, no problem with that :slight_smile:

1 Like

It sounds marvelous !
I will throw a look on that TileContainer.

1 Like

@singmajesty, does it make sense to use “static” tilemaps?
I mean, we can have some BitmapData that is representing the stage (some background image), which is never modified. Would it be faster to display it with Tilemap than with Bitmap or Sprite?

And another question. How do I crop a tile? I can see that it has rect property, but it must be something else?

Tilemap works a little differently for hardware (OpenGL, WebGL) and software (canvas, Cairo) renderers.

For hardware, 1 bitmap nearly equals 1 tilemap. That’s why Tilemap is so powerful on hardware, because combining multiple bitmaps into one draw is “nearly” free.

Software renderers use a bitmap, then blit (like bitmapData.copyPixels in Flash) onto that bitmap.

So I would say, Tilemap is inexpensive enough that I wouldn’t think you need to optimize it out to be a Bitmap instead for a single graphic, but if you’re using one Bitmap and have no need to draw two images from the same BitmapData spritesheet, switching up to Tilemap will likely give similar (if not marginally slower) performance, so I wouldn’t worry.

You crop by using Tileset.addRect (which generates a new tile ID to use), but you can also use the optional rect property per tile instead

I see, then it’s all about draw calls from the same source.

Either it’s not working, or I’m doing something wrong.

var tile:Tile = new Tile(0);
tile.rect = new Rectangle(0, 0, 250, 250);

Regardless of how I change tile.rect, I always see the full tile on the tilemap.

Oh, it looks like must be -1 for tile.rect to be used :confused:

Maybe it should be reflected in the API then :slight_smile:

Yeah, perhaps the tile.rect setter should change the ID?

And perhaps the constructor could also accept it.

Still playing a little more with Tilemap :heart_eyes:
I am discovering some strange behaviors that I can’t explain or set up right…

Is there a maximum number of tile added to a Tilemap ?
Something relevant to the graphical acceleration ?

When I refresh the tilemap with an impressive amount of tiles, the display of the tiles is broken…
Even if the addTile calls and tilemap.numTiles are increasing.

As shown in the next pictures.
I fill the visible screen display with tiles.

While I zoom away, the display cease and leave some no filled part of the tilemap…
Around the 16360th tile.

Similarly the same around tile number, even more dezoomed.


More specifically, the 16384th tiles and further are not displayed.

or 0xFFFF divided by 4…

Even if added to the tilemap.
Even if tileNum is accordingly well increased.
I will test back the bunny example.