[Fixed!!] Kindle & Nook build shows semi-transparent display objects shaded in, err... semi-transparent black

Solar2D Daily Builds and Public Releases
#1

I just installed my game on Kindle, and all of my display objects with alpha set to less than 100% appear mixed with black.

For example, yellow circle with 50% transparency would appear as if some black ink has been added to the color (imagine how supposed-to-look-like-a-pale-lemon would turn into some ugly-unnameable color). This same problem appears to affect custom fonts too. However, PNG images that are loaded into the game are not affected, whether or not the PNG images have transparency. This bug destroys the look of the game quite a bit.

This might be the very same issue that’s been discussed under this thread (and has been fixed): http://developer.anscamobile.com/forum/2012/01/26/semi-transparent-pixels-images-are-getting-mixed-black-kindle-fire

I’m using Daily Build 775, on Mac. I have a feeling the bug has crept back into the build. Must be a hard one to permanently purge, but sure would appreciate the fix.

Naomi

Edit: The observation made by Joe @firemaplegames is probably true regarding all .png images with transparency have black halos around, but I haven’t noticed any of my PNG images jumping out at me (even though most of my images have transparent background.)

Edit2: As per Nick’s suggestion below, I downloaded Daily Build 776, compiled the game and installed on Kindle. Unfortunately, I still see the same issue. Also note, the PNG images do not seem to be affected at all when built with 775 and/or 776. A bit of halos appear around the custom font (and semi-transparent black thingy making the font look dirty when its alpha is set to less than 1), but I don’t see any oddity with any PNG images even when their alpha is set to less than 1 at runtime. [import]uid: 67217 topic_id: 24369 reply_id: 324369[/import]

#2

I had the same problem with 775, but then i built with 776 and the bug disappearded.
Try 776 and report back.

Nick [import]uid: 77183 topic_id: 24369 reply_id: 98488[/import]

#3

Got it. Thank you, Nick. I’m downloading 776 now and will report back.

Edit: Nick, 776 didn’t fix the issue. Sadness. But I’m sure it will be fixed soon. (If you want to reproduce this issue, the easiest way to see it is to create a solid white rectangle as the background and then add semi-transparent circles spread around the screen – like yellow, red, blue and green circles with alpha set to something like 30%.)

Naomi [import]uid: 67217 topic_id: 24369 reply_id: 98551[/import]

#4

Hey, Joshua, do you want me to submit a new bug report for this with a simple project that easily reproduces the issue?

Naomi [import]uid: 67217 topic_id: 24369 reply_id: 98593[/import]

#5

Naomi,

The fix we made in build 765 to get rid of the black halos on the Kindle Fire and Nook Tablet actually causes the issue that you are seeing. We actually already knew that it would make the semi-transparent parts slightly darker, but we didn’t think it was noticeable. In fact, you were the first to notice it. Guess you have a better eye for color than most people. Or perhaps it is much more pronounce with your images?

You see, here is the real issue. The Kindle Fire and Nook Tablet (and possibly other Android devices) wrongly load PNG images with premultiplied alpha while most Android devices don’t. That in itself is a major inconsistency and their is no indication in Android that the image loaders are actually doing this. Once the image is loaded, Corona applies premultiplied alpha to the image so that it can be alpha blended efficiently in OpenGL. Now the consequence of this is that images are now being premultiplied twice on Kindle Fire and Nook Tablet, causing the image’s semi-transparent parts to become darker.

I’ve talked to Barnes & Noble’s tech-support team about this in regards to the Nook Tablet and they think it is a driver bug. Either their driver or a 3rd party driver. Of course, this doesn’t help us in the end since the damage is done and already released to the public. Our only other option at this point is to dump loading images via Android on the Java side and instead load them on the native side, but that is not a small/quick change and won’t happen anytime soon.

So… let’s talk about a work-around that you should be able to make work today…

If your image is really dark, then I suspect that your image has a very low alpha value (ie: mostly transparent). What you can do instead is make your image opaque and use pure alpha transparency around your artwork. When you load the image in Corona, apply an alpha value to the display object to make it semi transparent. Something like this…
[lua]local myObject = display.newImage(“MyImage.png”)
myObject.alpha = 0.5[/lua]

The above should work-around the issue because we are rendering the image transparent via OpenGL and avoiding the premultiplied alpha issue in the image mentioned up above.
[import]uid: 32256 topic_id: 24369 reply_id: 98595[/import]

#6

Thank you, Joshua, for the detailed explanation. I really appreciate it. Maybe I’m being a bit dense, so please bear with me, but I’m not sure if we are addressing the same problem. And maybe the issue I’m bringing up is different from the one you’ve worked out in build 765.

At this point, I’m very sure I don’t have any issue with PNG images I display in my game (regardless of how transparent the PNG images are.) So, I’m thinking that’s the part you’ve implemented the work-around for?

The problem I’m seeing is with display objects that I create at runtime, plus the custom font I use – both of which I set fill colors and alpha value for. I suppose the proper lingo for it is shapes (or vector images) created at runtime.

Here’s a plug-and-play code that you can drop in to main.lua and generate a Kindle build. Compare how it looks on simulator and how it looks on Kindle. The color difference is super obvious to me, especially with yellow and pink, but green & blue also look very much dulled down to me.

Or, is this the very same issue you’re talking about? And if so, only work around for me is to create PNG images with the color I want and use it, instead of creating display “shape” objects at run time? But then, what do I do with the custom font (which I think is vector based font) that manifests the very same issue? Maybe avoid giving it an alpha value (but then, what if the text needs to be semi-transparent so that whatever is behind can be somewhat visible???)

Thanks again for your attention regarding this.

Naomi

[lua]-- main.lua
local mainGroup = display.newGroup();
local backColor = display.newRect( mainGroup, 0, 0, 320, 480 )
backColor:setFillColor( 255, 255, 255, 255 ) – white

local circle = {}
for i=1,4 do
circle[i] = display.newCircle( mainGroup, 0, 0, 50 )
end
circle[1]:setFillColor( 150, 255, 150, 255 ) – green
circle[2]:setFillColor( 255, 255, 200, 255 ) – yellow
circle[3]:setFillColor( 100, 100, 255, 255 ) – blue
circle[4]:setFillColor( 255, 150, 255, 255 ) – pink

circle[1].x = 80; circle[1].y = 120;
circle[2].x = 80; circle[2].y = 360;
circle[3].x = 240; circle[3].y = 120;
circle[4].x = 240; circle[4].y = 360;

for i=1,4 do
circle[i].alpha = 0.45
end[/lua]

Edit: Please let me know (when you have a moment to spare – and if it takes a few days, that is no problem at all – just need to know within reasonable time frame) if the problem I presented here is indeed the same problem and cannot be dealt with within any foreseeable future. If that’s the case, I’ll need to look into how I might work-around it and minimize the damage. Thanks! [import]uid: 67217 topic_id: 24369 reply_id: 98613[/import]

#7

Naomi,

My apologies. I misunderstood the issue you were talking about.

Thanks for the sample code. I confirmed that this issue does happen on my Kindle Fire using release build 704, but it does not happen on my Samsung Galaxy S2 device. The circles are notable darker just like you said.

I’ll write this up as a bug to be fixed later. Thank you for informing us about this issue. I’ll try to have this fixed by the next release of the Corona SDK. Can’t promise a date yet, but we’re coming close to the point in our development cycle where we’ll be concentrating more on debugging. [import]uid: 32256 topic_id: 24369 reply_id: 98814[/import]

#8

Thank you so much, Joshua, for looking into this and getting back to me. Glad to know that you are able to reproduce it and confirm that this is a different bug and will be fixed by the next stable release.

I understand you are not able to state when might be the expected date of release, but I am also close to releasing my game. In fact, Apple has already accepted and approved my game for sale, but I’ve been holding off releasing the game (for various reasons, including the possible simultaneous release of the Android versions.)

So, I would like to know whether or not I should go ahead and make big changes to my game for Kindle (to minimize the ugliness effect caused by this bug). Can the time frame be in the next couple of weeks, or a month or longer? Again, I understand you cannot make any promises, and I do understand that development process can take longer than planned or hoped for due to unexpected bugs and whatever else that comes up. Knowing all that, I would still like to get a general sense regarding the release date so that I can make somewhat educated decision. I hope you understand and can help me out with some insight. I certainly will not hold you to any specific dates or expected time frame or anything. Again, I know things can change whether we like it or not.

Thanks again.

Naomi

[import]uid: 67217 topic_id: 24369 reply_id: 98830[/import]

#9

I’ll have to discuss this with the rest of the team first before committing to a date. We just need to re-prioritize and schedule the issues that we plan on resolving next. I’ll try to get an answer for you about this by the middle of next week. Does that sound good?

You might want to bug me about this issue again next week too… not that I’d normally forget, but I do get a lot of tech-support issues thrown my way. [import]uid: 32256 topic_id: 24369 reply_id: 98847[/import]

#10

That sounds great to me. I still have other kinks to work out relating to Kindle, and then I will need to work out Nook. Learning the time frame on your end will definitely help me plan my end of things. And yes, I’ll bug you again (if I don’t hear from you) on this thread mid next week.

Thanks again, Joshua! I really appreciate it.

Naomi [import]uid: 67217 topic_id: 24369 reply_id: 98851[/import]

#11

A quick note to let you know that the same issue appears with NOOK build.

Naomi [import]uid: 67217 topic_id: 24369 reply_id: 99124[/import]

#12

Tested my Android build on Galaxy S2, and it looks (and plays) just as nice as iOS version. Yay. (I guess I should find some other Android phones to test, but I’m feeling very happy at the moment.)

Figuring out how to go about setting up my dev and test device environment properly was a bit painful, but now that I’m over it (thanks to the many helpful Forum posts), I am simply amazed by how nicely iOS version crosses over to Android. Except for iOS specific code (such as IAP) and, perhaps, a little bit of art asset & sound file related changes, pretty much everything else work without much porting work. Truly awesome.

I’m now keeping my fingers crossed regarding the color issue posted here. Once it’s fixed, my Android version is very much good to go.

Naomi [import]uid: 67217 topic_id: 24369 reply_id: 99655[/import]

#13

Thanks for posting your test results. That really helps.

Regarding the Nook issue, I suspect that this issue only happens on Nook Tablet and not Nook Color. I have both devices here in the office, so I’ll eventually test it for myself… but I too have noticed that the Nook Tablet has the same graphics issues as Kindle Fire. I suspect that they both have the same video hardware/drivers, so they both have the same rendering bugs. [import]uid: 32256 topic_id: 24369 reply_id: 99848[/import]

#14

Yup, I tested on Nook Tablet. I don’t have access to Nook Color, so I don’t know how my game may look on it. Glad to hear you’ll be able to test this on both Tablet and Color when you get to work on finding workaround for this rendering problem.

Thanks!
Naomi [import]uid: 67217 topic_id: 24369 reply_id: 99857[/import]

#15

So… I’m back to ask what might be the timeframe for getting the rendering issue fixed. During the next 2-week sprint for bug fixes (I don’t know if you’re in the fixing or implementation sprint right now)? Or sometime in May or June or…?

Naomi [import]uid: 67217 topic_id: 24369 reply_id: 101699[/import]

#16

Yes, we plan on fixing this issue within the next 2 weeks. It was just scheduled in this week. Thanks for asking! [import]uid: 32256 topic_id: 24369 reply_id: 101726[/import]

#17

Hey, Joshua, that sounds great! Thank you for getting back to me.

Naomi [import]uid: 67217 topic_id: 24369 reply_id: 101740[/import]

#18

Namoi,

This bug is now fixed. The fix will be in daily build #797. [import]uid: 32256 topic_id: 24369 reply_id: 103354[/import]

#19

Awesome! Thank you, Joshua. I’ll fetch 797 asap.

Cheers,
Naomi

Edit: Joshua, I just verified that the issue is fixed on both Kindle and Nook Tablet. Thank you for fixing this!!! [import]uid: 67217 topic_id: 24369 reply_id: 103365[/import]

#20

Great! Happy to help! And thanks for bringing this issue to our attention. [import]uid: 32256 topic_id: 24369 reply_id: 104054[/import]