A list of issues in Flixel everyone keeps complaining about, so that we actually propose fixes

flixel-big-issues.md

FlxSpriteGroup

• FlxSpriteGroup shouldn't exist, but Flixel's "easy to get into" mindset means it has to exist. So now, the class is halfway between AS3 (sprite grouping is the default) and Kha (sprite grouping is DIY)
• Issues: setting alpha to 0 is unrecoverable. MouseChildren handling subpar, especially compared to flash.display.Sprite#mouseChildren
• Potential solution: give FlxBasic/Object/Sprites a parent:FlxTypedGroup<> property and propagate that change throughout the lib
• Impact to lib: major
• Effort required: possibly a lot
• Breaking: mouseChildren behavior could be changed to match AS3's

Inheritance

• Flixel greatly relies on inheritance, which makes it difficult to use
• Issues: buttons have a health property. addons/3rd party libs can't be easily used together (FlxSpriteAniRot + FlxNapeSprite)
• Potential solution: composition instead of inheritance (like ECS)
• Impact to lib: massive
• Effort required: a ton
• Breaking: possibly no breaking changes, definite workflow changes

Improved shape drawing

• FlxSpriteUtil uses draw() and does so after every draw__() is called
• Issues: expensive to call more than one draw__() since multiple draw()s get executed
• Potential solution: queue draw__ commands per FlxSprite
• Alternate solution: call endDraw() once, in the update/render phase (user must manually call it to expect immediate effect)
• Alternate solution: implement pixel-by-pixel drawing of shapes in a new class
• Impact to lib: minor
• Effort required: not much
• Breaking: solution 2 is, others are not

Bitmap and vector text

• FlxText and FlxBitmapText are not interchangeable
• Issues: using a spritesheet bitmap font instead of a font file requires reimplementation
• Potential solution: FlxText and FlxBitmapText implement an Interface (or something along those lines)
• Alternate solution: TextField modified to accept bitmap fonts (OpenFL effort, probably won't work on Flash)
• Impact to lib: minor
• Effort required: modest
• Breaking: no

FlxReplay

• FlxReplay is not up to date with respect to the rest of Flixel
• Issues: FlxActions and FlxTouch are not recorded, bugs/unexpected behavior in normal use, middle and right mouse aren't recorded
• Potential solution: update class, add additional data to each recorded timestamp while maintaining backwards compatibility
• Impact to lib: minor
• Effort required: not much
• Breaking: doesn't have to be, but consider how little replays are used vs what could be brokenly changed

Physics

• Flixel doesn't have very robust collision detection
• Issues: anything beyond basic rectangle collisions is iffy, FlxTilemapExt can kinda handle slopes but not really, missing more advanced callback/collision filtering
• Potential solution: Separate basic and advanced collisions (or don't), make advanced use a tried-and-true method of collision detection (N-based, Sonic-based, etc-based physics), implement collision filtering and callbacks
• Alternate solution: Nape with a lot of "gamey" physics PreCallbacks and InteractionCallbacks to avoid the realistic physics (not ideal and possibly not possible, from experience)
• Impact to lib: minor
• Effort required: modest
• Breaking: no

FlxTween?

Zoom/Scale?

Don't forget all this stuff
http://www.metanetsoftware.com/technique/tutorialB.html#section2
specifically sloped tiles

Don't forget all this stuff
http://www.metanetsoftware.com/technique/tutorialB.html#section2
specifically sloped tiles

And my axe!

I mean, here's an article on how classic Sonic did it, which may or may not be helpful but always is sorta the model I figured was the best we could hope for.

http://info.sonicretro.org/SPG:Solid_Tiles