In my game I’ve a few images that are greyscale. I was wondering if somebody could tell me which is better for performance, an image with no alpha, set to blendmode “add”, or an image with an alpha channel and blend mode set to normal.
I use TinyPNG to compress all my images. I was just wondering if there’s any performance benefit doing one over another.
Thanks in advance,
Dan
Dan,
The engineers at Corona can verify or contradict this, but I don’t think it matters what format your image is stored in.
Once it is loaded into memory it uses the same space.
That is, not to say using compression (TinyPNG or other) is a bad idea. Compression is good, and TinyPNG is awesome.
Stored format is irrelevant to in memory representation.
Oh, and I assume when you say performance you’re talking memory usage, not the cost of opening and loading the file into memory. Please clarify if I misunderstood you.
-Ed
PS - Just to be absolutely clear, I’m not saying PNG is the same as JPG is the same as quantitized PNG… PNG is necessary for Alpha JPG can’t do that for you (well JPG 2000 can, but I don’t think that is supported by Corona.) The point is, a 256x256 PNG with alpha takes the same amount of memory when loaded as does a 256x256 JPG. Unless the developers purposely chose a different representation for different sources (unlikely) then they will both use the same memory. The JPG will simply have an alpha of 255.
Hi Ed,
Thanks for the reply.
Sorry, I should have been far more clear. When I said performance I was referring to fps. I know in other games I’ve worked on (outside of Corona), overdraw can be an issue. Too many blended textures causes slowdown. So I guess what I’m asking is if blending is more expensive than alpha. For example, if I had twenty white images overlapping each other, would I see a difference in framerate if those images were additive or if they were alpha textures?
Dan
@Dan,
Ah. Yes that is a hard question to answer. Part of it is entirely dependent upon the hardware and its graphics pipeline as well as how many units it has available for specific operation types. That said, I find, if I know my target devices (say all late generation iPhones and iPads) that simply testing both in the extreme case is the best way to find out.
However, I hope someone who knows more about this, and is less rusty re: graphics pipelines than I, has a better answer than my “try it out” answer.
So all readers who have knowledge (even partial) please chime in!
PS - I last delved into the hardcore graphics arena back in the fixed pipeline days.
Dan,
I used the add blend mode extensively in my puzzle game Panal and haven’t noticed any major performance issues on the devices I’ve tested. I reuse a single white hex PNG and second blurred version for highlighting for each tile and tint it using the setFillColor method. Then the add blend mode takes care of merging the colors together. There’s a free version for Android if you want to check it out.
https://play.google.com/store/apps/details?id=jandjstudiosllc.Panal.Lite
Josh
except in a few special cases (no overlap, on black background) these two won’t produce equvalent results:
>> an image with no alpha, set to blendmode “add”, or an image with an alpha channel and blend mode set to normal.
so it’s not an entirely “fair” question. If you *need* one or the other, then you *need* it, case closed. However…
let’s assume you your question is theoretical, and you don’t care about any visual difference, and that you have “enough” (several hundred, -ish?) of these things to actually affect frame rate.
with a ton of caveats and other qualified disclaimers, and given the exact same configuration of objects on both tests… on “most” devices the blendmode normal with an alpha image will be faster. (spend an hour writing it and testing it on device yourself)
why? well it probably has nothing to do with alpha itself really.
rather, it probably has to do with state change. Corona might have to do the equivalent of a glBlendFunc/glBlendEquation call (and potentially a glEnable call) *per geometry*.
I’m not sure how “smart” the Corona internals are at keeping track of current state (and potentially only calling such functions when strictly necessary), but it’s easy to imagine a worst-case scenario where every other object is blend mode normal then blend mode add, so LOTS of state changes. (there’s also the possibility that Corona’s entire pipeline is now shader-based, but still you’d have to toggle something somewhere in the shader, or worse swap out shaders entirely – regardless there’s nothing faster than doing nothing :D)
it’s like the difference between these two loops (PSEUDOCODE):
setupOpenGLESDefaults() for i=1,300 do geometry:render() end -- setupOpenGLESDefaults() for i=1,300 do if (geometry.hasFancyProperties) then enableAllThoseFancyProperties() else disableAllThoseFancyProperties() end geometry:render() end
hth
Dan,
The engineers at Corona can verify or contradict this, but I don’t think it matters what format your image is stored in.
Once it is loaded into memory it uses the same space.
That is, not to say using compression (TinyPNG or other) is a bad idea. Compression is good, and TinyPNG is awesome.
Stored format is irrelevant to in memory representation.
Oh, and I assume when you say performance you’re talking memory usage, not the cost of opening and loading the file into memory. Please clarify if I misunderstood you.
-Ed
PS - Just to be absolutely clear, I’m not saying PNG is the same as JPG is the same as quantitized PNG… PNG is necessary for Alpha JPG can’t do that for you (well JPG 2000 can, but I don’t think that is supported by Corona.) The point is, a 256x256 PNG with alpha takes the same amount of memory when loaded as does a 256x256 JPG. Unless the developers purposely chose a different representation for different sources (unlikely) then they will both use the same memory. The JPG will simply have an alpha of 255.
Hi Ed,
Thanks for the reply.
Sorry, I should have been far more clear. When I said performance I was referring to fps. I know in other games I’ve worked on (outside of Corona), overdraw can be an issue. Too many blended textures causes slowdown. So I guess what I’m asking is if blending is more expensive than alpha. For example, if I had twenty white images overlapping each other, would I see a difference in framerate if those images were additive or if they were alpha textures?
Dan
@Dan,
Ah. Yes that is a hard question to answer. Part of it is entirely dependent upon the hardware and its graphics pipeline as well as how many units it has available for specific operation types. That said, I find, if I know my target devices (say all late generation iPhones and iPads) that simply testing both in the extreme case is the best way to find out.
However, I hope someone who knows more about this, and is less rusty re: graphics pipelines than I, has a better answer than my “try it out” answer.
So all readers who have knowledge (even partial) please chime in!
PS - I last delved into the hardcore graphics arena back in the fixed pipeline days.
Dan,
I used the add blend mode extensively in my puzzle game Panal and haven’t noticed any major performance issues on the devices I’ve tested. I reuse a single white hex PNG and second blurred version for highlighting for each tile and tint it using the setFillColor method. Then the add blend mode takes care of merging the colors together. There’s a free version for Android if you want to check it out.
https://play.google.com/store/apps/details?id=jandjstudiosllc.Panal.Lite
Josh
except in a few special cases (no overlap, on black background) these two won’t produce equvalent results:
>> an image with no alpha, set to blendmode “add”, or an image with an alpha channel and blend mode set to normal.
so it’s not an entirely “fair” question. If you *need* one or the other, then you *need* it, case closed. However…
let’s assume you your question is theoretical, and you don’t care about any visual difference, and that you have “enough” (several hundred, -ish?) of these things to actually affect frame rate.
with a ton of caveats and other qualified disclaimers, and given the exact same configuration of objects on both tests… on “most” devices the blendmode normal with an alpha image will be faster. (spend an hour writing it and testing it on device yourself)
why? well it probably has nothing to do with alpha itself really.
rather, it probably has to do with state change. Corona might have to do the equivalent of a glBlendFunc/glBlendEquation call (and potentially a glEnable call) *per geometry*.
I’m not sure how “smart” the Corona internals are at keeping track of current state (and potentially only calling such functions when strictly necessary), but it’s easy to imagine a worst-case scenario where every other object is blend mode normal then blend mode add, so LOTS of state changes. (there’s also the possibility that Corona’s entire pipeline is now shader-based, but still you’d have to toggle something somewhere in the shader, or worse swap out shaders entirely – regardless there’s nothing faster than doing nothing :D)
it’s like the difference between these two loops (PSEUDOCODE):
setupOpenGLESDefaults() for i=1,300 do geometry:render() end -- setupOpenGLESDefaults() for i=1,300 do if (geometry.hasFancyProperties) then enableAllThoseFancyProperties() else disableAllThoseFancyProperties() end geometry:render() end
hth