@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.
yooo, Hi u all! I was enslaved with studies these two weeks,I was a little absent, but im back, will have more action from now xD ...
Buenas!! estuve ausente un tiempo, estuve con presentaciones en la facu y me consumieron la vida, pero ya estoy de nuevo, y le voy a meter mas acción al foro/Haxe. Somos muchos con haxeflixel, yo hace 2 años empecé, pero ahora estoy retomando de verdad. Y que bueno ver UTNianos aca !! :P
It's a bit more more complex, but I once made a hexagon map by looping through the map like you would if you were inserting enemy/item sprites, but instead inserted hexagon-shaped FlxSprites. The trick is, every other row, you add an offset equal to half of the tile width.