I finished integrating everything manually yesterday, and it's almost ready
to be pulled (this time including all the updates since late year ;)). I
haven't requested a pull yet because I'm thinking about your comments with
the "graphicschanged" property. It's necessary because without it, the page
won't load at all, the error being something like "Cannot read property
'negative' of undefined" (negative being the first value I wanted it to
pull from the dictionary). It seems to imply that graphicsValues (the
dictionary) is inaccessible to applyGraphicsEffects when you initialize the
page, as in maybe applyGraphicsEffects is called first before the
dictionary is initialized? I'm unfamiliar with what order the functions are
read when page is actually rendered. But moving the dictionary inside the
function solves the problem. The only thing is now the setEffect would have
to reference the dictionary defined inside the applyGraphicsEffects
function...I partly don't know what I'm saying and this is a brainstorm,
but it sounds logical in theory. I will check when I am on my computer :)
The check makes it so that that you don't call the dictionary values until
the user specifies he wants to play with the graphics, fixing the reference
problem and with the added benefit being that it is faster because you
wouldn't have to go through all that pixel stuff regularly unless the user
specifies.

Okay I will see if I can fix reference error without the check, and if not
I will replace it with the function you commented. Thanks!
On May 26, 2014 11:42 PM, "Jens Mönig" <notifications@github.com> wrote:

> In objects.js:
>
> > @@ -866,11 +865,6 @@ SpriteMorph.prototype.initBlocks = function () {
> >              category: 'sensing',
> >              spec: 'set turbo mode to %b'
> >          },
> > -        reportDate: {
>
> Thanks, @galaticalmonkies <https://github.com/galaticalmonkies> for
> taking the time to clean this up. I don't know how to use Git effectively
> myself, so I'm not much of a help in this issue. I do appreciate that
> you're taking the effort to grapple with it :-)
>
> As a general preference I'd simply fork the main Snap repo, not some fork
> of a fork, because it looks to me that it's more likely and easier to keep
> direct forks in synch, than forks of forks. Gosh, I totally mistrust Git
> myself, and this makes me think I know why. See, there's really only one
> issue with your actual code (graphic effects not kicking in when you redraw
> the sprite for some other reason than applying graphics effects - and by
> now you've addressed that issue yourself), and the grave issues are all a
> result of some Git magic, so I realize that most of my comments were
> probalby unfair to you, because you didn't even decide to take out anything.
>
> It'll be fun to have your graphics effects in Snap, and I love how you've
> made them really fast without using any third-party libraries or Web-GL and
> such. That's *exactly* how I envisioned them to be, and it's really,
> really cool of you to have pulled that off!
>
> I've commented on your commit that fixes the "redraw" cases. It's just a
> slight remark about avoiding a piece of state that can get out of synch
> ("graphicsChanged"). Personally, I wouldn't mind if you simply left
> checking for "graphicsChanged" altogether (since you're checking in every
> graphics effect code anyway), but that's up to you. I'm only suggesting to
> use a function (a higher-order one, even, hehe) instead of a state-doubling
> property.
>
> Looks like this is *almost* ready to be pulled!
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/pull/401/files#r13063622>
> .
>