Why change the color parameter values?
Oct 08 2013 05:02 PM
The Corona way is about making coding easy. Not only is high channel color support not on anyone's wanted list - really, see the Corona votes page - I'm having a hard time thinking of popular tools or engines that like to use it. Or actual devices. I can imagine things like Steam or 4K or whatnot, but this wasn't even on my radar.
So the deck seems pretty stacked: we have existing tutorials supporting RGB. We have other tools that mandate (or prioritize) RGB. Photoshop itself emphasizes RGB. Users are mystified. It would seem, as an outsider looking in, that the best approach would be to either:
1. Continue the existing RGB-first approach, or...
2. Support seperate :setRGB() and :setHDR() fills.
3. Have a :setDefault() to tell Corona whether to use the RGB or HDR color space, so that :setFillColor() still works as is.
#2 and #3 would mean some more code somewhere, but still all internally translated to HDR anyway.
It may seem a slight difference compared to users rolling their own /255 function, but it saves all of the arguments and explanations and lets everyone get back to coding, which is the whole point anyway.
Completely agree with and share the same frustrations on this update.
The majority are more accustomed to using RGB. Supporting 16-32bit hardly seems urgent right now. Certainly not enough to introduce such a change in this manner. If I want to use RGB, I should be able to use RGB. As suggested above, it would have made perfect sense to introduce a setting for using RGB or HD color space (RGB being the Default) and leaving the methods as-is.
With regards to the V1 compatibility mode -- suggesting the use of that is hardly a solution. It's a temporary workaround to avoid breaking code because this change was not rolled out better. It'll be an expired workaround eventually. And when that happens, the expectations are for all developers to migrate to the HD color space and drop RGB altogether? Does anyone really want that?
I would like to see this revisited. I don't agree with this change being the "best decision" and seems like the majority here would agree.
i think, like many of you, there are several reasons why i would prefer not to use the new HDR color space in Corona. the good news is that now we don't have to !
i just finished writing and published a new module for my Corona Library which layers in backwards compatibility for the traditional RGBA color scheme - it's called dmc_kolors. i needed/wanted this module because of some client projects which i've done and about to do and i couldn't imagine doing (150/255, 100/255, 0/255) all over these applications. =)
i've incorporated some of the ideas and features from this thread -- things like setting a default color space, adding additional object methods (eg, setFillRGB, setStrokeHDR ) and setting up named-color files using the X11 standard colors.
i have written some docs and have an example included with the library. the docs are rough, but both together should get you on your way.
there are still a couple of things to add, but i think it's pretty comprehensive and solid enough to release. feel free to check it out and let me know if you run into any issues.
the dmc_kolor library with example is available here: https://github.com/dmccuskey/DMC-Corona-Library
docs are available here: http://docs.davidmccuskey.com/display/docs/Quick+Guide+-+dmc_kolor