I was trying to make a tilemap of size 50x50 and as soon as I created it the framerate drops to 5 frames I implemented it like the tutorial online (http://haxecoder.com/post.php?id=25) I thought it might be because of drawing so I commented the drawing part so the framerate was still slow around 20 frames and the reason because its an empty loop anyone know why is that? Its not huge loop its small one 2500 iteration is small loop and it should not drop the framerate from 30 to 20
Creating an array this size each frame must be putting to much strain on the garbage collector.
try replacing the everyFrame function with this:
private var tileData = new Array<Float>();
private function everyFrame(evt:Event):Void {
var i = 0;
for (row in 0...map.length) {
for (cell in 0...map[row].length) {
tileData[i++] = tileSize * cell;
tileData[i++] = tileSize * row;
tileData[i++] = map[row][cell];
}
}
tilesheet.drawTiles(tilesheetCanvas.graphics, tileData);
}
I really don’t know why people use garbage collection for games >.<
Regardless, Hashtables are more efficient than Array’s at larger quantities. I would suggest using a typedef versus an Array:
typedef Tile = { public var x:Float; public var y:Float; public var index:Int; };
private var tileData = new Map<Int, Tile>();
private function enterFrame(e:Event):Void
{
var iter = tileData.iterator();
while (iter.hasNext())
{
var data = iter.next();
tilesheet.drawTiles(map.graphics, [data.x, data.y, data.index]);
}
iter = null;
tileData = null;
}
In a discussion a while ago with @ibilon in another topic, OpenFL performance is not amazing by any stretch, and that is certainly something that should be touched on at some point in the future, and I would personally encourage people don’t target platforms with garbage collection since GC puts strain on overall game performance, which is very bad. 2D games MAY get away with it, but clearly it’s evident in this discussion that this is not the case.
If you want the most performances not using a garbage collector is not enough, you’d have to allocate a single block of memory and manually manage it. But that’s way less easy and anyway haxe has a garbage collector (on all of its targets).
@tienery Your example would kill performances by several order of magnitudes! A hashmap would use a huge amount of memory and is not made for iteration. (You can’t beat an array on memory size and linear iteration.) And calling such a huge amount of time drawTiles instead of once is bad. And you are gc-ing the map each frame, which is the original (probably) problem.
And gc isn’t a problem at all if you ask for memory at the beginning and release it only at the end, by reusing the data structure, like here the array.
A correction regarding what I said, it’s not that good compared to a hand written c++ gameplay code running on top of a c++ engine, but it’s good enough for games.
Performances are taken into account and are recently evaluated thanks to the amazing hxscout http://hxscout.com/haxe.html
@amidos2006 I know you said that you don’t think it’s the drawing code that’s the problem, but I am noticing that the tutorial you linked to does not call clear(), which will definitely be a problem when you start drawing again.
@tienery there is no OpenFl target without a Garbage Collector. The C++ target has a GC implementation too.
Unless I’m reading it wrong and doesn’t actually tell you if they are more efficient than arrays. Ignorance is bliss sometimes.
I guess I really can’t take OpenFL too seriously. As I was doing video tutorials for drawing sprites using the Graphics class and moving them about on Enter_Frame using delta time to determine speed, I would sometimes get the sprite jerking about slightly.
It’s funny, though, that Haxe claims that certain targets can be faster than hand-written code, such as Flash. But I don’t know, I need to shutup for anything that I am clearly not proficient enough in teaching or even consider applying in production.
They are more efficient in some cases, like lookup/search.
For example let’s take reading, both are O(1): constant, but that doesn’t mean it’s the same time for all O(1) algorithms, while array would indeed be instantaneous the hashmap needs to compute the hash.
And in the case of iterating for arrays you just move linearly in the ram, while for hashmap you move around (because of the hash) which kills perf because of cache miss (same reason why list are good from an algorithmic perspective but really bad in real life).
For flash that’s actually the case, because the haxe compiler produce better bytecode than the flash compiler.
It's funny, though, that Haxe claims that certain targets can be faster than hand-written code, such as Flash. But I don't know, I need to shutup for anything that I am clearly not proficient enough in teaching or even consider applying in production.
blitting engines like FlashPunk and Flixel on flash sometimes have better performance than openfl, I created lots of things using FlashPunk and It was always fast
First, I’ve long thought that the tiles API needed a rewrite. I am hesitant to introduce breaking changes here, but its implementation causes frustration on a number of levels. I’m not sure if we should do a new DisplayObject type, or what.
Regarding performance, I think that you can get great performance using OpenFL, but we have been in a feature phase. Some of the tempering (think beating a hot sword with a hammer, over and over) that OpenFL needs is being driven out right now.
Yeah, if you aren’t using .clear () with tiles, it’s going to die.
Also, -Dlegacy is notably faster on Neko. In my testing, desktop C++ builds are faster in the new code, with the exception of text, which is incomplete, and known to be slow at the moment
I implemented it like the tutorial online (http://haxecoder.com/post.php?id=25) I thought it might be because of drawing so I commented the drawing part so the framerate was still slow around 20 frames 
I wonder if keeping the draw commands between frame is the best default behaviour
