- Why hxbolts?
- Trying promhx
- Trying thx.promise
- Trying task
- Trying continuation
- Trying async
- Trying hext-flow
- Finally, hxbolts
Seriously, there are numerous promise / async libraries for haxe, why we need another one? In series of posts I will try to do the same task using different libraries.
Important note: I’m open to discussions on twitter or in comments here.
At first let’s find these libraries
Library must be cross platform – at least swf, js, cpp and neko. I go to the lib.haxe.org and enter “promise” into the search box:
corporationname (ooops, actually I can’t write it because of BSD license). Anyway, it is good strongly typed (using generics) promise library for java.
Introducing hxbolts! A pure-haxe and cross-platform port of “tasks” component from Bolts.
Imagine you have to delete all comments from blog while player playing in your game, mwahahaha 😈 . But server API has only 4 methods:
I was too busy at my primary work, so there is no much news. Two libraries updated:
FastIteratingStringMap is now called LinkedMap, super optimized for js target with default fallback for all other targets. Support for Haxe 3.1.3 is dropped in favor of Haxe 3.2.
Thanks to loudoweb Stage3D renderer was added for flash target (using TilesheetStage3D library). Much faster than sprites renderer – demo.
More features added to zame-haxe-particles:
- Support for embedded textures (both zipped or not)
- Sprites renderer added, which allows to use some color-effects for flash target
- Fallback to drawTiles renderer when WebGL is not available for html5 target
- Fix problem, when buttons under particle renderer was not clickable (for html5 target)
And two minor things:
Some time ago I wrote a post about an idea, how StringMap could be implemented (for js target) to have ability to iterate fast. I continued to work in this direction, and finally idea evolved into nearly final implementation.
- Tests were added;
- Special iterators implementation for case when there is no data in the map;
- Benchmark code instantiate a specific class now (instead of using creator function), to give Haxe ability to optimize map usage and inline functions;
- Haxe 3.2 (from development branch) was used to compile benchmark;
- Another idea was tested (CachingKeysStringMap);
- Constant time complexity.
Prehistory: before we come to the Haxe world, we make games for android and even release two our own on google play.
We (at zamedev) really appreciate opensource. Haxe is opensource. OpenFl and luxeengine is opensource. But even our old games (written in java) would not appear in the world without opensource.
Today we want to give something back to community, and we opensourced Gloomy Dungeons 2.
StringMap is probably most used class in Haxe (I think only Array is used more often). Probably you never use it directly, rather you use Map<String, SomeType>, which use haxe.ds.StringMap under the hood.
zame-haxe-particles updated again.
Code refactored, minor bugs fixed.
To go to the stress test click on image at top of the post (11 particle emitters, 9776 individual particles).
- Code refactored a little
- Bug with radial emitter fixed
- Support for .json format added
- Support for .pex and .lap formats added
When I need particles for one of my games, I searched a bit, and found excellent Particle Designer 2 for mac. Although this app is a little expensive (€36.99) and sometimes crashes, it allows you to create particle systems in an easy way.
Then I started looking for particle emitter, compatible with OpenFL, but all I found – it is old and abandoned projects.
I decide to create my own library.