Closed henrygab closed 2 years ago
@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
Which would you prefer?
I've confirmed the current 64 - hour
works for all of the Fibonacci PCBs.
I should enable the clock patterns for 1628 rings, but they probably don't make any sense for kraken and chamaeleon.
Ok, I'm fine either way... just wanted to ensure it was a conscious decision, and not an accidental regression.
Note that this will change behavior for existing boards that upgrade, by effectively rotating the output 90 degrees. I'll add to the wiki.
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 0702b2664362d354b25e28da9d4d2b874aba383b, 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: