Expected Behavior
The set pen color to {color} block should support ARGB in the same way that Scratch 2.0 does.
Actual Behavior
The set pen color to {color} block supports only RGB color.
Steps to Reproduce
Note that 2147483903 = 0x800000FF = ARGB(128, 0, 0, 255).
In Scratch 2.0 this will result in an image like this:
Needs discussion
Should the set pen color to {number} block also support ARGB color? It doesn't in Scratch 2.0, which is why the color variable is necessary in the "Steps to Reproduce" example.
cwillisf
All 17 comments
I wouldn't add ARGB support to set pen color to {number}
In that block, 'color' is being used as a simplification of 'hue', so it doesn't make sense to have it accept RGB values.
Also, how would just define the limit between what is considered a hue and what is considered an ARGB value?
imo this feature is only used by advanced Scratchers so it is best to stick to compatibility over usability
ed-cooper
on 23 Jan 2017
imo this feature is only used by advanced Scratchers so it is best to stick to compatibility over usability
This is :+1: but if you can figure out a good way to keep things usable and compatible that's always nice too!
towerofnix
on 23 Jan 2017
It is conceivable that you could check for a 0x string such that 0x800000FF is read as ARGB, while numerical values are read as hue. That would maintain compatibility while giving certain experienced scratchers the ability to use ARGB.
SillyInventor
on 23 Jan 2017
Yeah, accepting hex values for pen colors would be far easier to work with than the current system
mrjacobbloom
on 23 Jan 2017
Good point, @chooper100 -- I should probably have phrased that differently. I don't intend to break the hue-setting block that Scratch 2.0 has, but it might be interesting to support direct numeric input for semi-transparent colors somehow. @SillyInventor's suggestion might work, for example, but I don't think we use the 0x prefix anywhere else in Scratch right now so we might choose a slightly different way to express the color. I could imagine options like "rgba(255,255,255,128)" or "rgba(1,1,1,0.5)" or... lots of other options :)
On the other hand, it's certainly true that only advanced users set semi-transparent colors at all, and these options might be confusing to newer Scratchers. We'll need to carefully consider that balance before implementing an something like this.
cwillisf
on 23 Jan 2017
The 0x prefix syntax has kind of always existed since it's part of Flash's numer casting (and JS, too, I think).
set pen color to (join [0x] [77AA6666]) will get you a somewhat transparent red color (if you use the color-input block). (IIRC)
towerofnix
on 23 Jan 2017
@SillyInventor Then if you want to manipulate ARGB colors using Scratch's numbers you'll have to convert the number into a string representing the number in hexadecimal, which will be slow and annoying. And it will break compatibility, because you won't be able to use strings representing numbers in hexadecimal for hues anymore.
Jonathan50
on 23 Jan 2017
Or… Scratch could have a first-class "color" data type like Panther?? (And also accept ARGB numbers for compatibility which Scratch 2.0)
Jonathan50
on 23 Jan 2017
My recommendation would be to implement this identically to Scratch 2.0 for now in order to maintain compatibility / avoid scope creep.
thisandagain
on 23 Jan 2017
Resolved in https://github.com/LLK/scratch-vm/pull/403
thisandagain
on 27 Jan 2017
Still seeing issues with some projects. Example:
http://llk.github.io/scratch-vm/#125372703
thisandagain
on 10 Feb 2017
Looks like the issue with project 125372703 is a failure to correctly stamp the black block costume. Not yet sure if it's stamping in the wrong place, with the wrong amount of transparency, or not effectively stamping at all...
cwillisf
on 11 Feb 2017
Interestingly, once you click the "show" block in sprite1, the project is fixed.
I suspect this is some deeper issue related to loading of projects into the VM (seeing as it works in Scratch 2)
(EDIT: You have to drag out a new show block from the toolbox, if that wasn't clear)
ed-cooper
on 11 Feb 2017
Oh, nice catch, @chooper100!
cwillisf
on 11 Feb 2017
This is done: http://llk.github.io/scratch-vm/#73673560
thisandagain
on 18 Feb 2017
Still does not seem to be working:
http://llk.github.io/scratch-vm/#73673560
Windows 10 Google Chrome
TheBrokenRail
on 18 Feb 2017
That project uses the black "stamp" method for transparency, not RGBA pen.
On Sat, Feb 18, 2017 at 5:10 PM TheBrokenRail notifications@github.com
wrote:
Still does not seem to be working:
http://llk.github.io/scratch-vm/#73673560
[image: pen]
https://cloud.githubusercontent.com/assets/17478432/23097252/2c971852-f5fd-11e6-89cc-6fd3999e5854.PNGWindows 10 Google Chrome
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/LLK/scratch-vm/issues/393#issuecomment-280878914, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAtoeUj9OdTdKFyxKfaJhrvjO6MgvoMdks5rd2xugaJpZM4LrLdJ
.
thisandagain
on 19 Feb 2017
Related issues
fsih
·
7Comments
LiFaytheGoblin
·
5Comments
cwillisf
·
4Comments
griffpatch
·
6Comments
CatsAreFluffy
·
6Comments
Most helpful comment
My recommendation would be to implement this identically to Scratch 2.0 for now in order to maintain compatibility / avoid scope creep.