Just playing around with all this cost a lot of time and does not give any real solution. I can probably just scrap neko and debug from this list because they are performing worse then cpp and release anyways and wont be used in the end product. But still leaves enough variables for testing.
The last thing I can think off is to substitute tweens for normal x, y animations. But then again if I load a map with hardly any tweens other then those of the character the problem still remains. Also the Tweens just manipulate the properties you specify. Even if I would write very optimized code for translations instead of the generalized tweens, then still I'm basically doing the same things and with that probably can assume the same results.
This seems to work best and not being a very big change. Previously my updateFramerate was set to 120 because I sometimes on some maps can have a lot of physics and i thought setting updateFramerate higher would give less lag. But it seems to be doing the opposite.
If anyone still has some great advice or recommended reading on this topic. Them by all means please share.
It looks like my only issue was the FlxG.inWorldBounds() check after setting FlxG.worldBounds.set() to 0. After making my own worldBounds var and inWorldBounds() function I was able to replace the FlxG.worldBounds/inWorldBounds() with my own. Now I don't have double overlaps. Thank you!
So far, I haven't noticed any lag or frame rate drop.
Thank you for the insight. Since the new OpenFL removed legacy it seems to be most effective to try and use -Dnext. Because thats seems to be the future anyways. And I am building this project from scratch, so if there are any issues with -Dnext suppose to Legacy I ratter try and deal with them right away then be forced to do so later.
-Dnext seem to be working fine but sometimes on Android or Windows the build process fails. At this moment I have no log statement, but i belief it was the linker that failed. Other then that I have not experienced any real problems. If i see the build problem happen again i will save the log and post it.
I already found oud yesterday that the FlxTimer will not solve this. Just thought I would sleep over it before reacting. As soon as the function called by Thread.create(); ends, then the thread ends. Which is kind of normal behavior and the reason for using an endless loop to keep it going. The callback on the FlxTimer does not run in its own thread. Its just the main thread.
Now, adding a sys.sleep(0.1) to the while loop will make it more stable. But I still found some minor issues with it when clicking on and off the game. There are cases when you do that alot then the thread dies. Which does not make me confident enough to use it!
Some other critic I have on the threads is debugging them. Normally when you have an access violation (accessing a null pointer) the game crashes and you get a very decent execution trace which will give you a good idea where it all went wrong. Threads do not do this. They just complain and die on you. You have to figure out for yourself where it all goes wrong. If you have a big piece of code, this can be very irritating. The main thread of the game also just keeps running. So, if you don't keep an eye on the log, you wont even know its dead until you see some weird behavior in your game.
I'm going to solve this by getting rid of the heavy-duty parts of the code and keep the AI less smart. I've tested this yesterday and this will work, even on my slowest test device Samsung Galaxy s2. This is more a pragmatic solution. I would still enjoy a technical one because I might need to thread later in this or any other project.
For now i'm pretty done with it though! Its frustrating me too much and taking up too much time.
Some last and unmentioned thoughts on this would definitely also be performance. VSTi's can be pretty heavy-duty. Expensive on both ram and CPU. If you have just one simple Synth you probably are still okay... But if you want a complete setup with lots of cool stuff you just might not get it running on say an old/cheap Android with 512mb of ram. Actual music studios use server blades to run their DAW's on. (usually Pro Tools). An other problem in the VSTi scene is bugs. Its al written in unmanaged C/C++. So expect some memory leaks here and there and access violations. The new Cubase release 9 has a sentinel that detects and blacklist these kind of things because their helpdesk/forum is full of sad stories about VSTi's misbehaving and making Cubase unstable.
And also, AFAIK Flash does also not support threads which can also be a potential problem. So even if you find a AS3/Haxe synth you might not get it working in Flash builds while HaxeFlixel - and your game - is running. Because then you probably going to need a separate thread for it because of all the CPU time.
Finally after looking at your provided link https://github.com/OIIOIIOI/hxmidilib I can assure you that this library has no instruments with it. Its a nice and small framework that can be used to play midi files in events loops. For example it can give you a callback on every beat. Which can be used for music because on every callback you can play a mp3/ogg -file, but can also be used for other applications. It will not fully accommodate you desired application though. This will only work with (2) of my previous post.
Good luck with your game!
Here's some inspiration to get you going on the music for your game. Its 8bit synths + heavy metal guitar & drum. You just might have heard it somewhere... And its actually from a game-soundtrack! || For some odd reason I thought it would appreciated for this post :D
# Machinae Supramacy :: Death From Above
This will get you started in easy-mode!. Also, if you ever need to provide a path, you can best use forward slashes, including for windows paths. "c:/some/path/"; It will save you the escape \\ hassle!