New examples, and lots of bug fixes.
0-255 is a legacy of 8-bit color values, which aren't as ubiquitous as they used to be - for example many Apple devices now ship with 10-bit displays, which would correspond to a 0-1023 range. Rather than use a range that depends on a particular bit depth that can change over time, it makes more sense to use a fixed range like 0-100, especially when dealing with event logic (e.g. if you have a 0-100 value you can use it directly, rather than having to multiply by 2.55). Also modern GPUs internally calculate everything with floats and the bit depth only applies to storage and display.
But most color values in photoshop and illustrator are in 0-255 format. When doing color and translating values, I usually work with those programs and I need the 0-255 format more instead of translating it into 0-100.
It's really not that hard...
You divide your 0 - 255 color value by 255 and then multiply it by 100. Round to 2 decimals if needed.
Or just use this conversion tool and notice the "RGB Percent" calculation.
convertingcolors.com/rgb-color-255_100_100.html
True, but this is a change that adds work to a workflow for arguably minimal benefit. People aren't designing in 10 bit. Nor are they picking colours to suit their GPUs preferences. This just adds work.
I agree with damjan, this is a "programmers" decision, not an artist idea. Most of designers and artists are used to the 255, but i understand the issue with growing deep and precision in code and displays. i don't recomend deprecation, leave it as an option?.
100% agree. This is definitely a decision made outside of an artist's workflow. It should definitely be an option. Mandating makes no sense.
Most graphics programming is done in a 0-1 scale, so I think it's still appropriate for the event system. Also given that other parts of Construct such as opacity have long been in a 0-100 scale already, using a 0-255 scale would create an inconsistency with the rgba expression (either color components on a different scale to alpha, or opacity on a different scale to everything else in Construct). So this way is aimed at making sure Construct is internally consistent.
I totally appreciate how this benefits construct, the code, looks tidier, etc. But it's more work for your users. Photoshop and gimp both work in 255, and that's a huge chunk of the artist community. Now you're asking us those who are building palettes, sprites, etc in one system to keep converting to another every time they bring their work in construct.
Think about the huge impact this would have on the Replace Colour effect, for example, in a pixel-based game. Applying any kind of colour changing effects requires translation of every value.
It just seems like this translation from 255 to 100 could either be optional or certainly behind the scenes.
It's just hard to imagine anyone was troubled by opacity being in percentage and color being in 255. I think the pursuit of internal consistency is making your user experience considerably worse.
Hmm... I think maybe a better way to look at this is the difference between editing images vs. graphics programming logic. Image editors tend to work on a 0-255 scale for legacy reasons, or on the assumption you're editing an 8-bit image. However all graphics programming is done with a normalized scale. So keeping to that principle, the editing features would use the standard 0-255 scale, but the event features would use a normalized scale.
For sure, that makes total sense from the engineering perspective. The trouble is that most image editing software works in 255, and that's where our initial colour choices are made — regardless of the image's bit depth.
So from the game designer POV, 245 or whatever 255-based number becomes the value. Translating it back to 100-base is extra work, serious disruption in the workflow, and potentially problematic (imagine forgetting to convert 84 from 255-base to normalized).
As a game designer, I'm really hoping you can remove translating values at all for the R, G, or B channel value. If the designer's colours are chosen in 255-base, then they should be able to stay that way throughout the design process. Most colour interfaces give you option to use whatever system you prefer (hex, rgb, etc). I think it should be the case here.
I really do understand your case from the programming principle, but really think it's the wrong principle to base the construct experience on.
As described here I've added new expressions for the next release that work in a 0-255 scale, so you can have it both ways.
For what its worth, most artists can relate to 0-100... as it is not only a throwback when selecting colors for "print" (0%-100%), but most sliders (i.e. opacity) uses the "percentage" model -- but as a programmer and artist, I understand the concerns for the 0-255. Also, based on my experience, most folks that are more pure programmers are less likely to use Construct for the other platforms (no need to mention :-)
so, why no use (0-1)?
Most other parts of Construct already use 0-100, like the 'Set opacity' action.