Why is ColorSet a 1-100 range ?

Discussion and feedback on Construct 2

Post » Tue Dec 04, 2012 8:29 am

I ws playing with this effect and after asking on the forums, found out that it is on a scale 1-100, and not 0-255. Is there any reason for this ?

Attached is the oringal .capx, that I made while referencing.

https://dl.dropbox.com/u/108799982/Capx%20Demos/Colour.capx
Using R238 for all examples
B
60
S
17
G
6
Posts: 363
Reputation: 9,125

Post » Tue Dec 04, 2012 12:59 pm

We were talking about the same issue in this thread. I think a lot of people agree that it's a bit odd to have this range when it's so classically 0-255.
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Tue Dec 04, 2012 2:53 pm

I almost made the picture editor use 0-100 as well, which I do think makes more sense, but in the end I went with what other image editors do. Everywhere else I try to use a percentage where possible, such as with opacity which I feel should definitely be 0-100 and not 0-255.

The reason everyone's used to things going 0-255 is simply because it's common to store pixel data in an 8-bit unsigned byte, which has that range. Early graphics software simply displayed these values directly to users, and I guess it caught on.

The thing is an 8-bit byte is just one of many ways to represent color values, and it's possible to have 1-bit, 4-bit, 5-bit, 16-bit, 32-bit and even float 16-bit and 32-bit variations, or mixed-bit integer representations like a 16-bit color storing 5, 6 and 5 bits for red, green and blue respectively. In fact many modern graphics processors process everything as floats from 0 to 1 in a variety of bit widths and multiply by 255 just before displaying them on the screen.

In short 0-255 is not "the" way of entering color values, and may in fact be totally unrelated to the real representation inside the computer, so it's actually kind of an arbitrary choice these days. It's just everyone's used to it and probably assumes colors are still 8-bit values even if they aren't so much any more. So IMO it makes more sense to make it 0-100, like many GPUs really use but multiplied by 100 for convenience, but I went with convention for the image editor because it seems to be a de-facto standard there.Ashley2012-12-04 14:55:37
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Tue Dec 04, 2012 6:35 pm

While I understand from a developer and technical view. It still exlcudes the easy use of the plethora of shared pallets. Also having to put in 12 digits for translated numbers is a pain.
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Tue Dec 04, 2012 7:49 pm

Well, I guess that all makes sense. And while I understand Opacity and other effects are percentage based, I'd still argue that a 0-255 range would suit colours better, especially for those who have grown up with this as a standard from using programs such as Photoshop, or wed designers, where it's either #FFFFFF or 255,255,255.

That being said, I'm pretty sure that as it stands we can do the simple math of ((value between 0-255)*(100/255)) to gain the percentage value needed.
Using R238 for all examples
B
60
S
17
G
6
Posts: 363
Reputation: 9,125

Post » Sun Nov 10, 2013 8:21 pm

Holy mother of birds, I just spent about 3 weeks programming different combinations of my color based game. So much time... Lost.. Because I thought set color doesn't work.

I hope this never happens to anyone else :)
Learned a LOT of Construct 2 in the meantime :)
B
32
S
4
G
1
Posts: 266
Reputation: 2,426

Post » Sun Nov 10, 2013 8:56 pm

255 makes working with 16,7 mio colors easier, no need for the user to deal with decimals
Visual Novel 'Engine' in 100 Events
if you ever have to choose between buying Construct 2 on scirra.com or on Steam, read this: Review
B
20
S
9
G
1
Posts: 785
Reputation: 3,725


Return to Construct 2 General

Who is online

Users browsing this forum: armaldio, bilgekaan, Davioware, saiyadjin, Yahoo [Bot] and 2 guests