[posila] [1.1.72] recipe.crafting_machine_tint unexpected results with transparent black

[Deadlock989]

I have been fiddling with a crafting machine prototype that I wanted to display only one of two different kinds of working animation depending on the recipe, with a tinted layer involved. I realised that as long as I only want two variants, I can use the four channels of crafting_machine_tint and apply_recipe_tint with selective transparency - animation A sets primary and secondary to white and recipe-tinted respectively and sets tertiary and quaternary to transparent, and animation B does the reverse. (You could have four if none of them have to be tinted with a variable colour.)

I couldn't get it to work for ages and after much banging of head on desk figured out what the issue was. The wiki says that these are the default values of the channels if they are not specified:

Code: Select all

crafting_machine_tint = { primary = {r=0,g=0,b=0,a=0}, secondary = {r=0,g=0,b=0,a=0}, tertiary = {r=0,g=0,b=0,a=0}, quaternary = {r=0,g=0,b=0,a=0}}

{0,0,0,0} equates to (pre-multiplied) "transparent black". It shouldn't be visible at all. But the channels were appearing as if untinted or tinted by opaque white. This happens both if not specified at all (i.e. left to the default stated above) and if explicitly set to {0,0,0,0}.

I then tried other tints with various colours and transparencies. They all worked as expected - half transparent red, quarter transparent green etc. - as long as the value wasn't {0,0,0,0}.

Finally I figured out that this achieves the desired effect as a workaround:

Code: Select all

local tint = {
	primary = {r=0,g=0,b=0,a=0.000000000000001},
	secondary = fluid.base_color,
	tertiary = {r=0,g=0,b=0,a=0.000000000000001},
	quaternary = {r=1,g=1,b=1,a=1},
}

If forced to guess I would say that a value of less than 1/255 works because the additions to the background colour channels are effectively rounded down to a value of 0 in the render.

You can't use any other transparent colour because the crafting machine tints are treated as pre-multiplied - so e.g. transparent red {1,0,0,0} gives odd-looking but correct results because the red channel should be pre-multiplied, e.g. 10% additional red should be {0.1,0,0,0.1} and 0% additional anything is {0,0,0,0}.

What I think should be happening (if full untinted opacity is the desired behaviour for not specifying a crafting machine tint channel) is that the default value should be {1,1,1,1} and explicitly setting {0,0,0,0} should be treated as fully transparent.

[posila]

Some programmer tried to be smart (me) and thought nobody will need to tint anything by {0,0,0,0}, because that would make it invisible, therefore the sprite wouldn't need to be there in the first place. So I used 0,0,0,0 as signal value, to indicate the value was not set in the prototype and we should fallback to default_recipe_tint defined in the working visualization (which default to white)

I'll change this.

[Deadlock989]

Many thanks, I wondered if it was something like that.

Is there any scope in the engine maybe for checking that a recipe tint (actually, any tint) of transparent black is being used and then not bothering to run the add-to-background maths and effectively skipping the animation layer completely (per entity per recipe)? Or is that already pretty optimised, or not worth the trouble? I am starting to feel a bit guilt-stricken about trying to populate the screen with invisible animations. In my defence, they are small (two tiles or less) and not too many frames.

[posila]

Fixed/changed for 1.1.73

[posila]

Some specific things (like smoke) test for transparency level being very close to being completely transparent, but general sprite drawing doesn't. I don't think machines that have working visualizations will generate that many sprites for it to matter.

[Deadlock989]

Many thanks.