Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixed palette FX to more closely match original 1D version #4263

Merged
merged 2 commits into from
Nov 27, 2024
Merged

fixed palette FX to more closely match original 1D version #4263

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
536444f
fixed palette FX to more closely match original 1D version
DedeHai Nov 9, 2024
32dc54c
reverted rotation scale, offset only on static rotation, inverted shi…
DedeHai Nov 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions wled00/FX.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1940,7 +1940,7 @@ uint16_t mode_palette() {
using angleType = unsigned;
constexpr mathType sInt16Scale = 0x7FFF;
constexpr mathType maxAngle = 0x8000;
constexpr mathType staticRotationScale = 256;
constexpr mathType staticRotationScale = 255;
Copy link
Contributor

@TripleWhy TripleWhy Nov 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rotation scale is now exactly 180° (divide slider input by 255 instead of 256)

Mirroring does work in 2D, so I don't think it is necessary to provide an exact 180° rotation.
In any case this change breaks every other "nice" angle. With this change it is impossible to produce 90°, 45° etc.

So you are adding an additional way to achieve 1 nice angle, and for that trade in 254 angles that were nice before and become ugly now.

Also it was not possible to make it match exactly: the moving direction was inverted. The shifted rotation angle now makes it possible to choose the direction.

If that is really the underlying issue, I'd prefer inverting the shift direction.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thx for the review! really good point, did not think of that (I ran 1D tests mostly, as that is the issue addressed in this PR).

you are right, with mirroring this can be done also in 1D. So this was an unnecessary change.

constexpr mathType animatedRotationScale = 1;
constexpr int16_t (*sinFunction)(uint16_t) = &sin16;
constexpr int16_t (*cosFunction)(uint16_t) = &cos16;
Expand All @@ -1949,7 +1949,7 @@ uint16_t mode_palette() {
using wideMathType = float;
using angleType = float;
constexpr mathType sInt16Scale = 1.0f;
constexpr mathType maxAngle = M_PI / 256.0;
constexpr mathType maxAngle = M_PI / 255.0;
constexpr mathType staticRotationScale = 1.0f;
constexpr mathType animatedRotationScale = M_TWOPI / double(0xFFFF);
constexpr float (*sinFunction)(float) = &sin_t;
Expand All @@ -1961,7 +1961,7 @@ uint16_t mode_palette() {

const int inputShift = SEGMENT.speed;
const int inputSize = SEGMENT.intensity;
const int inputRotation = SEGMENT.custom1;
const int inputRotation = SEGMENT.custom1 + 128;
Copy link
Contributor

@TripleWhy TripleWhy Nov 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move the +128 into the theta computation:

  1. These lines here are meant to give the raw input values names for better readability. If you modify the values here, they lose that purpose and now themselves contribute to bad readability because the names no longer speak for their content.
  2. The offset should only be applied to static rotations, not animated rotations (where it determines the speed, not the offset).

const bool inputAnimateShift = SEGMENT.check1;
const bool inputAnimateRotation = SEGMENT.check2;
const bool inputAssumeSquare = SEGMENT.check3;
Expand All @@ -1985,7 +1985,7 @@ uint16_t mode_palette() {
// So the rectangle needs to have exactly the right size. That size depends on the rotation.
// This scale computation here only considers one dimension. You can think of it like the rectangle is always scaled so that
// the left and right most points always match the left and right side of the display.
const mathType scale = std::abs(sinTheta) + (std::abs(cosTheta) * maxYOut / maxXOut);
const mathType scale = std::abs(sinTheta) + (std::abs(cosTheta) * maxYOut / maxXOut);
// 2D simulation:
// If we are dealing with a 1D setup, we assume that each segment represents one line on a 2-dimensional display.
// The function is called once per segments, so we need to handle one line at a time.
Expand Down Expand Up @@ -2016,7 +2016,7 @@ uint16_t mode_palette() {
colorIndex = ((inputSize - 112) * colorIndex) / 16;
}
// Finally, shift the palette a bit.
const int paletteOffset = (!inputAnimateShift) ? (inputShift-128) : (((strip.now * ((inputShift >> 3) +1)) & 0xFFFF) >> 8);
const int paletteOffset = (!inputAnimateShift) ? (inputShift) : (((strip.now * ((inputShift >> 3) +1)) & 0xFFFF) >> 8);
Copy link
Contributor

@TripleWhy TripleWhy Nov 13, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed shift offset: offset is now zero at slider 0, to hit 128 on touch input devices is really hard

As mentioned, the offset was introduced by @blazoncek. I believe he didn't provide an opinion on removing it again in the previous discussion?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TripleWhy FYI I stepped down as a maintainer & developer of WLED and my decisions (past and present) may be overruled.

The original reasoning I had was that for existing/old presets (which lack new effect sliders/options) the default value for sliders/options should not interfere/clash with effect display (i.e. if c1 is unset in preset it's value should be 128 and not 0 which would be similar as if sx is missing).

Looking at the bigger picture (and certain PRs in the queue) quite a few effects are ripe for consolidation and pruning. This will inevitably break compatibility so no matter how you look at it some users will be upset.
My 2c.

colorIndex += paletteOffset;
const uint32_t color = SEGMENT.color_wheel((uint8_t)colorIndex);
if (isMatrix) {
Expand All @@ -2028,7 +2028,7 @@ uint16_t mode_palette() {
}
return FRAMETIME;
}
static const char _data_FX_MODE_PALETTE[] PROGMEM = "Palette@Shift,Size,Rotation,,,Animate Shift,Animate Rotation,Anamorphic;;!;12;c1=128,c2=128,c3=128,o1=1,o2=1,o3=0";
static const char _data_FX_MODE_PALETTE[] PROGMEM = "Palette@Shift,Size,Rotation,,,Animate Shift,Animate Rotation,Anamorphic;;!;12;ix=112,c1=0,o1=1,o2=0,o3=1";


// WLED limitation: Analog Clock overlay will NOT work when Fire2012 is active
Expand Down