Years ago I had an iriver spinn. Which was cool except that eventually I broke it. Yesterday I found one of the SWFs I’d made for it, which got me thinking about re-implementing something like it in haXe.

The interface would have to be different. I imagine something more drag-y and less spin-y. Which got me thinking about dragging in general, and drag velocity in particular.

I made a class called com.gigglingcorpse.utils.DragVelocity to manage that, and which the example above uses.

DragVelocity.start(); // The class should add its listeners

In the Event.ENTER_FRAME handler, I call:

var p:nme.geom.Point = DragVelocity.velocity; // Current value

And calculate how the ball’s velocity and coordinates should be updated.

If, for any reason, you want DragVelocity to stop, there is an aptly named and publicly exposed stop() function, which will clear its listeners.
Any further calls to DragVelocity.velocity will result in (0,0), until DragVelocity.start() is called.

Feel free to use it, if you want to!

 

Some of the things I learned today:

1. For the CPP and Neko targets, nme.filters.BlurFilter‘s blurX and blurY properties are private.
For the flash target, they are not. ¹

2. Setting the filters property of a nme.display.DisplayObject (I tried with Shape and Sprite) to [new BlurFilter( a, b )] caused it to crash on my android.

 

 

PS. You know, I just realized – maybe it should be a MouseVelocity instead of DragVelocity. That way you can just check if the mouse button is checked and it becomes the equivalent to DragVelocity.