Why change the color parameter values?

Solar2D Advanced Graphics
#21

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…  

#22

(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.]

#23

@HardBoiledIndustries - that is a brilliant idea!!! 

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

#24

+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. 

#25

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 

#26

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.

#27

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.

#28

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

#29

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.

#30

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.

#31

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.

#32

Woo Hoo!

#33

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

#34

hi, all, just posted a tutorial on this: http://www.ladeezfirstmedia.com/2013/11/21/tutorial-what-to-do-about-colors-in-the-new-corona-sdk-graphics-2-0-public-release/

#35

Thanks DMC for the module, i’ll use it until i get used to % or we really need to use HDR.

#36

Hi Jen,

Thanks for this excellent tutorial. I’ll be testing this method myself, in my own conversions. :slight_smile:

I just added the link to Corona University under “3rd-Party” in the “Images, …” section:

http://www.coronalabs.com/resources/tutorials/images-audio-video-animation/

Thanks,

Brent

#37

Thanks Brent :slight_smile:

Here’s one you might consider adding to that same list, on content-scaling sprite sheets 

http://www.ladeezfirstmedia.com/2013/10/31/tutorial-image-scaling-with-texturepacker-corona-sdk/

:slight_smile:
J

#38

Added! :wink:

#39

I’m going to complain about this again because I feel it was a bad decision – and while I suspect the chances of Corona Labs “fixing” it by rolling back the change is slim, I feel a responsibility to speak up (with a proposed solution this time).

I don’t know of any game developers who think of colors in the range of 0-1 – which means when we get ready to set a color for something we have to use some other tool to figure out what the color number should be. And I don’t actually know if I have anything that will tell me 0-1 ranges, but I do know that just about EVERY paint program out there will tell the color in 0-255 range.

Solution: I believe setFillColor() should be returned to using ranges of 0-255 and if you want to use 16-, 32-, 64-bit colors, then a new setFillColorHD() API call can be added and that one can use the 0-1 ranges. There’s a precedent for that in display.newImage and display.newImageRect.

Thanks.

 Jay

PS - I decided to complain again because I’m writing new code and every time I come up against setFillColor() there’s no good+easy way to set the color.

PPS - Adding /255 to every color value is a kludge and offends me every time I resort to it, so it doesn’t fulfill the good part of good+easy.

#40

Sorry to disappoint you (no offence) but you are totally wrong here saying that. It’s you and other Corona developers who are used to 0 ~ 255 color palette ( which is convenient because you can easily grab color from graphic program which I also find nice).

However, you must face some facts. Corona is based on OpenGL ( on simulator ) and OpenES ( mobile, a bit less powerful version, on device). This has been standard (next to later DirectX) for game industry for years and amount of games produced with it is tremendous. There color palette was always in 0~1 scale - so there is reason why for years it was kept the same in this matter (like for example supporting different color resolutions).

Corona Labs created (highly probably) 0~255 scale for filling for 2 reasons. For easiness for greater range of user and no need for greater resolution. But I bet that under the hood they were still dividing by 255 to get 0~1 to pass it to OpenGL.

As team said, they are now trying to support greater resolution of colors and Graphics 2.0 brought more OpenGL feature for developers, so they must have decided to get back to native color range for compatibility and unification reasons.