Topic: Suggestion: Explicit option in the editor to choose the blending mode?

[Monsieur OUXX]

[I hope this is the right forum]

I just had this thought:
Many alpha-related issues happen not only because of the technical aspect (the implementation, etc.), but also because developers often bump into the most common issue with alpha blending, namely DECIDING "how should my alpha sprite be blended? Should the transparent channel replace the underlying color, or blend into it, or add, etc.?".
If my memory is correct, this has been partially addressed in Calin's blending plugin, but still this alpha-blending paradigm (pardon my French) is not obvious for the beginner.

So I was thinking: Why not do like most painting programs do? If you look closely, in most of them the "brush" tool comes with an option to choose the blending mode: "add colors, replace colors, etc.". There is an explicit button/menu for that.
Maybe we could do the same thing in AGS? Add a simple attribute to each sprite that defines how it's going to blend. And the game developer could choose that at import time with a simple tick-box. something like "Tick this if you want the alpha-channel to replace the colors instead of merge" (<-- bad English, but you get the point).

I know it doesn't sound like a priority, but I have the feeling that the alpha-blending issue is on the verge of being fixed by some of the developers around. They are currently fiddling with the source. They sound really pissed off by the alpha bug. They're going to do it (you can't stop them, they're crazy
So it sounds like the right time to suggest this. Two stones with one bird, y'know.

What do you think?


(this is a complex example with one billion blend-modes, but one would be enough for AGS)

[Snarky]

It would be very nice to have more blend options available (I'd particularly like to be able to set the blend options separately for alpha and color values, as that would simplify my subpixel routines a lot). Good in-engine performance probably depends on what the graphics API supports. Does anyone know about that?

[Ghost]

I think at least a couple of "standard" blending modes should be in- highcolour games are becoming more popular and they allow a lot of neat tricks that require complicated workarounds in 16bit. I'm all for giving as many options as possible. When there's going to be an engine overhaul, it might as well be a huge one.

Also, Snarky's suggestion makes perfect sense!

Performance-wise, wouldn't the screen resolution have a lot of impact? Is it possible to make a tiny 320x240 window stutter on medium-level PCs?

[Monsieur OUXX]

Good in-engine performance probably depends on what the graphics API supports. Does anyone know about that?

As I wrote, yes, there are several specialists ( I wrote "specialists" in comparison with people like me, so please Calin don't deny  ). Some plugins have been written.
All of that is available for the last 10 years in DirectDraw, and even when it's not, the routines have been written (then again, see Calin's plugin).
If it's possible for the alpha channel, it's possible for the colors separately.

So the purpose of my post was more to make those blending options visible for the Editor's end user, rather than discussion the technical aspect of the issue.

[Ali]

All I can say is: Yes to this!

[Ghost]

So the purpose of my post was more to make those blending options visible for the Editor's end user, rather than discussion the technical aspect of the issue.

In that case a full +1! 

[Alan v.Drake]

It's already possible to introduce different blending modes, since allegro does support some of them and d3d as well. The problem is deciding how.
Should we add a property to characters/objects/overlays/etc.. to change the blending mode ? Setting it directly to the sprite sounds bulky and cumbersome, it also requires to fiddle with AGS.NATIVE which is not out yet.

But if that's too much work one could just make a command to change blend mode for all overlays, or something.

- Alan

[Calin Leafshade]

(oh look new forums)

The most elegant way to do this is with pixel shaders which would preclude the use of non PS capable gfx chips.

However, fuck those chips.

I suggest that you create shaders in exactly the same way you create other named assets (like dialogs). They can be compiled and bundled like any other asset along with some standard shaders.

Then you simply assign the shader to the character/object

Code: [Select]

cEgo.Shader = myShaderWhatIMaded;

That seems pretty elegant to me providing a default is provided.

Since the compiler isnt open yet there are some difficulties with this idea but they are not insurmountable.

[selmiak]

this sounds great. especially when you can chose between just the alphapixels blending or the whole sprite.

*throws in more Photoshop and CSS3 ripoff ideas*

oNeonsign.Glow = #442345, 10, 3, bScreen;    (color, blurrange, fill, blendmode)
oWoodsignInFrontOfWall.Shadow = #000000, 10, 3, 20, 20, bNormal;   (color, blurrange, overfill, offsetX, offsetY, blendmode)

[monkey0506]

oNeonsign.Glow = #442345, 10, 3, bScreen;    (color, blurrange, fill, blendmode)
oWoodsignInFrontOfWall.Shadow = #000000, 10, 3, 20, 20, bNormal;   (color, blurrange, overfill, offsetX, offsetY, blendmode)

Putting that in something more like AGScript:

Code: [Select]

oNeonsign.SetGlow(HexToDec("442345"), 10, 3, eBlendScreen);
oWoodsignInFrontOfWall.SetShadow(HexToDec("000000"), 10, 3, 20, 20, eBlendNormal);

[SSH]

I thought you meant that the option shoudl be explicit like: "Use f$%^&ing multiplicative c^^&&! blending"

[Dualnames]

I recall Calin's plugin actually offered some of those, did anyone bother checking that out? I'm also fully supportive of such feature. Provided we get someone fully committed and equipped with the technical knowledge and coffee supply to implement it, I think it would make a wonderful and useful addition.

[Monsieur OUXX]

I thought you meant that the option shoudl be explicit like: "Use f$%^&ing multiplicative c^^&&! blending"

Yes, but apparently the discussion is getting out of hand, and people are already discussing the actual implementation.
I say we should just let them do their thing. Well, actually, let yous do your thing, considering you're also a coder, SSH.

"Let's get cracking" (Dr. Fred)

[Calin Leafshade]

oNeonsign.Glow = #442345, 10, 3, bScreen;    (color, blurrange, fill, blendmode)
oWoodsignInFrontOfWall.Shadow = #000000, 10, 3, 20, 20, bNormal;   (color, blurrange, overfill, offsetX, offsetY, blendmode)

Putting that in something more like AGScript:

Code: [Select]

oNeonsign.SetGlow(HexToDec("442345"), 10, 3, eBlendScreen);
oWoodsignInFrontOfWall.SetShadow(HexToDec("000000"), 10, 3, 20, 20, eBlendNormal);

I would advise against implementations like this. Modularise Modularise Modularise.

If you have built in, indexed blending modes like eBlendNormal how does one add new blenders?

However, if you create them in the editor as *named objects* they are encapsulated nicely and easy to expand upon by the user *if they want to*.