I2CToFastLEDRefactor branch compare #97
No reviewers
Labels
No labels
Core
Fixed
Godot
HardwareIssue
LEDS
Networking
Problem
SoftwareIssue
duplicate
enhancement
good first issue
help wanted
invalid
on hold
question
reminder
todo 🗒️
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
squatnet/ArduinoStuff!97
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "FastLEDKikiCheck"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@ -729,0 +858,4 @@downReversed = 0;}if (posDown == 0) {downReversed = 1;localised version of gHue as not required by other patterns
when palette mode 1, stores the number of the palette to use, this iterates each LED and cycles 0-256 see lines 697-703,
@ -729,0 +858,4 @@downReversed = 0;}if (posDown == 0) {downReversed = 1;cool, seems fine to me
@ -729,0 +858,4 @@downReversed = 0;}if (posDown == 0) {downReversed = 1;Ah. I remember now why gHue is global, it's being incremental in loop. Probably better to keep it like so as if its instantiated locally it will be reset each time the function is called
will it not as its set to static? that was the idea anyway :) just iterate it when pattern thats using it is called?
If its local to the pattern it is destroyed each time the pattern is called
so will always be 0
On Thu, 30 May 2019, 10:15 kieran-boyle, notifications@github.com wrote:
am i missing something here?
Duh no it's me I completely missed the static bit. Its early. Does that
mean it can be incremented from outside of its functions. IE gHue++ is in
loop.
I'll be honest I haven't really bothered with static yet as didnt really
see the point outside of a class. Theres no memory saving having it local
or global if you are keeping it alive with static. So yeah seems fine to me
as long as we dont decide to use gHue in another pattern in future I guess.
On Thu, 30 May 2019, 10:26 kieran-boyle, notifications@github.com wrote:
No worries. It should only be incremented inside of the function. Idea was to pull as much or if loop as possible and have all variables be self contained to the functions that require them (where possible at least) just trying to build up good practice. If course
Lol sorry hit wrong button with fat thumbs. As I was saying, of course if multiple functions need a variable we are better of keeping it global, but I don't think it will be the case with this one.
Aye fair enough.
On Thu, 30 May 2019, 10:44 kieran-boyle, notifications@github.com wrote:
I don't understand why gHue would ever be static..?
It's an incrementally changing value..
am I missing something here?
have you tested this code?
Static is not like constant it just means that the variable is kept alive after the function exits. The code is untested as far as I know. Kieran seems to think it's better to do it as a static local variable as it is only ever used for fill_rainbow so it does seem pointless to have it as a global variable seeing as nothing else references it. I dont actually think it makes any difference with regards to memory or anything and personally I would have just left it as it was as it wasnt hurting anything.
no makes no difference as to it being global, or static local, just means it doesnt get deconstructed. as i stated above, purpose was to remove a global that only has one calling function. good code practices and all that..
I see, It wasn't and now is..
Surely whatever replaced gHue in the other patterns is using the memory
instead.
Read the linked page, hadn't quite got it.. Still can't see how it helps
tho.
Don't push the code before you test the code x
On Mon, Jun 3, 2019 at 10:48 PM Squatnet notifications@github.com wrote:
Resolved