Fix 24 - Updating API to Flixel 3.0

[greysondn]

The title says it all, but in case it's not clear please see #24 in which this has been discussed.

This will be my branch to do this work in; there's no need to get in a hurry or anything. I just wanted to give a directly visible location for the work and a way to pull it in if I should happen to abandon it along the way. It is reasonable to expect I should have more commits for at least a few more classes updated to the current API over time as I work on my current projects.

[greysondn]

This first group of three commits updates FlxBitmapFont and returns it to working order. It has been given a basic test (via a child class) in my own work. If there's a better way to structure these commits, please do let me know. The changes are trivial this time, to say the least.

[greysondn]

This group of commits is for FlxMath. Working on requirements to get FlxButtonPlus back.

Worth noting is that photonstorm's FlxMath has a name conflict with the flixel community FlxMath. Not sure if that's a problem or not.

A test that fails to cover all the code has been performed. It at least compiles.

[greysondn]

This set of three commits is for FlxColor. Working on requirements to get FlxButtonPlus back.

The only dependency FlxColor has in Flixel-Power-Tools is on FlxMath. It's a natural choice for the next class to update.

A test that fails to cover all the code has been performed. It at least compiles.

[greysondn]

This set of commits is for FlxCollision. Working on requirements to get FlxButtonPlus back.

FlxCollision depends on FlxMath and FlxColor. Again, continuing through the classes in a natural order.

A test that fails to cover all the code has been performed. It at least compiles.

[greysondn]

This set of commits is for FlxGradient. Working on requirements to get FlxButtonPlus back.

FlxGradient depends on FlxMath and FlxColor, just like FlxCollision. I maintain this is a natural order of updating the classes.

A test that fails to cover really anything has been performed. It at least compiles. I think the test I performed - testing just one function from the class, by the way, as it is for each of these - actually passed but I have no way of confirming it. The good news is that FlxButtonPlus's default background is a gradient, so it'll show trivially and clearly if it works or not by then.

[greysondn]

These three commits give us back MouseSpring (a base type), FlxExtendedSprite, and FlxMouseControl. These were the last requirements for FlxButtonPlus to be brought more up to date.

After a long stream of three commits per class, I was forced to take these three as a group. Without bothering with the mundane dependencies, what is more interesting - and concerning - is that they're dependent upon one another. I've not examined the nature of the dependency but I know that in C++ this would be likely considered a circular dependency and marked as an architectural error upon review. Evidently AS3 can resolve them, regardless of how it is they're working, exactly.

I have tested this, basically swapping one of my classes dependent on flixel-community's FlxSprite for FlxExtendedSprite. It showed no errors that I could immediately gather. It's doubtful that this test performed complete coverage of the code, by a long shot.

In the future we should perhaps examine the circular dependency and see first if it actually needs resolved and second if we should resolve it.

[greysondn]

Finally! This latest set of three commits gives us FlxButtonPlus.

It has been tested briefly (and incompletely) and will end up used a reasonable amount, so problems with this and classes underlying it (a large stream in this commit record) may show if they exist.

I can now confirm that FlxGradient (and FlxColor) are working fine. The gradient in the background of an FlxButtonPlus looks gorgeous.

Most of this work is tedium. Compile, read errors, swap imports, rinse, lather, repeat. Initially I thought that perhaps the answer lay in doing the entirety of Flixel-Power-Tools all at once but the error readout is overwhelming and hard to trace dependencies in that way. I think doing this in a more structured way is actually reasonable and could recommend it - at this point - to people who want clear direction in porting code from flixel 2.56 (or thereabouts) to what will eventually become flixel 3.0.

[Dovyski]

Awesome, thanks for all your hard work! All changes look ok, so I think it's safe for us to merge it now to later deal with any problem if they appear.

[greysondn]

Dovyski, this isn't the full lot. I don't know if there'll be more or not.

Do you want me to resync to dev and open a new branch if I continue work?

[Dovyski]

No problems. I've merged your changes now to make some room for others willing to help with changes and testing.

Do you want me to resync to dev and open a new branch if I continue work?

Yeah, that would be great. Do you have a rough idea of how close you are to finishing it all?

[greysondn]

The whole set?

"..."

Looking through what's left, I'm most likely to still need - for my own purposes - FlxSpecialFX (and the FX subpackage), API.FlxKongregate (though it could be some time before I can actually test that one due to the way Kong handles their API requests/authent), and I've an idea that would be easier with FlxVelocity in tow. Not sure if there's a set of tweening functions hidden in here (I know a few simple tweens are either here or in Flixel itself) but those will be wanted for the same task if they're not already included in the current list.

I am willing to fast track all of those but FlxKongregate - and withhold that one only because of the feasibility of testing it. I understand the theory behind it but I've never integrated a remote API before :/ ... So that will be a new experience for me.

I had other ideas that I don't have time for this instant - a level editor for user submit levels, for example, that would be easier facilitated by FlxGridOverlay as I understand it (for snap-to-coordinates on a grid). I'm a bit more open in time constraints give or take the hospital visits until Autumn so my work should continue in general.

It wouldn't take too much to convince me to at least get all of FPT to at least compile but I can't devote time to testing much more than what I need personally (and even that testing would only be practical as opposed to an actual formal test of any sort). Ostensibly - and probably actually - updating the test-suite/demo should cover at least the codebase and general usage but under the circumstances the structure of the test suite seems a bit unwieldly for me in general. I think it's symptomatic of the design and also of how it's for a dated version of FlashDevelop as I understand it. (That, and my desire to help out upstream is complicated by my motivation to keep my own work moving.)

It may also be of interest to you an observation or two when I was tracking dependencies. There are cyclic dependencies - such as the one noted above - at times, but more interesting is something like FlxExplode (if memory serves) where there's no effective class at all. I'm not quite awake but I feel like there was a thing or two more like that which caught my eye as I skimmed over files and error messages.

I've also noted a few issues that I'm trying to track down between FPT. Flixel, and my own code that will probably work they way into at least reports. I feel that discussing them at much length before there's enough certainty as to where they stem from is a fool's errand, but just be aware that's on the way.

That's uh - I can't fathom anything else at all I could have to tell or offer you this instant as it relates to FPT. I'm open to questions if you have them and free to disclose anything you may find useful about my work as it's just me these days. (Feels nice to get that liberty as opposed to when I first tried to help out while dodging around what I was obligated to not disclose.)