You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is to capture the discussion regarding which way is defaulting to "up" on each board. Specifically, as part of PR #213, "up" was defined to use 64u - hour (etc.). See commit 0702b26, file map.cpp.
However, IIRC, the original branches used different values for "up" when defining the clock's location for 3/6/9/12. The issue tracks the review of the following two functions, back to the original (per-product) branches:
As can be see, every branch calculated "up" as 255 - hour, with the exception of Fibonacci256. Only Fibonacci256 calculated it as the currently-checked-in code does (using 64u - hour). As an aside, it would likely be more correct to use 256u - hour ... casting to uint8_t to cause angle to remain in range [0..255] ... for the other products.
This leaves only one question:
Decide how to fix this, or have regressions in all boards other than Fibonacci256
The text was updated successfully, but these errors were encountered:
@jasoncoon -- I can see two simple ways to fix this.
rotate the positions / angles of Fibonacci256, so that up is at zero degrees (256u ... matching all others)
define new symbol WHICH_WAY_IS_UP for configuration, used only by Fibonacci256
I'm leaning towards the first option. It would entail the following:
A. Subtract 64 from the values stored in angles
B. Rotate values stored in both coordsX and coordsY counter-clockwise 90 degrees. Should be as simple as (untested):
* newX[i] := 255 - oldY[i]
* newY[i] := oldX
henrygab
changed the title
map.cpp - Check 90degree rotation of each device
map.cpp - Fix regression for "up" direction, as used by clocks
Dec 13, 2021
This is to capture the discussion regarding which way is defaulting to "up" on each board. Specifically, as part of PR #213, "up" was defined to use
64u - hour
(etc.). See commit 0702b26, filemap.cpp
.However, IIRC, the original branches used different values for "up" when defining the clock's location for 3/6/9/12. The issue tracks the review of the following two functions, back to the original (per-product) branches:
drawAnalogClock()
drawSpiralAnalogClock()
The branches in question are:
1628-rings
-- Map.h used255 - hour
kraken64
-- Map.h used255 - hour
parallel
-- N/A, map.h did not exist in that branchfibonacci256
-- Map.h used64 - hour
fibonacci512mini
-- Map.h used255 - hour
fibonacci128
-- Map.h used255 - hour
fibonacci64
-- Map.h used255 - hour
fibonacci32mini
-- Map.h used255 - hour
As can be see, every branch calculated "up" as
255 - hour
, with the exception ofFibonacci256
. OnlyFibonacci256
calculated it as the currently-checked-in code does (using64u - hour
). As an aside, it would likely be more correct to use256u - hour
... casting touint8_t
to cause angle to remain in range [0..255] ... for the other products.This leaves only one question:
The text was updated successfully, but these errors were encountered: