Why change the color parameter values?

I’m not wrong because I said I don’t know of any game developers who think of colors in that way. It could be that I just don’t know the game developers you know. But my point was, and I’d bet money it’s right, that most devs don’t *think* of colors in that way. As in, come up with colors 0-1 in their heads.

And that has nothing to do with the solution that would have allowed 98% of Corona devs to continue using 0-255 while the ones who care about a larger color palette can do that, too:

setFillColor(0-255, …)

setFillColorHD(0-1, …)

Adding features is good. Breaking existing code is bad. I think CL could have gone to Gfx2 without breaking things – you can deprecate things over time and do an end-of-life later.

Example: object:setReferencePoint(display.CenterLeftReferencePoint) could have done an anchorX=0 and anchorY=.5 under the hood along with a warning that setRefPt was deprecated and to stop using it – but it would still work. That would have allowed maintenance and updates to go on for a while without things breaking.

Yes, it requires more back-end coding and yes, the resulting code is not as optimized as it could be, but that would only be a problem for the people who continue using the deprecated API calls.

 Jay

(Full disclosure – the changes hit me harder than the typical Corona dev (I think) because I make my living teaching game dev using Corona SDK. And the changes in the latest version basically put me out of business until I can recreate 100+ tutorial videos. So now I’m knee deep into that and every time I come across a change that wouldn’t have had to happen it frustrates me all over again and makes me think maybe being a janitor would be a less stressful way to make a living.)

 Jay

J.A., I agree that it’s sort of a hassle and we have to now edit our code (and your tutorials, that’s a mammoth task….)

It’s not really a question, though, of CL arbitrarily dreaming up one system or another. It’s just moving from the use of RGB Decimal to RGB Percent, both of which are used by various graphics programs. 

For example, http://www.colorhexa.com/271e94

This color is listed in several formats, Hex, RGB Dec, RGB %, and more.

I recommend in my tutorial above NOT dividing manually by 255 but just copying/pasting the percent value, edited to move the decimal place. There are other solutions like special libraries to use named colors, or whipping out your calculator and doing the math yourself…but in my opinion we might as well just make the change and hope we don’t have to ever do it again (right, CL? :slight_smile: )

I absolutely agree! CL seems to make these decisions pretty lightly without much consideration to the impact on their customer base.

Your proposed solution sounds awesome but I think this ship has sailed. I don’t expect CL to make any changes in this area. I feel for you and your 100+ hours of videos which now need to be updated. Best of luck. 

We don’t make these decisions lightly.  We understood fully that this would be a big impact on people and after considerable discussion from all people in the company, switching to 0…1 and providing graphicsCompatibility = 1 mode seemed to be the best of both worlds.  No one is forced to use 0…1 if they are vested in 0…255 for existing code.  If they want to use new features, then they have to change.

I feel bad for Jay and the other authors who v1 compatibility mode doesn’t help , but at the end of the day, it was the right direction for the future of the engine. 

Rob

I don’t know if this is of use to anyone but I’ve just updated the GGColour lib to use the new 0-1 values - https://github.com/GlitchGames/GGColour

Hey Graham, have you considered using the XWindows Color specifications for your color names and values?  See:

http://en.wikipedia.org/wiki/X11_color_names

This is a somewhat common definition of colors and names.

Rob

I’ll chime back in here with another idea for a fix.  Similar to the fix introduced for the recent uproar over the new “lazy loading” of textures, how about setting a display default with something like

"display.setDefault( “HDcolorSpace”, true/false ) 

If false (the default value) any color settings use the familiar 0-255 range.  If set to true then use the 1-0 range.  Then nobody needs to comb through their old code, tutorials, or samples (including all Corona Labs samples and other 3rd party code samples that are now broken), or flip their brain inside out just to use new graphics 2.0 features.  Anyone who has already switched to using the 0-1 range would only have to add a single line of code to set the default.  Under the hood the 0-255 range could of course be converted to 0-1 if required by the new engine.

While I appreciate the implications of this change were discussed at length internally within the walls of Corona Labs, for future changes that will potentially break existing code it would be much better to float them out to the broader user community before committing them.   We’re all in this together, trust, transparency, yadda yadda…  

(Where’s the Like button?)

What CL did with the changes was to make obsolete almost every course, every book, every tutorial for their framework. That’s not a good thing no matter how you look at it. And it was avoidable.

 Jay

[Edit: For anyone keeping score, my complaining is not because I hate Corona, but exactly the opposite. I want it to be better than it is.There’s so much potential it frustrates me when I see what I think is a stumble.]

@HardBoiledIndustries - that is a brilliant idea!!! 

Jay, absolutely my sentiments. Thanks for voicing it so well. 

+1 for @HardBoiledIndustries idea. I’ve gone back through one of our projects and divided all of the values by 255 (well multiplied by 0.00392156862745 actually), and this default behaviour would have been much preferred. 

Every book out there and some that just got released, and many videos I’m watching, every tutorial on the internet - all seemed be broken now which is really great for anyone learning corona right now.

Ok, so that was very sarcastic but it’s extremely true. I’m with others, it’s a drastic change that while it was discussed internally that doesn’t help the external people. I realize there was a daily build for it, and people chimed in on various things but then BAM it’s just “released” and then this wave of confusion hit everyone. 

Yes, you can use ggcolor or do some division / 255 or something but it be nice if there was co existence with some standard phase out / deprecation over time and life cycle vs the chop off the head approach and make everyone swim for their lives.

I’m sticking with 1260, too deep to switch right now so I’ll release, support and update and see what happens.

Either way, I think the confusion is much higher than previously thought and seems to be growing.

-nick 

Hey Graham, have you considered using the XWindows Color specifications for your color names and values?  See:

 

http://en.wikipedia.org/wiki/X11_color_names

 

This is a somewhat common definition of colors and names.

 

Rob

Would be a trivial change, I think I will pull out the hard coded values anyway and put them in a separate definition file. Then I can include an X11 one as well as any others.

Also, as Rob pointed out, the change to the 0-1 color system is intended to provide future-proofed support for 16 and 32 bit per channel images. As far as I know there isn’t a current mobile device that has a true HDR display (though I’m sure some day there will be) so that extra color fidelity is literally invisible on today’s devices.  But assuming some day we will all have HDR phones and tablets a lot of app developers are going to want the ability to turn off that capability since a 32 bit/channel image is going to be 4x the size, and take up 4x the texture memory and bandwidth, as today’s 8-bit/channel images.  Unless you are making a photo editing/viewing app you will most likely want to use non-HDR textures for the performance and storage benefits.  This is all to say, having a way to set the default color space might actually be a very desirable feature in the future.

^^ Good point! I wonder if the decision was in some ways influenced by the upcoming Windows Desktop build support… 

I think I side with the 255 argument here. I don’t say this lightly.

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.

Sorry for the slightly-off-topic post but I thought I’d just update to say GGColour now uses external colour definition files and I have included the otherRBG colours as before as well as the x11 colours that Rob mentioned.

Woo Hoo!

Hey all,

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 ! :slight_smile:

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

cheers,
dmc