[2016.10] Sprite:setBlendMode(src, dst)

In Gideros 2016.10 `setBlendMode` has extended version with 2 parameters (blend functions): `src` and `dst`. They define how top sprite colors (`src`) will be blended with bottom sprite colors (`dst`). If you are familiar with image editors like Gimp or Photoshop you know they have many ready blend modes to mix layers in various ways for great effects. Those blend modes are just combinations of aforementioned blend functions so we have added direct support of those functions to Gideros.There are 11 of them: Sprite.ZERO, Sprite.ONE, Sprite.SRC_COLOR, Sprite.ONE_MINUS_SRC_COLOR, Sprite.DST_COLOR, Sprite.ONE_MINUS_DST_COLOR, Sprite.SRC_ALPHA, Sprite.ONE_MINUS_SRC_ALPHA, Sprite.DST_ALPHA, Sprite.ONE_MINUS_DST_ALPHA, Sprite.SRC_ALPHA_SATURATE. This constants are represented in Lua as integers from 1 to 11. Therefore in Gideros we have 11 * 11 = 121 way to mix colors To test extended `setBlendMode` you can use following snippet:

Comments

Hi. I'm trying to understand your example. It uses a lot of the newer features of Giderosmobile so it's really cool, but at the same time, slightly confusing for me.

I can grasp the @ macro, Pixel and setBlendMode. What I don't get is the little bit in the middle.

for k,v in pairs(Sprite) do if tonumber(v) == v then t[v] = k endend

I don't think I've ever seen someone iterate over Sprite before. What exactly are you doing (besides generating the 11-item table)? Can you iterate over other classes/objects? Why does it show the BlendModes when you do this?

@Greywine: I am just building reverse table: a table where keys are swapped with values.Since I know Sprite contains numeric constants (1 to 11) only for blend functions I can iterate over Sprite class and when value is a number I am adding it to reverse table: that number becomes a key and that Sprite key becomes a value. In the end I have following table:t = { [1] = "ZERO", [2] = "ONE", [3] = "SRC_COLOR" .....}And I use that strings as labels on the top and on the left side of the example app.In Gideros each Sprite class and subclass is represented as a Lua table. Try to iterate over some class with `for k,v in pairs(some_class) do print(k,v) end` and you will see it's methods, constants, etc. That's why we can easily create new subclasses: we are using usual Lua tables and we can store anything we want in them.

@Xman: `setBlendMode` is overloaded method: one argument to set blend modes as before, two arguments to set blend functions.Do you mean it's better to create`setBlendFunc` method for this and avoid overloading?

@Xman: see this commit:https://github.com/gideros/gideros/commit/0bfc155d7f1cb30598f4c9c4a7c6e71bf9bc2c33As you can see I have refactored Gideros blending source to make it much more clean and simple, without the need of extra utils like `bin2c` and lua-files. Also in this particular case overloading makes sense because setBlendMode(src, dst) still means you set blend mode, only composed from 2 blend functions. Compare it for example with overloaded `Sprite:setScale` where you can use both simplified 1-arg and more complex 2-arg versions.

sprite.lua is not only a "complicated way" for the blending function, we can easily extends the api for Sprite without polluting the C++ code. It should not be deleted.The creator of the engine atilim won't do such a lot of work to just add a setBlendMode function instead of make the binder code complicated like this.

C++ code was not polluted because Lua C API is natural way for Lua to interact with lower level languages like C/C++ It is easy to write, it is loaded faster and it doesnt need external convertors to load Lua scripts. And 99% of Gideros source uses Lua C API so it is bin2c-scripts are polluting C++ code, not Lua C API