I just ran into this today. I’m trying to use white bitmap fonts that I colorize for use against different background colors, but they revert to their default white inside a masked scrollview. The docs say this is a
“known limitation at the moment”
which leads me to believe there was an intention to fix it. Given that so much time has passed, is this a true hardware limitation that can’t be fixed or is there some hope that it will eventually be addressed?
Hi @HardBoiledIndustries,
Can you show me a bit of code where you’re inserting and colorizing these text objects? I just tested some colorized fonts inside a scroll view (masked) and it works, so I must be doing it differently somehow.
Thanks,
Brent
Hi Brent,
Strange. My project is complex so I tried to create a simple test case for you and… it worked!
I don’t know what I could be doing differently in my actual project as compared to the test. The big difference is that I am using Text Candy for the fonts and it’s own setColor method so I’ll need to dig deeper to see what it’s doing under the hood. But the current behavior is that all my text objects that are rendered inside a masked scroll view have the color missing. If I disable the mask then the colors show up.
But at least in the simple test case setFillColor does indeed work inside masked scrollviews.
UPDATE: I made a simple test case and it does indeed seem to be a bug or limitation of Text Candy objects. I poked around in the TC code but couldn’t figure out what’s causing the issue. Since TC works fine with scrollviews as long as they don’t have a mask I’m guessing the X-Pressive guys will call it a Corona bug. I submitted my test case to them anyway in hopes they can isolate it further.
Hi Brent,
I think I found the bug, and its an issue with Corona, not Text Candy.
Basically, a newImageRect object with alpha, such as a white circle against transparency saved as a .png and imported as a newImageRect, can be color tinted using setFillColor, but it will lose that color if it is inserted into a scrollView with a mask.
If the object is a newRect it will retain the color inside the scrollview, so newRects can’t be used to exhibit the problem (possibly what you used to test it yourself?)
If the scrollview doesn’t have a mask then a newImageRect will retain the color tint inside the Scrollview.
I’ve attached a simple project that exhibits the issue. I’ve also filed a new bug with the same project file.
(Case 25782) ImageRects loose color tint when inside scrollView that has a mask
What’s a use case limited by this bug? I am using bitmap fonts via Text Candy for all my in-game text because they are much faster to render. (I was having long delays between scenes on Android devices when using newText objects so I had to switch over to bitmap fonts). Bitmap fonts are of course created using newImageRects for each character. I create each font using a white color with the expectation that I can tint them to any color that I want inside the game. This works perfectly, _except _in the case where I use text inside a scrollview with a mask, of which I have several inside my in-game store interface. The only work around is to render separate font image sheets of the same font, for each color. This is very wasteful in terms of app file size and texture memory since I would have to store, load, and display multiple copies of the same font, one for each color I intend to use.
Hi @HardBoiledIndustries,
Thanks for filing this bug. I see the same behavior you describe in my latest tests. I believe this will be addressed in Gfx2.0, but let me test it when I have some free time.
Best regards,
Brent
Same behavior occurs on TableView, not just ScrollView. Not sure if that needs a separate defect # or if it will also be resolved in Gfx2.0?
This will all be fixed in Graphics 2.0. The problem is how masks, groups and tints have to interact with graphics 1 and the limits imposed there. With G2.0 we get a feature called “containers” which are like self-masking groups with a defined size. Groups now have no size and have to be masked to make their contents (like tableView rows) that are outside the box to be hidden. There are only so many nestings of masks and such that can be done and this impact the tinting of things.
When containers come into play, we won’t need to mask the scrollView or tableView any longer and things get better.
Awesome! Thanks for the update and explanation.
Thanks for the info, Rob. I’m curious how easy it will be to integrate graphics 2.0 features into a mature 1.0 project. For example, in the case illustrated above, will I be able to simply use the “container” feature of 2.0 to allow text tinting in a scrollview but otherwise make no other changes, or will using graphics 2.0 require major rewrites of existing code? In other words, can I use graphics 1.0 and 2.0 features interchangeably within the same project, or will I have to pick one or the other? In other, other words, how backwards compatible is graphics 2.0?
Walter has indicated that there will be a compatibility flag that will let V1 apps build against V2, so ideally with that in place you won’t have to make any changes and can start using the new features. I’m still learning about all the features, and I’m not quite to a point where I can go into much details.
Hopefully we will have more information soon.
Rob
Same behavior occurs on TableView, not just ScrollView. Not sure if that needs a separate defect # or if it will also be resolved in Gfx2.0?
This will all be fixed in Graphics 2.0. The problem is how masks, groups and tints have to interact with graphics 1 and the limits imposed there. With G2.0 we get a feature called “containers” which are like self-masking groups with a defined size. Groups now have no size and have to be masked to make their contents (like tableView rows) that are outside the box to be hidden. There are only so many nestings of masks and such that can be done and this impact the tinting of things.
When containers come into play, we won’t need to mask the scrollView or tableView any longer and things get better.
Awesome! Thanks for the update and explanation.
Thanks for the info, Rob. I’m curious how easy it will be to integrate graphics 2.0 features into a mature 1.0 project. For example, in the case illustrated above, will I be able to simply use the “container” feature of 2.0 to allow text tinting in a scrollview but otherwise make no other changes, or will using graphics 2.0 require major rewrites of existing code? In other words, can I use graphics 1.0 and 2.0 features interchangeably within the same project, or will I have to pick one or the other? In other, other words, how backwards compatible is graphics 2.0?
Walter has indicated that there will be a compatibility flag that will let V1 apps build against V2, so ideally with that in place you won’t have to make any changes and can start using the new features. I’m still learning about all the features, and I’m not quite to a point where I can go into much details.
Hopefully we will have more information soon.
Rob