SzFMV2020-Tavasz / AutomatedCar-A

Working repository for the subject "Szoftverfejlesztés multinacionális vállalatoknál" @OE-NIK 2020 Spring Group A
2 stars 1 forks source link

Team3-dev <---- #212 Fix Car Sliding #221

Closed aether-fox closed 4 years ago

aether-fox commented 4 years ago

The Bug

While going in certain directions slowly, then the car clearly shifted towards one direction of the map.

The Adventure

I spent tons of time figuring out what the hell is problematic with the expressions of the movement. I printed out tons of angles and vectors, still no clue. All seems completely fine and perfect. Yet, the car was sliding, and my hair was falling out. I was staring at the movement vector and all vectors representing the movement of the car... all was quite accurate. And then in a moment a spark of doubt fired up in my mind. What if... what if all vectors and all hellish math are right? What if someone else is an evil bastard moving the car additionally besides my gold-plated lovely code? My investigation begun for the intruder to my kinematic territory. But nothing. Not a single line sets the coordinates of the AutomatedCar, except... those two methods. Those two, setPosition(IVector) and setPosition(int x, int y). I checked them. No one uses them, except my code. Not a single invocation from outside of it. So I returned to these two methods. One of them. It was the culprit. It was the hellish evil bastard, containing one of the most hidden bugs I have ever written. There was the lines of otherworldly suffer:

this.setX((int)movement.getXDiff());
this.setY((int)movement.getYDiff());

It's right there. Hiding quietly. Enjoying his short lived avenge on our bad design decisions we made on the long road we took. Do your eyes find those demons of bugfixing?

The redemption my kinematic world waited all along:

this.setX((int)round(position.getXDiff()));
this.setY((int)round(position.getYDiff()));

The Solution

The location of the car is stored as X and Y, both being integer, although the movement calculation of the car is much more refined and is calculated in double. There is a little need to dumbify the accurate coordinates into ints. And there is the catch. When the movement vector had a very little, but importantly negative value, then the double got always truncated down to the nearest integer, hence the more frame-rate the game has, the faster the car shifts towards negative values when going in certain directions.

Lesson Learned

Store map locations in games as double values or at least float in case it is not just a chess or some boardgame. Especially if the given object is moving. Please.

... and of course don't just truncate double were a whole number is required. Truncate only intentionally and consider rounding instead.

codecov[bot] commented 4 years ago

Codecov Report

Merging #221 into Team3-dev will decrease coverage by 0.17%. The diff coverage is 18.36%.

Impacted file tree graph

@@               Coverage Diff               @@
##             Team3-dev     #221      +/-   ##
===============================================
- Coverage        46.87%   46.70%   -0.18%     
- Complexity         437      442       +5     
===============================================
  Files               73       77       +4     
  Lines             2897     2925      +28     
  Branches           277      277              
===============================================
+ Hits              1358     1366       +8     
- Misses            1440     1460      +20     
  Partials            99       99              
Flag Coverage Δ Complexity Δ
#unittests 46.70% <18.36%> (-0.18%) 442.00 <6.00> (+5.00) :arrow_down:
Impacted Files Coverage Δ Complexity Δ
...ava/hu/oe/nik/szfmv/automatedcar/math/IVector.java 37.80% <0.00%> (-0.47%) 14.00 <0.00> (ø)
...u/oe/nik/szfmv/automatedcar/move/CarMoveInput.java 0.00% <0.00%> (ø) 0.00 <0.00> (?)
.../oe/nik/szfmv/automatedcar/move/CarMoveOutput.java 0.00% <0.00%> (ø) 0.00 <0.00> (?)
...e/nik/szfmv/automatedcar/sensors/ParkingRadar.java 86.04% <0.00%> (ø) 38.00 <1.00> (ø)
...ava/hu/oe/nik/szfmv/automatedcar/AutomatedCar.java 42.30% <16.66%> (+16.66%) 4.00 <0.00> (ø)
...v/automatedcar/move/CarMoveCalculatorStrategy.java 22.22% <22.22%> (ø) 2.00 <2.00> (?)
...va/hu/oe/nik/szfmv/automatedcar/move/CarMover.java 50.00% <50.00%> (ø) 1.00 <1.00> (?)
.../nik/szfmv/automatedcar/powertrain/PowerTrain.java 27.77% <100.00%> (+1.36%) 5.00 <2.00> (+1.00)
... and 2 more