i decided to break these out into new classes using what Thomas had originally submitted and building off of it. it is not as efficient as i would have wanted - i was shooting for having just one container in the UI class and then positioning the grouped elements accordingly - but it was too hard to make it all work smoothly so i went back to what Thomas had and just extended things and added the refresh system in there to keep redrawing down to a minimum. let me know if this is usable. you can test it with this test scene: https://www.dropbox.com/s/cwjxhf6s5r6qpma/MultiresolutionTest.zip
Removed dependency on lvlEnded Signal.
Added Nape Teleporter platformer object.
Merge remote-tracking branch 'upstream/master'
Bugfix: StarlingTileSystem crashed when using ATF-Images

Removed a "new"-keyword from the byteArray-definition. This keyword has
caused the StarlingTileSystem to crash when an ATF-Image is loaded as a
ByteArray.
new feature: added "tilesFromBitmap" to StarlingTileSystem

Since it can be useful to add bitmaps into the StarlingTileSystem (e.g.
when creating large images with ObjectMaker2D) I added the additional
method "tilesFromBitmap".

I've also moved most of the code from "tilesFromMovieclip" into the
second new method"tilesFromBitmapData" since it also used by
"tilesFromBitmap".

Finally I removed "pWidth" and "pHeight" since they are always equal to
"tileWidth" and "tileHeight" and removed "bitmap" and "rect" since their
content is used directly in the following line and then never again.
new feature: "updateInterval"-property in StarlingTileSystem

With this additional "updateInterval"-property it is possible to reduce
the distance for loading tiles and/or their image sizes without creating
"blank spots" which are otherwise filled too late.

This way you can tweak a better tradeoff between distance, tile size and
update interval.
Starling 1.5
Starling updated to 1.5.1
Merge pull request #201 from RazorDE/atf-fix

Bugfix: StarlingTileSystem crashed when using ATF-Images
Merge pull request #202 from RazorDE/tiles-from-bitmap

new feature: added "tilesFromBitmap" to StarlingTileSystem
Merge pull request #203 from RazorDE/update-interval

new feature: "updateInterval"-property in StarlingTileSystem
Merge pull request #200 from caroach1080/master

LevelManager Update - Remove lvlEnded Signal. Add Nape Teleporter PhysicsObject.
starling stats fixed scale
new feature: setting the fps for animations in an animation sequence individually

Currently the AnimationSequence-class assumes that the play-speed is
identical for all animations. The new method "setAnimFps" allows to set
this speed individually.

Example: You have an "idle"-animaton with two images each being
displayed for 1 second and you have a "walk"-animation with four images
each being displayed for 0.25 seconds.
Without "setAnimFps" you would have to determine the fastest animation
(in this case "walk") and then you would have add redundant images to
the other animations in order to let them appear to be playing slower
(in this case "idle").
Merge pull request #206 from RazorDE/setAnimFps

new feature: setting the fps for animations in a sequence individually
bugfix: null object reference in the set-method "oneWay"

When adding a platform object from a tmx-map then the set-method
"oneWay" of the "Plaform"-class (Nape) tries to add a prelistener and a
callback type to the body object which has not been created at this
point.

This doesn't lead to an exception because the try-catch-construction in
the "setParams"-method of the "CitrusObject" catches it. But this method
is not meant to catch this error and therefore displays a misleading
response (Warning: The parameter OneWay does not exist on [class
platform] ...).

I've changed the code such that the prelistener and callback type will
not be added if the body doesn't exist. The "createConstraint"-method
which  is called later in the process already takes care of this
instead.
Merge pull request #207 from RazorDE/fix-set-oneway

bugfix: null object reference in the set-method "oneWay"
bugfixes: AVirtualJoystick - threshold calculations, Hero - check for "duck" instead for "down"

If I understand the threshold property of AVirtualJoystick correctly it
is supposed to be set between 0 and 1. This means that the normalized
distance to the center (which is also between 0 and 1) has to be used
for comparison. But currently the pixel distance to the center is used
instead which will always be >=1 when the knob is not in the center. As
a consequence the threshold setting currently doesn't affect anything.
I've replaced the pixel distance by the normalized distance in order to
fix this.

I've also noticed that in the hero classes for Box2D and Nape the
"down"-state is used to check if the player character is ducking while
the "duck"-state is used for the animation. On the opposite side the
"jump" is used in both cases. While the "down"- and "duck"-state
basically seem do the same their initial action ranges in
AVirtualJoystick are different (same goes for "up" and "jump"). This
currently leads to an asyncronic behavior of the virtual joystick,
because you need to be at 0.8 in order to jump but only -0.3 in order to
duck.
Therefore I've changed the check from "down" to "duck" such that you
need to be -0.8 in order to duck.
Revert "bugfixes: AVirtualJoystick - threshold calculations, Hero - check for "duck" instead for "down""

This reverts commit 0d54ad3272810910dbc8a1e52e36b7b20477745d.