Anyone needing more blend functions and pixel shader access, please request this feature to be prioritized.
The lack of a simple “additive” blending operation is a major drawback when creating all sorts of nice “lighting” effects such as lights, explosions, lasers, neon, flahses and so on. [import]uid: 5750 topic_id: 5632 reply_id: 305632[/import]
So what are your thoughts about shaders? Do you want the ability to submit raw OpenGL shader code yourself or is that too low level? How would you bind shaders to objects (e.g. would each display object have the ability to get its own shader?) Do you have thoughts on what happens if grouped display objects have their own conflicting shaders, how is that resolved?
Also, using the existing non-shader pipeline, would exposing up the OpenGL blend functions be useful for your purposes, e.g. glBlendFunc(GL_ONE, GL_ONE)?
(I’m not implying anything here except we just want to know what people really need and want.)
[import]uid: 7563 topic_id: 5632 reply_id: 19370[/import]
how about
object:addShader(“shaderType”)
object:removeShader
object:changeShader(“newShaderType”)
not sure about syntax…but hopefully you get the idea.
Seems like this method would allow us to apply it and remove it on the fly.
I would think additive and screened are the top 2. Would also think it would be nice if there were a scaler on it…as to how much filtering to apply…
such as:
myObject:addShader(“additive”, 0.5) – add 50% additive filter to object.
Not sure if possible…but seems like this could be expanded to include glow, dropshadow, and outline effects.
Sorry for the simplicity…OpenGL is above my pay grade…just speaking from a novice coder’s perspective. I think for most of us “less sophisticated” users, we just want cool visual FX to polish up our apps…that are “Corona simple” to implement.
One other note…
Seems like GameSalad implemented this really well into their GDK. It was super simple to apply filters to objects and particles. It really made a huge difference in the end results of the assets during gameplay. [import]uid: 9492 topic_id: 5632 reply_id: 19378[/import]
I would LOVE it if blending modes were implemented similarly to how they are done in Flash. I personally do not need that really low level access, and I would appreciate it if you “Corona-fied” it!
So, something similar to this:
event.target.blendMode = BlendMode.ADD
event.target.blendMode = BlendMode.MULTIPLY
event.target.blendMode = BlendMode.OVERLAY
event.target.blendMode = BlendMode.SCREEN
event.target.blendMode = BlendMode.NORMAL
And those could be accessed and changed on the fly.
It would be great if the blendmodes could be applied to all display objects - images, text, vectors, and groups.
If a Display Group has objects with several blendmodes, they should be applied one after the other, starting with the bottom object, and moving upwards - similar to how Photoshop handles it.
One blendmode that would really help me out, is the ‘LAYER’ blendmode. It is used on Display Groups to composite objects together before applying different effects.
A problem that Flash used to have, and that Corona currently has, is that when you try to apply an alpha fade on a display group, Corona goes in and fades each object separately, as opposed to as a whole.
This produces undesirable “see-through” effects.
It’s a little hard to explain, so I made these three images to show it better:
Here is the first image. Imagine that this is a display group with two objects in it - the person and the baseball cap:
If I was to apply an alpha setting of 50% to this group, something like: myDisplayGroup.alpha = 0.5
I would get a result like this in Corona:
This is not really what I want, as you can now see the person’s hair through the baseball cap.
In Flash, I would fix this issue like so:
myDisplayGroup.blendMode = BlendMode.LAYER
myDisplayGroup.alpha = 0.5
And it would render it correctly, like this:
I realize this sounds like an extremely fiddly request, but I am encountering it all the time in my adventure games. I am cross-fading between screens, and as the screens fade in, you are able to see though locked doors, see objects that aren’t supposed to be there, etc.
Here is a blog post from Tinic Uro, when he was working on implementing blend modes in Flash Player 8: http://blog.kaourantin.net/?p=26
And this is a classic article explaining the different formulas used to calculate the blend modes in Photoshop: http://www.pegtop.net/delphi/articles/blendmodes/
It would be so amazing if you could implement any/all of those!
I know that pixel level stuff like blend modes really affect performance, but their effect is so stunning!
They should totally be a “use at your own risk” feature, but if you give us access to them, we will definitely create some amazing looking apps! [import]uid: 8444 topic_id: 5632 reply_id: 19389[/import]
So what are your thoughts about shaders? Do you want the ability to submit raw OpenGL shader code yourself or is that too low level? How would you bind shaders to objects (e.g. would each display object have the ability to get its own shader?) Do you have thoughts on what happens if grouped display objects have their own conflicting shaders, how is that resolved?
Well, writing and assigning shaders would be good. As I see it, Corona would meet the favor of its broadest audience by exposing both blending modes (i.e. glBlendFunc) by object or groups of object and by directly loading and assigning pixel shaders.
Now, you could do this many ways performance-wise. If I recall, changing states on a per-object basis has got a cost. Although you could introduce “shading groups”, as in Maya for instance.
A shading group would be a node to which a shader (along with its custom parameters) and/or a blending mode is assigned and that contains display objects and display groups as children.
That way Corona can limit the number of state changes to shading groups only… a state change for each shading group.
I’d summarize the shader system with a few, general functions:
- shaderObject = shader:loadShader( string )
By using a string as a parameter would allow to both loading a shader from the system folder and by creating it programmatically within Lua.
(in the end, any IO load functon in Lua returns the file as a string anyway)
Now, in an ideal situation the loadShader function would parse shader parameters automatically and expose them. Shader params would then be modified at runtime by value assignment to the shaderObject table member.
Ex: shaderObject.myShaderVar = 2.0
If that’s too heavy on Lua, a shaderObject:addParam() and shaderObject:setParam() would be needed.
- shadingGroup = shader:createGroup(params_table)
shadingGroup:assignObject(…)
– list of display objects and/or groups
shadingGroup:setShader(shaderObject)
shadingGroup:setBlending(ENUM_BLEND_MODE)
shadingGroup:bindTexture(…)
– list of display objects and/or groups. Must allow a texture to be outside the current shadingGroup.
Now the binding is a bit tricky. In theory most of the times you want to lookup for each display object texture in a shader, but you also might want to lookup more than one texture as well.
In that case a convention could be used where every shader is passed a “defaultTexture” as register 0, representing the currently drawn display object texture, while the optional shadingGroup:bindTexture(…) will address any other additionally declared texture, in order, within the shader code.
So, if you additionally bindTexture(obj1,obj2) textures, you must declare their image names - without extension - within the shader as well.
Also, using the existing non-shader pipeline, would exposing up the OpenGL blend functions be useful for your purposes, e.g. glBlendFunc(GL_ONE, GL_ONE)?
(I’m not implying anything here except we just want to know what people really need and want.)
In order to simplify and allow a basic use of glBlendFunc only, without using the shader system, Corona could expose a “defaultShadingGroup”, which is the current, standard rendering node for all display objects, and allowing for its modification:
[lua]local defgroup = display:getDefaultShadingGroup()
defgroup:setBlending(ENUM_BLEND_MODE)[/lua]
Clearly, if you want to set a blend mode just for a group of objects, you need a shading group, although without the need to write a shader for it. (shading groups without shaders should be legal for this very purpose)
I might have missed many things, but this is how I’d see it being most useful for both “simple” and “advanced” usage.
Thanks. [import]uid: 5750 topic_id: 5632 reply_id: 19439[/import]
True, I notice the same during page fades. That’s “common” though. The only way you can achieve the “LAYER blend mode” (and supposedly Flash solves the same way) is using “render to texture” techniques - aka “texture baking”.
It’s not trivial on a mobile device and requires pixel shaders - unless implemented in a “fixed way”.
Although I second the feature, and although it would solve a very common issue, it’s very, very specific and could be quite slow, depending on hardware.
I suppose I can live without that another two or three Corona drops. 
[import]uid: 5750 topic_id: 5632 reply_id: 19451[/import]
+1 [import]uid: 12088 topic_id: 5632 reply_id: 23252[/import]
I so what pixel shaders I could crap a brick. I feel so strung along about this issue and I can’t get a straight answer if they are actually working on it or just “Thinking about it” [import]uid: 5886 topic_id: 5632 reply_id: 23566[/import]
you need a +1 score of 50, to get them to work on it
here’s mine… +1 [import]uid: 6645 topic_id: 5632 reply_id: 23653[/import]
+49 [import]uid: 9371 topic_id: 5632 reply_id: 23667[/import]
I can’t help being pedantic about the title of this thread and saying I do not support making shaders the top priority. I would put them at maybe 3 or 4 on the list of priorities.
I would LOVE it if blending modes were implemented similarly to how they are done in Flash. I personally do not need that really low level access, and I would appreciate it if you “Corona-fied” it!
I concur with this approach. I too have little interest in writing shader code directly (if I wanted to be that low-level, I wouldn’t be using Corona) but add and multiply blend modes would be the bee’s knees. [import]uid: 12108 topic_id: 5632 reply_id: 23676[/import]
I’m afraid there’s no real easy way out with pixel shaders and blending modes.
The least you need to define when using blending modes, as said earlier, could be “shading groups” - and that’s pretty easy, no shader for you to code - although part of the “Corona shading system”.
So, if anyone isn’t interested in the actual pixel shader code, they’re done.
The thread title looks ok to me. Working with blending modes poses some of the same problems as working with shaders - on the architectural side of the engine.
As a final thought, I believe there are things you cannot over-simplify - like shaders. For many reasons: performance, engine complexity, engine maintenance and of course flexibility on the users side. Personally, I’d never, ever want Corona to become “Flash”. 
[import]uid: 5750 topic_id: 5632 reply_id: 23692[/import]
I think you misunderstood my comment. I wasn’t saying blending modes instead of pixel shaders, I was saying that blending modes are how I’d like to see pixel shaders implemented. As in, Corona uses pixel shaders but abstracted under commands like image:setBlend(“add”)
And, um, my comment about the title was a joke. *swish* [import]uid: 12108 topic_id: 5632 reply_id: 23700[/import]
Uhmm, I think I did not misunderstood your comment. I can’t read you wanted “blend modes” implemented as “pixel shaders”, you simply said:
I too have little interest in writing shader code directly (if I wanted to be that low-level, I wouldn’t be using Corona) but add and multiply blend modes would be the bee’s knees.
…which means, well… “blend modes”, which usually refers to glBlendFunc, or “fixed pipeline” functions.
It would be quite outrageous to implement “blend modes” using pixel shaders - and not being able to actually write them.
If you read back my long comment, you find that my suggestion is very similar to your image:setBlend(“add”) - wrt blend modes.
The only difference is that you’d prefer a more “automatic” management of shading groups, i.e. you’d simply set blending mode for an object. Which isn’t in contrast to the system I suggested.
Corona could automatically define shading groups for all the glBlendFunc modes, and automatically insert the object with the corresponding mode into the right shading group.
On the other side, while this could be feasible, it might well limit the flexibility of the actual pixel shaders system and future enhancements.
I’d rather have you to also define shading groups, i.e. 2 functions instead of your proposed single function, rather than jeopardize flexibility and future development.
[import]uid: 5750 topic_id: 5632 reply_id: 23764[/import]
I bought my ray-ban shaders today.
C. [import]uid: 24 topic_id: 5632 reply_id: 23788[/import]
If we had shader support I could render your shades with some sweet caustics.
Carlos, I hope you are hinting about an imminent daily drop with shader support. If not that is just a bad and hurtful joke. [import]uid: 5886 topic_id: 5632 reply_id: 23809[/import]
I bought my ray-ban shaders today.
You know Ray-Ban is italian now, don’t you ? [import]uid: 5750 topic_id: 5632 reply_id: 23866[/import]
so are my shoes… Prada… oh wait, Ferragamo… No wait… Never mind… For a minute there I saw Manolo Blahniks…but those aren’t mine.
C. [import]uid: 24 topic_id: 5632 reply_id: 24837[/import]
“All your *shoe* are belong to us”… dear Carlos! 
[import]uid: 5750 topic_id: 5632 reply_id: 24874[/import]
+1 from me…additive especially is crucial to games. Glowy particles and other additive effects can add polish to a game.
I was a bit surprised that with all the exposed API’s, the few lines of C++ required to implement blend modes somehow got overlooked. [import]uid: 29170 topic_id: 5632 reply_id: 25229[/import]