Snapblocks (Part 3)

Share your Projects
61

I initially tried that, but for accuracy, it has to be -0.5 (or -0.6), and I think either firefox or chrome was rounding it to -1. Or maybe it was just that I wanted you to be able to import the svg into inkscape, which doesn't support drop-shadow(). There was a reason why I didn't use it, but I can't remember exactly.

I use a bevel filter because it was easier than having to draw all the edges myself (most of the block drawing is mostly precalculated, unlike snap). It was also because that's how scratchblocks did it for the scratch2 style.

62

chrome rounds it, but -1px is the right amount, not -.5 or -.6. snap source code shows 1px and it's easy to see that chrome is more accurate. chrome also rounds the svg filter, firefox is displaying it accurately.

63

Oh yeah, it is -1px. The reason why I went with -0.5 is because I was comparing the blocks with snap block zoom set to 5, which changes the shadow offset (I later changed it to -0.6 to try and move it slightly out more).

Also, chrome doesn't seem to be rounding it.
-0.6px -1px
330x111
330x111330×111 7.25 KB
330x111
330x111330×111 7.43 KB
64

ok no i see, chrome rounds the svg filter to a physical pixel, but rounds the css filter to a logical pixel. that means in chrome that -0.5px does actually match snap on a standard dpi display.

ok one useful thing i can say while i'm here: firefox is really fussy about the borders of an svg filter. if the borders on an svg filter fit too tight, firefox doesn't always realign it so elements can be randomly off by a pixel. if the borders aren't on the real pixel grid, firefox doesn't line the element up to the pixel grid and it ends up blurry (what i can see happening on snapblocks right now)
i don't know the exact steps to fix it off the top of my head but i'm working on it so hopefully the svgs should end up looking much better in firefox

65

not sure if its only me, but this is still an issue

{glide (span) secs to x: (x #) y: (y #)} :: define+
<t> primitive [doGlide V]
script variables ((pos)) ((start)) ((fract)) $<>
set [pos V] to (position)
set [start V] to (current [time in milliseconds V])
repeat until <(fract) \>= [1] $<:> > {
set [fract V] to (((current [time in milliseconds V]) - (start)) / ((span) x (1000) $<:> ))
go to ((pos) + ((list (x) (y) $<> ) x (fract) $<:> ) $<:> )
} $loopArrow
go to x: (x :: variables) y: (y :: variables)

image
image505×336 39.6 KB

(screenshot of what I'm seeing, in case it is just me)

i also just noticed that variables / inputs named "x" or "y" automatically have the motion category (i forgot to set the block type to variable in the (list () () $<>) block

66

Yeah, made the fix, but haven't released the update yet, and even if I do actually release it, I can't update it on the forum, since the web extension updater page is kind of broken right now (I told Michael).

As to x and y variables turning into motion blocks, blame the Estonian language.

67

why? also, will there be a fix?

68

image
image156×157 2.64 KB

Screenshot 2025-02-27 154934
Screenshot 2025-02-27 154934269×117 7.05 KB

The Scratch translation of the "x position" and "y position" for Estonian is just "x" and "y".

69

with a space after it, it seems? also ego-lay_atman-bay, why don't the bottom x and y vars become blue?

70

They overrode it to be in the variables category.

That is probably just the fact that the blocks can't get any skinnier, just like in Snap! with hat blocks:

small::control hat
71

Yup, that's the reason. Snap doesn't center the text of reporters that have text smaller than the smallest width, so it might look off.

Honestly, I don't know. I don't want to get rid of translations, though if I do actually figure out a solution to adding snap translations (and keeping them up to date), then these will likely be replaced with their snap translations.

72

Well the scratch one was the one that looked off centered to me, but ok. As for the translation, I don’t understand why there is a reason to keep problematic scratch translations in snapblocks.

73

and as I said, I forgot to override the instances of x and y above it

74

Currently I don't have a way to import the translations from snap, so I'm sticking with the scratch translations for now. I do want to be able to import them at some point, I just haven't created a system yet.

There is actually also another thing I have to work out, the blocks that are more dynamic, any block with variadic inputs, is also difficult to figure out how to translate them.

There's just many things I have to out before getting snap translations in snapblocks.

(I could also just have translations off on the forum by default, which would fix some of the translation issues we're having)

75

Is "primitave" some other language, or a typo?

76

That's a typo on @mctx_studios's part. Snapblocks checks for "primitive" spelled correctly. It just doesn't help that the obsolete color is grey (which is one reason to have it be red, just saying).

77

:~P

78 
when gf clicked
say [wow!]
dance around idk::#f90f9f
79

image
image464×139 5.79 KB

ehhh... what is happening? the hat just got fatter or something

80

i finally got around to finishing those changes:

i redid the block shading entirely. it looks much more like snap, even down to the slight blur on block edges from pixel misalignment.