Two new vars, atom.alpha and atom.color, influence the appearance of icons on the screen. The alpha value can be used to fade an atom in and out; the color is multiplied by the icon.
Applies to:DM Language
Status: Resolved (500.1205)

This issue has been resolved.
atom.alpha has been added to the language, but it occurs to me that I set it up in a way that makes sense to me, but might not to everyone else. I'm not sure, so I wanted some opinions.

Right now, it's using a range of 0 to 255. This makes sense to me, as it's what I'm used to from icon procs. But is it sensible to everyone else? There's no reason that the var can't range from 0 to 1, for instance, or from 0 to 100 as a percentage.
I don't see any reason it can't be 0 to 1, given that that's the format most rendering systems use internally these days.

It's not like it makes much difference on the backend, though, seeing as numbers in BYOND are pretty much all 32-ish bit floats.

Maybe that would deviate from what BYOND developers are comfortable with, though, I can't say.

Not like it's hard to convert either way, though:

xI/255 = floor(xF*255) = xI

I'd think it'd make more sense to use the one that allows you to pipe it straight into whatever blitting functions you are using on the backend, that way you don't have to do any serious casting.

(Obligatory celebrations.)
They're all fine. A percentage approach seems more intuitive, though.
Internally it's just a byte in the 0 to 255 range, so it's already in the format easiest to use by the graphics. But it can be presented on the frontend any way that game developers will find most comfortable. It's no trouble to me to convert the float to this range before storing it.
I think 0 to 255 range is just fine, since it is the same alpha handling as the rgba format.

This range would probably be a better in terms of handling when compared to 0 to 1, that is if you are used to handling colors in the 0 to 255 range.

So yeah the current format makes sense.
^I think Taitz has kind of nailed it. rgb() basically boils byte data down into as close as a 4-byte integer as BYOND's engine can handle, a 10-byte string.

Consistency would really make sense here, and since we've been working with unsigned byte representation thus far, it makes sense to be consistent, since it's no trouble on the backend for you, Lummox.

I'm sold.
It's zero trouble at all, as that's the format I'm already using. (Not that it would be any trouble to switch to a different range.) My gut said the 0-255 range made good sense because of the icon ops; I just wanted to confirm that was true of other users and I wasn't just thinking like a C++ developer.
Sorry, should have said since it's not any trouble, not if.
I'm definitely for sticking with 0 to 255, with a 1% to 100% as a second choice. 0 to 1 just seems like a lot of unnatural mental "conversion" has to go on to get a full range (sure, half opacity and other "round" values are easy... but what's the decimal equivalent of 134 out of the 0-255 format? not that anyone really needs to be using such odd values, but I think it's just an unnecessary pain if the need were there)
In response to SuperSaiyanGokuX
You make a good point there; plus, a number like 0.5 won't really be preserved, so if you set alpha=0.5 and then got 0.501961 when you read it back, you'd probably find it pretty strange.
The transition to working with floats when I initially moved to 3D was rough. The precision preservation is a good reason to not use floats at all, because BYOND's target audience is just not ready for methods of managing imprecise decimal values, much less manipulating quaternions and the like. Handling euler angles in two dimensions seems to top out our average userbase. We operate with an audience that has little algebra/trigonometry/calculus education or understanding (unrelated to the current problem, but indirectly indicative of a general mindset), so yeah, the 0 to 255 approach kind of falls in line with the target demographic's usage.

I guess the more I think about it, the more my initial feeling was not considering several key factors.
I prefer 0 - 255. You can convert with math if you need percents

50% = 255 * 0.5
99% = 255 * 0.99

In response to Lummox JR
Lummox JR wrote:
so if you set alpha=0.5 and then got 0.501961 when you read it back, you'd probably find it pretty strange.

Isn't this still a problem you need to fix?? Especially with icon_state frame delays.
The DM icon editor works with 0 - 255 so that method would probably be the most intuitive for the majority of developers.
I'll be the black sheep and say that I'm for 0-100 as opposed to 0-255

While I'm sure I can do that math myself, a percentage rests easier in my mind :)
In my opinion 0-255 makes the most sense. It's a little odd for alpha but it's consistent with the rest.
Maybe you could just have atom.color that would include color tints as well as alpha, using the existing rgb() proc that takes numbers from 0 to 255.
As much as I'd like atom.color, I think it's prohibitively slow. In software mode it'd be dog slow, though DirectX can do it quite easily. (It'd be cool, though, to see color utilized in animation.)
I'm fine with 0.0 - 1.0 or 0 - 255.

0-1 makes it more consistent with HSV or HSL, but then again there are no HSV or HSL operators in DM.

0-255 is consistent with the preexisting rgba icon operators.
The IconProcs library supports HSV, but yeah, there's nothing native.
Page: 1 2 3