Personally I usually just go with a "DebugLog" array, which is easy to inspect at runtime, and the Chrome JavaScript console. Not great, but better than nothing for these cases when you can't use the breakpoints

— great art work, btw, I checked the links in your signature, very nice !

Unrolling the x & y you end up with :

dir.x = Player.ImagePoint.X - Gun.Pos.X

dir.y = Player.ImagePoint.Y - Gun.Pos.Y

dirLength = sqrt(dir.x^2 + dir.y^2)

v.x = dir.x / dirLength

v.y = dir.y / dirLength

Gun.pos.x = Gun.pos.x + Gun.speed*dt*v.x

Gun.pos.y = Gun.pos.y + Gun.speed*dt*v.y

— Correct, I just wrote Object.pos , but you'll need to apply this to both dimensions, x and y. That would remain true in 3d where you'd only need to add z component to your vectors as well.

But make sure you don't dissociate x and y components, you *need* a (x, y) vector when normalising what I called vector "v". If you move separately on each axis independently, you will move along a non-normalised vector, the speed non-uniform and the simulation breaks horribly.

Check the C2 maths expressions, there might be some helpers to save time with vectors, with norms, length, etc. Maybe.

Let me know if you get stuck, I'll try to put a quick capx example together !

Alternatively if that makes things even simpler for you : use a bullet behaviour on the Gun ; if the Gun is far from the destination (using an arbitrary small threshold value), enable the Bullet behaviour and every tick set it's direction toward the Player.ImagePoint. When close enough, disable. Done !

—

Thanks for the details ! It is an interesting case indeed. Having re-read the whole thing, I understand much better know. I initially missed the fact that we're lerping from the current pos for a chase-behaviour.

And no need to apologise ! I hope I didn't make you feel you had to, because I didn't mean to be hard or aggressive or anything. My apologies, instead

If you don't like the lerps, why not breakdown the computations and do something you understand and you're comfortable with ; something you can re-use and tweak in future projects, and not rely on black-voodoo-magic. Is it important that your gun catches up exactly in x frames ? If not, maybe something like :

Every tick, if the Gun.pos is far from Player.ImagePoint

compute direction dir towards the destination : dir = Player.ImagePoint - Gun.pos

compute normalised vector v towards the destination : v = dir/dir.length (so that this vector has a length of 1)

move Gun along v depending on its speed and dt : Gun.pos = Gun.pos + Gun.speed*dt*v

for good effect, add a clamp() to make sure you don't overshoot if the gun is already close to the mount point

It's a bit less fancy, but if that makes more sense to you, maybe it'll be easier to get it to work the way you want. This ensure uniform speed, but doesn't guarantee the time for the Gun to catch up with the destination.

(for people interested in this kind of problems and modelisation, a spline arc-length reparametrisation would be a good fit. Out of the context of C2 built-in behaviours, but maybe a useful plugin )

OK, 'read the article, I got the example and maths, but ... something bothers me ; the question is :

Why would we ever want to interpolate from the starting value ? (accumulating the progress made as the new starting position). I fail to see a case where that's useful

I see mainly 3 scenarios :

1. Pinning an object to an other - no interpolation involved, just static offset in the local object's frame

2. Moving between two known positions ; pos = lerp(pos1, pos2, s) , with s updated every tick based on speed (and therefore going 0 -> 1 over the course of the movement). The known positions can be static or represent other objects

3. Moving from the current position towards another position, e.g. chase or catch-up behaviour. lerp(pos0, pos1, whatever) will always give a (pos1 - pos0)-aligned vector. Just use that with : pos += (pos2 - pos)/|pos2 - pos|*speed*dt (= normalised unit-length aligned vector*speed*dt), or just let velocity_dir = (pos2 - pos) and let the discrete integration update the position

I don't see what we're trying to solve by lerp from the current pos every tick newt can you please explain what you're doing with weapon, for example, so that I can understand the desired behaviour ; I'm clearly misunderstanding the use case here

Thanks for the link, I'll check that article !

— If setting an object like a weapon to an image point of another sprite, why lerp-ing at all ?

And unless I'm missing something, lerp(x1, x2, s) with s = 26*dt doesn't make any sense ? "s" being the interpolation value, at s=0 we are at x1, at s=1 we are at x2. At a framerate of 30fps, 26*dt = ~0.87. That's a fixed position, fluctuating a bit back and forth around that position due to dt varying between frames

With this :

Set Positions to X | lerp(self.X,player.ImagePointX(1),1-0.00000000026^dt)

you end with (very small magical number)^(1/fps) ; at 30fps, that's the 30th square root of a magical number, which is another magical number

I haven't followed the full example, so I might be getting this wrong, but I fail to see the math logic between these formulas

Elliott G-Sync monitors are a novelty, and it's pushed forward by NVidia (with competitors having alternatives in the starting blocks already) ; it makes sense that they are the one promoting their new tech as differenciation factor, and it's good marketing and com to associate this with their most powerful GPU products, i.e. "our stuff is what you need for the best gaming experience". They also provide gaming rigs for shows, conferences, demos, etc. to showcase their hardware and innovations.

But for the end-user, there is virtually no difference ; g-sync monitors are not more expensive to manufacture, and lots of devices can be made compatible with just a firmware update if they already have the right controllers on-board. It's novelty, but it's definitely not exclusive to people with powerful desktop rigs and high gaming budgets. As Aphrodite said, all that it means is that we're moving more and more away from the idea of a fixed refresh rate, and learning "now" to design applications with this in mind is the only way to be ready when it will be the standard. Just like with multi-threading a decade ago when multi-core and virtualised CPUs started to become common consumer products.

newt I'm not sure what the formula refers to, but x^dt would seem fishy in any kind of discrete integration approach. But why work in pixels per second ? This couples your logic tightly to a specific type of devices ; say you run your application on a normal device, and then on a Retina display - how does it remain consistent ? I would argue that we should always work in arbitrary units (whatever fits the projects, "1 tile = 1 meter" or something like that), except for specific situations e.g. aligning a HUD to safe zones, to abstract the world representation from it's rendering.

Aphrodite The change should be almost transparent for higher-level apps like browsers ; this should be handled almost entirely at the driver level, though there will be some impact on the schedulers of multi-threading game kernels to maximise the efficiency of the frame structure (esp. pre/post-render stages and boundaries for animation/physics/rendering consistency)

I wouldn't worry too much honestly, I have seen games in development working on g-sync monitors with very little extra work.

Also this fits nicely with the philosophy of the new upcoming rendering APIs (MS/NVidia DX12, AMD Mantle, Apple Metal) which give more control of the rendering and GPU resources to the software.