Topics created by ashes999

@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.

Thanks!

@gcardozo that's an interesting link. The page right before that on FlxSprite answers my question:

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.

You mean, like Planetoid Pioneers?

You'd basically want to threat it like a big planet, with gravity. Not sure how this would work for other styles, but basically, everything revolves around a central object.

This approach might be a bit killer, but is better than doing screen by screen checks, or teleporting objects. In my honest opinion of course. Haxeflixel supports physics already, you could give it a try and let us know!