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…
• 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
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.
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
Tileset to optimize 2D rendering without having to write 3D rendering code.
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.
A bit complex to determine which component of Visual Studio Community are needed !
Within console, I get :
openfl build windows
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/AssetCache.cpp [haxe,release]
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.
IT REALLY ROCKS !!!
Amazing !!! I can really see my GraphicalCard works and keep an amazing FPS !
Congratulations for the work “behind the scene”.
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.
NEW QUESTION, SAME SUBJECT.
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 container
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
It sounds marvelous !
I will throw a look on that TileContainer.
@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
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
tile.id must be
tile.rect to be used
Maybe it should be reflected in the API then
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
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.