Remove Surface Library Alpha 0 Optimization
It looks like there's some kind of optimization in place that prevents the surface library from drawing when the alpha of the draw color is 0.
This means that in situations where it's necessary to set the alpha channel of a Render Target, the surface library will work exactly as expected in every case except for one, which is confusing and inconsistent. Unless it's something actively harmful, I expect the game to do exactly what I tell it to do, not independently decide to silently ignore me.
Plus, I can't imagine this optimization is doing much, if anything, for performance in practice. There just aren't many situations where someone would be drawing a prohibitive number of fully-transparent shapes.
Workarounds exist, but a much more elegant solution would be if it just worked as you would expect it to.
My hope is that this is as simple as removing if( drawColor.a == 0 ){ return; } from a few functions.
Do I understand correctly that the reason you want this, is to "overwrite" a pixel in RT with 0 alpha? That's the only reason I can see for this request. I am not sure this is the best approach for this instance.
I expect the game to do exactly what I tell it to do, not independently decide to silently ignore me.
You have no idea how much the game does this for you, as it should. Lua is not a low level language, gotchas and no-ops like this should be abstracted away as much as possible.
Do I understand correctly that the reason you want this, is to "overwrite" a pixel in RT with 0 alpha? That's the only reason I can see for this request. I am not sure this is the best approach for this instance.
I expect the game to do exactly what I tell it to do, not independently decide to silently ignore me.
You have no idea how much the game does this for you, as it should. Lua is not a low level language, gotchas and no-ops like this should be abstracted away as much as possible.
This is one of the examples. Other ones are simple: stencil masks (0 alpha just breaks them) render.OverrideBlend (he was talking about that) and depth issues (rendertargets with depth)
Do I understand correctly that the reason you want this, is to "overwrite" a pixel in RT with 0 alpha? That's the only reason I can see for this request. I am not sure this is the best approach for this instance.
Not necessarily a single pixel, but if you have a Render Target that you want to initialize some part of to a specific alpha value, you can use the surface library to do that successfully in every case other than when the alpha is 0.
My only real complaint here is that it doesn't behave consistently, not that it's the only available way to achieve the effect.
I see this kind of behavior as belonging more in the draw library which uses the surface library, rather than in the surface library itself which is intended to be the underlying shape-drawing library.
Perhaps the optimization could be disabled specifically if render.OverrideBlend is enabled.
That might get the best of both worlds, depending on if it's somehow expensive to check the state of render.OverrideBlend