Closed aether-fox closed 4 years ago
Merging #221 into Team3-dev will decrease coverage by
0.17%
. The diff coverage is18.36%
.
@@ 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 |
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)
andsetPosition(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: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:
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 indouble
. There is a little need to dumbify the accurate coordinates intoint
s. And there is the catch. When the movement vector had a very little, but importantly negative value, then thedouble
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 leastfloat
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.