I’m porting a schmup from Ruby+Gosu to FP to try and get my legs with it. I’m starting to implement enemy fire, and a function I can’t seem to find is moving an entity at an angle from it’s current position. Is this something I’ll need to implement myself, or is it something handled by some kind of tween? I haven’t scratched the surface on learning tweens yet.
Move an entity at an angle
You need to use trigonometry.
Here’s the most basic movement across an angle:
x += Math.cos(angle * FP.RAD) * speed * FP.elapsed;
y += Math.sin(angle * FP.RAD) * speed * FP.elapsed;
Thank you for the answer and implementation. Gosu has this implemented out of the box, so I was sort of confident it was already implemented here too and I was just failing to find it.
If you don’t like using trig and know the point you’d like to fire at, you can use a directional vector.
For an entity with position(x
, y
) to move to a point, target
, you can make a vector, get the unit vector, and use that to create a velocity vector based on a SPEED
.
// Obtain a directional vector from the entity to the target point.
var v:Point = new Point(target.x - x, target.y - y);
// Use the vector to create a speed vector for the entity.
v.normalize(SPEED);
// Now, use v to move the entity during update.
x += v.x * FP.elapsed;
y += v.y * FP.elapsed;
If you don’t like using trig and DON’T know the point you’re firing at, you can use FP.angleXY().
var v:Point = new Point();
FP.angleXY(v, angle, speed);
x += v.x * FP.elapsed;
y += v.y * FP.elapsed;
[SOLVED] How to make direction based movement?
Creating a point each frame is expensive, though. Store the point as a variable in your entity, and just modify its x and y positions.
Sure, naturally. I don’t generally optimize my example code as its main purpose is to convey a basic idea rather than to be robust.
I do know the point I’m firing at, so this approach worked great. Thanks a ton.
Is it really that expensive? Even on mobile you can allocate many many small objects like these before it becomes a problem.
I mean, yeah, it’s worth optimising if necessary, but premature optimization, root of all evil etc.
Well, creating an object is one of the most expensive operations in AS3, IIRC.
Also, premature optimisation being the root of all evil is used when you’re sacrificing code readibility in favor of speed. Just keeping a Point variable as a propierty instead of a local var isn’t really sacrificing readibility, and is actually a good practise and a good habit to acquire.
And I’d like to add that I personally think FlashPunk should sacrifice readbility in favor of speed, internally. The API should be beautiful, but the code should be fully optimised, IMHO.
It is indeed one of the most expensive operations and in this particular case you’re definitely right (I use this practice myself, and the FP class even has useful ‘scratch pad’ Matrix/Point variables you can use for stuff like this).
I personally disagree about sacrificing readability in favor of speed; I feel that FlashPunk is an open source library designed to be simple but efficient. I don’t believe it’s really a contender for ‘best performance’, nor do I think it needs to be - it’s more of a learning tool targeted at beginners and in my opinion it’s rather nice that even beginners can easily dive into the core engine code and make some mods if they like. This is a great asset to the engine as a whole and one of the reasons it actually has its own ‘niche’. If we remove that, what is there that makes FlashPunk better than, say, Genome2D? FlashPunk simply can’t compete with that kind of performance, and I don’t believe it’s worth trying.
I don’t really see that the performance of FlashPunk is much of an issue - the only bottleneck is really has is rendering (and even there that’s only really on mobile). It performs really well and is super neat, readable and consistent. If we start changing the internals to have highly optimised but also hard to understand code, I think we’d be abandoning one of the core facets of the engine.
All that said, the code is pretty optimised where it counts.
Just my opinion though.
Yeah, maybe it is. But the reason people like FlashPunk is the API, not necessarily its inner guts. I’m not sure if there could be a massive optimisation overhaul, but I think we shouldn’t pass that opportunity in favor of internal code readibility if there was the possibility.
Was re-reading this while refactoring and the FP.angleXY() fits in great to reduce some redundancy. Commendations all around!