It will scale to the different resolutions but you might need to account for the physical size. A 10" tablet will have physically large buttons and will be harder to use/reach the buttons. A phone will have smaller buttons and might be hard to use too. We can use openfl.system.Capabilities.screenDPI to calculate the physical size. (maybe there's a HF var already for this?)
Also, the aspect ratios vary from almost square to extra wide screen. So with a squareish screen the vpad buttons might be better along the bottom, while on wide screen it might be better with them on the sides (landscape). 16:9 wide screen seems to be the most popular aspect ratio at this time.
I've yet to deal with all this for my game, but thought I'd share these considerations.
I'd doing a a couple of things that may be unusual.
Firstly, my games size is larger than the size I am viewing it at - FlxGame 600x1000 viewed half size. My initial zoom is -1.
Secondly I am using 2 cameras, one for the game, one for the ui, so when I start my game state I removed all the cameras, add a new game camera, then a new ui camera.
It shows up if I leave it alone but when I try to change the zoom on the game camera I either see nothing or it gives me runtime errors - I can't paste them now as I'm at work and the project is a hobby I'm doing at home.
if after you optimize the code, there is still a delay in the speed of the game then you might give the option for the user to set the speed of the game by changing its framerate. this is not a bad idea as some users might like to play the game at a slower or faster framerate than others.
Recently, a super nice youtuber willing to play my humble game stumbled upon this problem. Certain recording software can get the recording choppy, with uneven framerate, or slow to a crawl. We fixed this by adding an option to lock the game to 30 fps and enabling frameskip, with great results!
In case someone is wondering how that can be achieved, is simple:
BTW: sometimes is possible to have choppy, jumpy movement even tho you are having great performance. I can't yet understand why, but has something to do with super.update() call. For example, there might be sightly movement differences between this:
Finally My thoughts on the current state of html5.
Desktop html5 is powerful enough to be able to run most games as long as not to many effects with many sprites are being used. But the mobile performance for html5 is insanely bad and if that is something you want to support haxeflixel is not the right choice. Also with many things you will encounter with html5, importing js and using that code specific html5 libaries gives the best results in solutions with html5 specific problems so keep your eye out for those issues with browser display , showing video, saving cookies etc.
Also consider this: if the asset you're referencing with AssetPaths has been renamed or deleted, you will get a compiler error. If you reference the asset via a String path, you will only notice at runtime.
Thanks for your help ! What a great community ! :)
To show it on top, I removed and added it again. It works fine. It just seemed that it was not the right way to do it but ok.
By adding it again to the FlxMouseEventManager, it seems that I can click it correctly.
But I did it another way. I turned on the MouseChildren param so that I can trigger event on other objects overlapped by my gem. I did it since I need to be abble to trigger tooltips when the mouse is over buttons and I am draggind my gem.
I will look at all your other advice :) Thanks !
Looks like your connection to HaxeFlixel was lost, please wait while we try to reconnect.