How to implement overshoot on enemy arrival?

A place for people with an interest in developing new shmups.
User avatar
DyingIsFun
Posts: 35
Joined: Mon May 31, 2021 7:14 am
Contact:

How to implement overshoot on enemy arrival?

Post by DyingIsFun »

In many shmups, when enemies arrive, they accelerate onto screen, decelerate, and overshoot their position slightly, before backing up slowly to the position. This can be seen in many shmups, including those by Cave & Raizing.

I tried implementing this behavior using normal steering arrival behavior, but it was too finicky and the effect wasn't right, so I am now trying to use a decaying sine or cosine wave to encode the enemy's distance to their destination.

In particular, I am trying to create a parametrized decaying sine or cosine wave so that arriving enemies overshoot their destination slightly before returning to it, without additional oscillation.

Ideally, I'd like for the first peak of the sine or cosine wave to be the full amplitude and for it to take one additional period for the wave to decay sufficiently close to 0 (say, within some epsilon).

The ideal curve looks something like:

Image

I have looked at some articles on decaying trig waves (for example, https://en.wikipedia.org/wiki/Damping and https://www.calculushowto.com/damped-sine-wave/) and know that there's an infinite number of ways to specify decay in a parametrized curve.

For example, the equation for exponentially decaying cosine wave is the following:

Code: Select all

y(t) = amplitude * e^(-lambda * t) * cos(frequency * t + initial angle offset)
where lambda is the decay rate.

I can't seem to fathom how you'd specify that it'd decay over exactly one additional period, however.

It would also be nice to be able to specify the amplitude of the decayed peak, so that you can granularly control the overshoot distance proportional to the full amplitude. It would also be nice to be able to specify that the resolution of the overshoot happens faster than the initial period (for example takes 2 * initial period, rather than the full period).

Does anyone have any tips or tricks for implementing this kind of curve in order to approximate overshoot movement?

Are there other ways to implement overshoot and return that you've found look appealing for enemy arrival? For example, does anyone know how it was done in popular shmups by Cave or Raizing?

I know that certain Tween libraries like http://dotween.demigiant.com/documentation.php have ease types that represent overshoot, but I'd like to implement it myself for more control & flexibility.

I tried the following, gradually increasing amplitude by a certain step once the curve reaches 0 (which happens at PI/2), as well as decreasing speed once the curve reaches the nadir of -1 (which happens at PI). But the results weren't very good. The overshoot does resolve, but not in a smooth way. Rather, the enemy quickly stops when it reaches its final position.

Code: Select all

    private IEnumerator MoveAlongCurve()
    {
        // walk through curve using parametrized form, w/ parameter t
        while (t < Mathf.PI/2)
        {
            t += Time.deltaTime * speed;
            pos_on_curve.x = origin.x;
            pos_on_curve.y = origin.y + y_func(t * 2 * Mathf.PI) * amplitude;
            
            transform.position = pos_on_curve;
            yield return new WaitForEndOfFrame(); // wait for end of frame
        }

        while (t >= Mathf.PI / 2)
        {
            if (t >= Mathf.PI)
            {
                speed = 0.5f;
            }
            amplitude -= 0.25f;
            amplitude = Mathf.Clamp(amplitude, 0, float.PositiveInfinity);
            t += Time.deltaTime * speed;
            pos_on_curve.x = origin.x;
            pos_on_curve.y = origin.y + Mathf.Cos(t * 2 * Mathf.PI) * amplitude;

            transform.position = pos_on_curve;
            yield return new WaitForEndOfFrame(); // wait for end of frame
        }
    }
oab
Posts: 61
Joined: Tue Mar 19, 2019 4:14 am

Re: How to implement overshoot on enemy arrival?

Post by oab »

I use this website (https://easings.net) as example for implementing easing functions in my game.
I am making a vertical shmup game: USG

Released Flesh and miniStrike
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: How to implement overshoot on enemy arrival?

Post by trap15 »

DyingIsFun wrote:For example, does anyone know how it was done in popular shmups by Cave or Raizing?
If you have videos/clips of examples of this, it'd be easier to help.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: How to implement overshoot on enemy arrival?

Post by Sumez »

I don't have any clear answers for you, but if you're looking for how it was done in classic shooters, or even newer ones like Raizing or the older Cave titles, I don't think you're on the right track using actual trigonometry and complex mathematical functions.

These were games made by old school programmers used to simpler hardware and assembly code. Anything that does require trigonometry, like aiming and calculating a trajectory, is probably done using lookup tables.
More likely the objects just have a simple velocity value that's being subtracted slightly from on each frame (or added to, providing moving down = negative velocity), causing it to gradually slow down and eventually go in the other direction, and then stop once it hits a certain threshold. Not unlike a classic platformer jump arc.
I don't think they are designed around a "target position" for where they end up, but rather something like a timer value for how far they go before they start slowing down.

I'm just going by speculation here based on my own experiences of course, but I'm sure someone like mikejmoffitt or trap15 could probably confirm/deny.
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: How to implement overshoot on enemy arrival?

Post by trap15 »

Sumez wrote:These were games made by old school programmers used to simpler hardware and assembly code. Anything that does require trigonometry, like aiming and calculating a trajectory, is probably done using lookup tables.
More likely the objects just have a simple velocity value that's being subtracted slightly from on each frame (or added to, providing moving down = negative velocity), causing it to gradually slow down and eventually go in the other direction, and then stop once it hits a certain threshold. Not unlike a classic platformer jump arc.
I don't think they are designed around a "target position" for where they end up, but rather something like a timer value for how far they go before they start slowing down.
This is all exactly correct.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How to implement overshoot on enemy arrival?

Post by heli »

Did you know multiplying a value by itself gives exponential curve also ?
You are using floating point i see, then you keep value under 1, multiply by itself,
subtract that from one and you have your shape.
Dont ever use sin or cos in your main loop.
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How to implement overshoot on enemy arrival?

Post by heli »

There are many people saying you can use math functions inside your main loop,
they are misleading you.

They say you can use it on modern pcs easy,
true, dont you want your code to run on any computer ?
In a danmaku/barrage game you need those cycles for more in screen.
Buy a 5900+3080 to run a game that looks like dreamcast/ps2 ?, comeon.
Every cycle counts, get rid of pointers also, they waste cycles to.
User avatar
DyingIsFun
Posts: 35
Joined: Mon May 31, 2021 7:14 am
Contact:

Re: How to implement overshoot on enemy arrival?

Post by DyingIsFun »

Thanks for the comments all!

For reference, I am referring to the type of arrival behavior shown in the following.
In each clip, notice the enemy arriving in the top right. You can see how they decelerate, overshoot some position slightly, then recoil back to that position slightly before beginning their next behavior.

I managed to approximate the behavior in my prototype using the following curve https://www.desmos.com/calculator/yaptmrvc2l (with 0 < x < 4.9).
Basically, I walk through the first curve (describing the arrival), then I wait 0.75 seconds and start walking through a Bezier curve describing the subsequent movement of my enemy. The code is the following.

Code: Select all

 private IEnumerator MoveAlongCurve()
    {
        // walk through arrival curve using parametrized form, w/ parameter t
        while (t < 4.9f)
        {
            if (t > 2.76f && speed == 3f)
            {
                speed *= 2f;
            }
            t += Time.deltaTime * speed;
            pos_on_curve.x = origin.x;
            float k = 0.65f;
            float a = 1f;
            float b = 0.2f;
            float y = Mathf.Exp(-k * t) * (-a * Mathf.Cos(t) - b * Mathf.Sin(t)) + 1;
            pos_on_curve.y = origin.y - y * amplitude;
            host_controller.transform.position = pos_on_curve;
            yield return new WaitForEndOfFrame(); // wait for end of frame
        }

        yield return new WaitForSeconds(0.75f);

        // start following Bezier route component on the gameObject
        host_controller.transform.GetComponent<BezierFollow>().StartRoute(0, 0.75f);
    }
It works well enough, but I am still interested in learning other techniques. Knowing that old-school programmers likely fiddled with fine-tuning decrement steps and timers gives me some solace. I guess to get the perfect behavior just requires a ton of fine-tuning and finding appropriate values, regardless of the method you choose!
Last edited by DyingIsFun on Tue Jun 15, 2021 8:07 pm, edited 1 time in total.
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: How to implement overshoot on enemy arrival?

Post by trap15 »

Looks more to me that rather than doing an over-shoot and recoil, it's two movement "steps". The arrival movement ends at a set point, flat stop. Then it begins a "leaving the screen" movement, which begins with a negative movement to give it weight. Probably just a small "decrease speed per frame" segment, followed by a long "increase speed per frame" segment ending in whatever the maximum "leave the screen" speed is.
heli wrote:There are many people saying you can use math functions inside your main loop, they are misleading you.
[...]
get rid of pointers also, they waste cycles to.
I don't want to say you're full of shit, but you're incredibly incorrect despite making your statements as fact.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: How to implement overshoot on enemy arrival?

Post by Sumez »

Unless you're working on an old 70s or 80s CPU, there's no issue using tons of math functions in your main loop. Like, where else would you use math?
The kind of math necessary for enemy movements is a very, very minimal calculation for any common PC CPU over the past multiple decades.
Though there might still be certain caveats on relatively modern hardware - like, if you're doing something with lots and lots of bullets, there is a risk of coding yourself into a corner by sticking to certain high level OOP patterns, due to the way memory is accessed.

That said, I'd say there's still some appeal to staying clear of advanced math functions and stuff like easing functions etc. if you're replicating classic shooters. A lot of common behaviors, quirks and overall game design that we are used to is partly dictated by the hardware that classic games were designed for, so by programming them in a way that's at least somewhat respectful of those approaches will probably help creating a similar feeling. As opposed to creating what feels like a LittleBigPlanet to Dodonpachi's Super Mario Bros.
But there's also no reason to make things more cumbersome for you than necessary. No reason to create a lookup table when you can call a cosine function just as effectively. As long as you know what you're doing, there's no sensible argument for doing things the "old school" way.
User avatar
wht11
Posts: 115
Joined: Sun Apr 25, 2021 9:16 pm
Location: StageHidden

Re: How to implement overshoot on enemy arrival?

Post by wht11 »

trap15 wrote:I don't want to say you're full of shit, but you're incredibly incorrect despite making your statements as fact.
I was just passing by and could it be it's your birthday today? If so I wish you a happy birthday, if not then a happy day all the same.
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How to implement overshoot on enemy arrival?

Post by heli »

trap15 wrote:I don't want to say you're full of shit, but you're incredibly incorrect despite making your statements as fact.
Why am i incorrect ?, Have you run the tests ?
Not full of shit, so there is something good in what i say ?, what point then ?
If i use for every frame for all enemys and bullets math functions, i notice difference.
*i develop on a celeron with onboard graphics.
pieslice
Posts: 200
Joined: Sat Mar 01, 2008 12:15 pm
Location: Finland

Re: How to implement overshoot on enemy arrival?

Post by pieslice »

If you really need to resort to sort of micro-optimizations in a shmup game to get acceptable results it means that your codebase is ruined and you'd better to do at least partial rewrite.

You really should try to actually do some software engineering instead of coding and to actually design your programs in a way that they are structurally efficient.
As an example you might be able to optimize a function around 20-25% in a very lucky case (getting +100% performance boosts by optimizing means that your original implementation was bad). But with proper engineering you can for instance reduce the call count of the said function ten times less, gaining 1000% performance boost without even optimizing the function itself - after that you can still profile it further to see if it is still a bottleneck.

Also by doing the 80's style optimizations you often end up with worse results since the lookup tables and such usually trash the cpu caches - it's better to just call a sin() and store it to a local variable in a scope than to fetch a sin value from a lookup.
pieslice
Posts: 200
Joined: Sat Mar 01, 2008 12:15 pm
Location: Finland

Re: How to implement overshoot on enemy arrival?

Post by pieslice »

[quote="heli"]In a danmaku/barrage game you need those cycles for more in screen.
[/quote]

I'd suggest you stop spreading your misinformation, period.
Shmups are among the easiest games to program physics, math and collision-detection wise. Testing 3000 bullets vs a single player craft is nothing; for instance RTX you need to do tens or hundreds of thousands of raycasts (and secondary rays) against arbitraty geometry. With voxels you create a 3d mesh shell contouring thousands of individual points in space.
pieslice
Posts: 200
Joined: Sat Mar 01, 2008 12:15 pm
Location: Finland

Re: How to implement overshoot on enemy arrival?

Post by pieslice »

DyingIsFun wrote:Thanks for the comments all!

Code: Select all

 private IEnumerator MoveAlongCurve()
    {
        // walk through arrival curve using parametrized form, w/ parameter t
        while (t < 4.9f)
        {
            if (t > 2.76f && speed == 3f)
            {
                speed *= 2f;
            }
            t += Time.deltaTime * speed;
            pos_on_curve.x = origin.x;
            float k = 0.65f;
            float a = 1f;
            float b = 0.2f;
            float y = Mathf.Exp(-k * t) * (-a * Mathf.Cos(t) - b * Mathf.Sin(t)) + 1;
            pos_on_curve.y = origin.y - y * amplitude;
            host_controller.transform.position = pos_on_curve;
            yield return new WaitForEndOfFrame(); // wait for end of frame
        }

        yield return new WaitForSeconds(0.75f);

        // start following Bezier route component on the gameObject
        host_controller.transform.GetComponent<BezierFollow>().StartRoute(0, 0.75f);
    }
Suggestion: If you are doing unity, do not use Coroutines (each coroutine creates heap which will eventually trigger Gc and cause a frame-rate stall) and sync everything to FixedUpdate(), otherwise you'll create framerate-dependent physics and that will end up in problems. Also AnimationCurves are your friends.

You could also use the Physics2D (box2d) directly to control the objects, it's faster to manipulate rigid bodies than transforms; with the physics you can also use velocities to move objects around instead of explicitly replacing the object if you feel more comfortable with that approach.

If you have colliders in transforms without rigid bodies they are considered to be static physics-wise; moving a static collider will re-calculate the search tree data structures in the engine level which is slow; adding a rigid body to a collider hints the unity engine to treat the object as dynamic so it won't be included to the static collision structure at all.
User avatar
DyingIsFun
Posts: 35
Joined: Mon May 31, 2021 7:14 am
Contact:

Re: How to implement overshoot on enemy arrival?

Post by DyingIsFun »

pieslice wrote:Suggestion: If you are doing unity, do not use Coroutines (each coroutine creates heap which will eventually trigger Gc and cause a frame-rate stall) and sync everything to FixedUpdate(), otherwise you'll create framerate-dependent physics and that will end up in problems. Also AnimationCurves are your friends.

You could also use the Physics2D (box2d) directly to control the objects, it's faster to manipulate rigid bodies than transforms; with the physics you can also use velocities to move objects around instead of explicitly replacing the object if you feel more comfortable with that approach.

If you have colliders in transforms without rigid bodies they are considered to be static physics-wise; moving a static collider will re-calculate the search tree data structures in the engine level which is slow; adding a rigid body to a collider hints the unity engine to treat the object as dynamic so it won't be included to the static collision structure at all.
Thanks for the advice pieslice! I am using Unity, and will try to stay wary of coroutines. I don't have any colliders on my objects—I do collision detection manually. If I experience any performance issues, I will experiment with using native Unity physics.
User avatar
9uile
Posts: 50
Joined: Mon Jan 13, 2020 4:57 pm

Re: How to implement overshoot on enemy arrival?

Post by 9uile »

DyingIsFun wrote:I don't have any colliders on my objects—I do collision detection manually.
How did you check collisions without colliders ? I'm curious about the way to do that :)
User avatar
9uile
Posts: 50
Joined: Mon Jan 13, 2020 4:57 pm

Re: How to implement overshoot on enemy arrival?

Post by 9uile »

Sumez wrote: But there's also no reason to make things more cumbersome for you than necessary. No reason to create a lookup table when you can call a cosine function just as effectively. As long as you know what you're doing, there's no sensible argument for doing things the "old school" way.
I'm agree with you but as a beginner coder, i'm also interested by the 'old school' or accurate way to do basics shmups stuff.
I think that online tutorials aren't so valueable than proven codes.
My actual thoughts are that it's possible to do a lot of things in Internet era but we are missing some mentors.
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: How to implement overshoot on enemy arrival?

Post by Sumez »

Yeah, I don't want to come across too much of a dinosaur, and personally all video game programming I've done over the past 5 years have been on NES or SNES, so I'm absurdly biased in that regard - but I really do think there's merit to doing things "the old school way" in order to get the right feel for the game.
Relying too heavily on stuff like Unity's built in physics routines and colliders, etc. to create half the game for you, can very easily end up becoming very noticeable to the player if you aren't extra aware of how you use them to your advantage.

I guess, use all the tools you have at your disposal if it helps you getting to your goal faster, but don't rely on them just because they are there.
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How to implement overshoot on enemy arrival?

Post by heli »

Have you ever looked what is inside a sin cos itoa or rand function ?
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: How to implement overshoot on enemy arrival?

Post by Sumez »

Have you ever counted the number of cycles a modern x64 CPU is capable of during 1/60 of a second?
Like I think pieslice was hinting at, RAM addressing is usually a bigger bottleneck on modern systems than raw CPU speed, so stuff you might think is an optimization isn't necessarily always one.
User avatar
DyingIsFun
Posts: 35
Joined: Mon May 31, 2021 7:14 am
Contact:

Re: How to implement overshoot on enemy arrival?

Post by DyingIsFun »

9uile wrote:
DyingIsFun wrote:I don't have any colliders on my objects—I do collision detection manually.
How did you check collisions without colliders ? I'm curious about the way to do that :)
9uile, I use simple geometric checks to see if a bullet is within a certain radius or rectangular area around my player or enemy. It's pretty straightforward to determine if a point is in a circle or rectangle without full fledged physics engine :D. I actually found these simple geometric checks to be more performant for me than when I did have BoxColliders on player, bullets, and enemies (which is how I originally started my prototype).

I am unsure if I will add solid collision to my levels (for example, like that found in Guwange). If I do, I'll probably raycast each frame looking for the walls and adjust my transforms accordingly.
pieslice
Posts: 200
Joined: Sat Mar 01, 2008 12:15 pm
Location: Finland

Re: How to implement overshoot on enemy arrival?

Post by pieslice »

DyingIsFun wrote: actually found these simple geometric checks to be more performant for me than when I did have BoxColliders on player, bullets, and enemies (which is how I originally started my prototype).

I am unsure if I will add solid collision to my levels (for example, like that found in Guwange). If I do, I'll probably raycast each frame looking for the walls and adjust my transforms accordingly.
I am quite sure that the problem is not in the Colliders itself (Box2D is blazingly fast, actually) but in your scene setup. Perhaps you forgot to mark the bullets as rigidbodies etc.?
One more pro for the box2D is that you can create "Continuous" collision checks for fast moving objects - simple geometric checks have a tendency to phase through smaller colliders if the objects move fast enough.
For the walls I do really suggest you use the built-in physics collisions or roll-out some simple tile-based approach if you want to do the collision checking manually.
User avatar
DyingIsFun
Posts: 35
Joined: Mon May 31, 2021 7:14 am
Contact:

Re: How to implement overshoot on enemy arrival?

Post by DyingIsFun »

pieslice wrote:
DyingIsFun wrote: actually found these simple geometric checks to be more performant for me than when I did have BoxColliders on player, bullets, and enemies (which is how I originally started my prototype).

I am unsure if I will add solid collision to my levels (for example, like that found in Guwange). If I do, I'll probably raycast each frame looking for the walls and adjust my transforms accordingly.
I am quite sure that the problem is not in the Colliders itself (Box2D is blazingly fast, actually) but in your scene setup. Perhaps you forgot to mark the bullets as rigidbodies etc.?
One more pro for the box2D is that you can create "Continuous" collision checks for fast moving objects - simple geometric checks have a tendency to phase through smaller colliders if the objects move fast enough.
For the walls I do really suggest you use the built-in physics collisions or roll-out some simple tile-based approach if you want to do the collision checking manually.
Ah, makes sense. I will revisit this approach! Thanks again, this entire forum is amazing. Happy to have found you all :D
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: How to implement overshoot on enemy arrival?

Post by trap15 »

heli wrote:Have you ever looked what is inside a sin cos itoa or rand function ?
I have, they're quite lightweight honestly. sin and cos generally use a smoothed table lookup (a few multiplies and a lookup table), itoa is really really basic so I don't know why you included that, and rand is incredibly simple and fast (a single multiply and add in most cases, or a shift and XOR in a less common case), so I have to conclude you really don't know what you're talking about.
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How to implement overshoot on enemy arrival?

Post by heli »

Trap15, Have you looked into it and actually saw the code for itoa ?,
or have you read/heard somewhere ?
thanks
User avatar
trap15
Posts: 7835
Joined: Mon Aug 31, 2009 4:13 am
Location: 東京都杉並区
Contact:

Re: How to implement overshoot on enemy arrival?

Post by trap15 »

@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
User avatar
Sumez
Posts: 8019
Joined: Fri Feb 18, 2011 10:11 am
Location: Denmarku
Contact:

Re: How to implement overshoot on enemy arrival?

Post by Sumez »

More importantly though, what the hell is the purpose of itoa() in logic controlling video game mechanics?
Tom1970
Posts: 1
Joined: Sat Jun 19, 2021 8:41 am

Re: How to implement overshoot on enemy arrival?

Post by Tom1970 »

Hello,

I think the easiest way is an ease function, here then the EaseOutBack. Here is my funktion for GameMaker Studio, but it can also be used in other engines

Code: Select all


function easeOutBack(currentstep,startpoint,endpoint,totalsteps) {
	
	endpoint -= startpoint;
	var _s = 5; // size of overshoot (1 = low, f.e. 10 = high)

	currentstep = currentstep/totalsteps - 1;
	return endpoint * (currentstep * currentstep * ((_s + 1) * currentstep + _s) + 1) + startpoint;
	
}

and here the call (also from GameMaker Studio)

Code: Select all


Object create event:

var cy = camera_get_view_y(view_camera[0]); // get camera y position

x = room_width/2; // or any other x position
_step = 0;
_max_step = 180; // 3 sec. animation with 60 FPS
_start = cy-20; // start position outside the camera
_end = cy+300; // end position


Object step event:

if (_step <= _max_step) {
	_step++
	y = easeOutBack(_step,_start,_end,_max_step);
}

Hope someone can use it :D

Another way can also be to combine 2 ease functions, first an easeOut (or sine, quad, etc.) up to the max point, then an easeIn (or easeInOut) back to the end point, then you have a little more control.

Best regards
Thomas
User avatar
heli
Posts: 585
Joined: Fri Sep 13, 2019 3:58 pm

Re: How to implement overshoot on enemy arrival?

Post by heli »

Trap15 you did not answer my question,
@Sumez : Just for showing purposes.

There is a big modulo, it requires at least a divide instruction.
Maybe i have to tell here : divide is very slow, not recommended for use in main loop.
Just nice for you to know, look online for comparision between math functions and divide.
You using itoa in your main loop for the score ?, that it has to do with video game mechanic.
Post Reply