Direction facing left-right bouncing

[msbit]

When calculating the player velocity, per update, we have:

https://github.com/stewartmatheson/projectx/blob/b47569d61c16974b0863a612623fdbd999ef722d/src/PlayerController.cpp#L49-L52

which causes the speed (for a given vector) when going from stop, to movement, then back to stop, to be something like this:

0.0000000000000000000000000000000000000000000000000000000000000000
5.0000000000000000000000000000000000000000000000000000000000000000
4.9499998092651367187500000000000000000000000000000000000000000000
4.9504995346069335937500000000000000000000000000000000000000000000
4.9504947662353515625000000000000000000000000000000000000000000000
...snip...
4.9504947662353515625000000000000000000000000000000000000000000000
-0.0495049469172954559326171875000000000000000000000000000000000000
0.0004950494621880352497100830078125000000000000000000000000000000
-0.0000049504947128298226743936538696289062500000000000000000000000
0.0000000495049476967324153520166873931884765625000000000000000000
-0.0000000004950494458810794640157837420701980590820312500000000000
0.0000000000049504944414635598803897664765827357769012451171875000
-0.0000000000000495049422462312538328887967509217560291290283203125
0.0000000000000004950494118744006976501337291551863017957657575607
-0.0000000000000000049504939863951089680169093121264722867636010051
0.0000000000000000000495049372790116754519576091481125601490020927
-0.0000000000000000000004950493707706328371537858696271004743660882
0.0000000000000000000000049504934552708387008140809645178638531693
-0.0000000000000000000000000495049322107775746332620123291094603484
0.0000000000000000000000000004950493144040559687836767110671828331
-0.0000000000000000000000000000049504930838552489257356467026725176
0.0000000000000000000000000000000495049277822671771194089463080102
-0.0000000000000000000000000000000004950492521087328469565502262640
0.0000000000000000000000000000000000049504925067380321948793754564
-0.0000000000000000000000000000000000000495049264126268477006181427
0.0000000000000000000000000000000000000004950493201782070499988643
-0.0000000000000000000000000000000000000000049507874744595787115735
0.0000000000000000000000000000000000000000000490454462513685974823
-0.0000000000000000000000000000000000000000000000000000000000000000
0.0000000000000000000000000000000000000000000000000000000000000000

In combination with:

https://github.com/stewartmatheson/projectx/blob/b47569d61c16974b0863a612623fdbd999ef722d/src/Entity.cpp#L26-L32

it causes the Entity's facing_left to flip-flop each frame until it settles back to 0, which is visible when drawing.

Is it worth going back to something simpler like:

auto new_velocity = sf::Vector2f(
    current_input.x * speed * acceleration,
    current_input.y * speed * acceleration
);

?

[stewartmatheson]

yep +1. I figure that controller code might get re-written when introducing game pad support which I'm keen to do sooner rather than later.

[msbit]

Yep makes sense.

What I've seen in simple game engines is to have:

• acceleration
• damping
• velocity
• position

and on each engine update:

• zero acceleration
• check inputs and update acceleration
• apply acceleration to velocity
• apply damping to velocity
• clamp velocity between valid values
• apply velocity to position

I've put together a quick example here.

[stewartmatheson]

Check out

https://github.com/stewartmatheson/projectx/commit/fafa4331d7f78efeb1f2a32a51eb97d754f2a8c5

Working a lot better now. Still does not feel quite right but the system is much more solid. Based on your example code which was a huge help :D. Have not done the clamping yet though.

[msbit]

Looks good!