@Vortelio, after reading your post, I’ve actually decided to test one of my games, I’m transferring from Flash/AIR to OpenFL.
Both Android and HTML5 versions are working much slower than Adobe AIR/Flash versions.
Unfortunately, I can’t compare with previous versions of OpenFL.
I was quite excited to try these settings, but none of them seem to be have any significant impact on the render performance on my HTML5 mobile game (which uses about 100 tilemaps)
Yes I need them, because I have many UI elements, with several overlays and parenting stuff.
I already use texture atlases when possible, e.g. when all elements in a given overlay can share the same tilemap.
I would really like to update my game to the latest version of openfl. But I cannot do this, as these people. I see a lot of topics on this forum where people use the legacy version. The more developers move to the new version, the better for openfl.
My game is made for people with low incomes, and it is popular in their respective countries, where the whole family has one weak Android device.And I cannot allow the game to stop working for so many people.
I wonder If this could be a frame update timing issue rather than some inherent performance problem?
There was / is a similar problem in Android + OpenFL Legacy (<= v3.6.1). With Legacy, If you have vsync enabled and set the frame rate to 61fps you get nice smooth performance, 60fps is choppy.
So try upping the frame rate (with vsync enabled) and see If things improve, If not then It It’s probably a GC issue. You could use hxScout and see If GC sweeps tally with the frame drops.
Revealed another pattern. Abnormal behavior is observed on all low performance devices with 1GB ram. There is no anomaly on the low performance device with 2GB ram.
Everything is much easier.
Plain code without Tilemap drops fps to 38:
package;
import openfl.display.Sprite;
import openfl.display.BitmapData;
import openfl.display.Bitmap;
class Main extends Sprite {
private var bitmap : Bitmap;
public function new () {
super ();
bitmap = new Bitmap (new BitmapData ( stage.stageWidth, stage.stageHeight, true, 0xFF00FFFF ) );
addChild ( bitmap );
addChild ( new openfl.display.FPS() );
}
}
In the openfl legacy, on the same device, I had 2-3 such backgrounds and many Tilesheet sprites at 60 fps.
From 27 to 31 FPS. Very ragged frametime with very simple graphics. OpenFL Legacy can draw a more complex picture with 60 FPS on the same device.
Is it a dead end?
I’m not sure if this is related, but I had to fix low performance and even crashes after few hours of gameplay for a port of my game for the Switch, it’s made with openfl/Starling/Haxe & lime-switch (private repo)
I found an issue with the latest Lime, including SDL.
Here is how I fixed it for windows and Switch as it seems to be active on both.
Search for the file SDL_spinlock.c in you Lime library.
Change SDL_AtomicLock function to simply this
SDL_AtomicLock(SDL_SpinLock *lock)
{
SDL_AtomicTryLock(lock);
}
I don’t think it will work for all of you, but it’s an easy fix and worked for me.
You probably have to do this in console after the change
Lime rebuild windows -clean -v
Hope it helps, again I’m not sure what I’m doing, crashes point to this on Switch but it works for me.
