FlxGroup can be added to other groups/states, so update() and draw() are called on all the members of the group with exists == true. Be careful, adding to two groups can lead to update() called twice resulting in 2x simulation speed (can be solved by marking the group active = false).
Use arrays when you don't want to update/draw sprites, or they are updated/drawn from other group already.
And also, as you said, use groups when APIs demand FlxGroup, like for object recycling or collision.
It's not slightly worse, it's a lot worse. Don't measure with fps, measure with milliseconds, they tend to accumulate the more code you have, and if they accumulate more than 16 ms per frame, the player will have less than 60 fps. If you have steady 60 fps, but with steady 15 ms (draw + update), you're in trouble.
Because it would be the slowest part of rendering. My example may not be the best, because copyPixels in new versions of OpenFL is really slow anyway, so you don't want to use it unless you are ready to do some optimization work on it
Note that I'm talking about native targets, flash target is mostly unchanged AFAIK
@Gama11 How about the latest lime (5.3.0)..? If I install that then Flixel states:
Flixel is currently incompatible with Lime 3.0.0 or newer
Is there anyway we can ignore this and force a newer version of Lime instead of -3? I'm asking because i'm having some Jitter on camera follows again on a new project. Newer version of Lime just might have better SDL support and with that less Jitter. It seems to be a windows thing. I'm not seeing it on android.
There are a couple of discusion to be found with Google on this subject, but there does not seem to be a real solution.
Try making vsync to only affect cpp (if="cpp" on your project.xml in the end of the relevant line) or cancel it altogether.
Try FlxG.fixedTimestep = false; FlxG.maxElapsed = 0.25.
Sadly, If these options won't work I wouldn't be too surprised.
A thread on github, an other one on google-groups, an interesting one on OpenFL (they talk about SLD there), and a post of myself. The problem just might not be Flixel or OpenFL, the problem can lay in Lime or SDL (or the way SDL is being used). Just playing around with stuff like:
Is time consuming and not fixing anything. I would love to try out a newer version of Lime, perhaps they fixed it there? :S Is it in anyways possible that i can try this? (Development version, beta version?)
I really like HaxeFlixel and enjoy using it. But this Jitter on camera while following is driving me insane! It does not happend at the beginning of the game, but after say 10 seconds it slowly starts, after that it builds up. After 2 minutes or so its very noticeable.
@starry-abyss no worries! I actually have never released anything on HaxeFlixel with non-trivial performance requirements. I'm really grateful for the time and energy you put into explaining it to me until I finally "get it." So, thanks again.
I'll probably get a chance to work on this later tonight. I'll move my code into revive and if (for some reason) it doesn't work, I'll report back in this thread.
Yes, I remember the campaign, but if the project had more money, they could hire more people to work full time on it, run tests, improve the documentation, pay hosting costs, etc.
Well, I don't see a reason to not invest some more time improving the Patron page and I can't see how making more money wouldn't help HaxeFlixel.
It is pretty common place to extend FlxSprite for your own game's needs; for example a SpaceShip class may extend FlxSprite but could have additional variables for the game like shieldStrength or shieldPower.
Therefore, the main use-case of HaxeFlixel is inheritence-based, using the Flx* primitives as building-blocks.
For the record, I also created an ECS (actually, three) using HaxeFlixel. Ultimately, I moved away from this approach, because of a) duplication of fields across components (eg. synching the coordinates two-ways between a PositionComponent and the FlxSprite depending on if the user called move or if I'm using FlxSprite.velocity), and b) collision detection just didn't work reliably for some reason.
After moving away from using an ECS, I write less code and go faster, so I'm happy.
Looks like your connection to HaxeFlixel was lost, please wait while we try to reconnect.